FCKeditor Works with MediaWiki Now

For the longest time, our MediaWiki installation was abandoned because I could not figure out why FCKeditor would not work. The behavior was erratic at best, being that the issues were different depending on which browser I was using.

In Snow Leopard with Safari 4.0.5, the editor appeared to work, allowing me to create a new page and use the WYSIWYG editor as I pleased... until I tried to edit a page. When editing a page, by default the wikitext editor appears with the correct contents of the page. But as soon I switch to FCKeditor, all of the text disappears, leaving me with a blank slate. Then, when I switch back to the wikitext editor, all I see are six alarming characters: $nbsp;. Everything in the page was effectively erased.

In Snow Leopard with Firefox 3.6.3, FCKeditor would not load at all. Whenever I tried to switch to the rich text editor, I would get a totally mysterious error in the Error Console.

Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.statusText]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://www.northeastern.edu/cpspedia/wiki/skins/common/ajax.js?207 :: anonymous :: line 124" data: no]

In Windows with IE8, FCKeditor would also failed to load with the same visual symptoms as experienced with Firefox in Snow Leopard. To Microsoft's credit, IE8 did produce a more useful error message than I had previously encountered.

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Timestamp: Sat, 12 Jun 2010 23:17:16 UTC


Message: Access is denied.

Line: 107
Char: 3
Code: 0
URI: http://www.northeastern.edu/cpspedia/wiki/skins/common/ajax.js?207

Months ago, I had searched high and low over the web and found nothing useful to help me solve this problem.

With renewed determination this time around, since there was a larger user buy-in and more at stake to have a successful deployment of MediaWiki, I tried to tackle the problem again. Hitting the same walls as I did previously, I was almost ready to give up and file a bug with CKEditor and cross my heart hoping to die that CKEditor would troubleshoot the issue with me. I even found a tip in the "FCKeditor integration guide" that sounded exactly like the solution for me, but it seemed suboptimal and more importantly did not work.

After spending almost three hours this time around on the same problem, I took one last shot by diving into wiki/skins/common/ajax.js. There, going to line 107, I found a lone function call with three parameters, one of which was called uri. When I used alert() to examine the three parameters, I almost jumped from my seat as I realized what the problem was.

The URI being passed to the function had an internal base server name and not the external server name that I was using to access the wiki in my browsers!

Digging through some MediaWiki documentation, I found a reference to $wgServer and found out that this variable was not set in LocalSettings.php. Once I set this variable with the correct server name, all was well.

Correction: All is well.

Goodness... what a trip.

Copy and Paste from Mac OS X Clipboard in VI

I really like using VI, but one of the frustrations for me was not knowing how to copy to and paste from the system clipboard. Thankfully, a search on Google took me to an article that gave a very good pointer on how to workaround the issue.

"Mac OS X clipboard sharing"
http://vim.wikia.com/wiki/Mac_OS_X_clipboard_sharing

Basically, the technique involved using VI's ability to execute shell commands within the context of the text editor. So, the copy/paste functions can be emulated by using the native pbcopy and pbpaste commands in Mac OS X.

• To copy, type :[range]!pbcopy


• To paste, type :r !pbpaste

Terminal Setting to Facilitate VI in Mac OS X SSH Session

I was constantly annoyed by the fact that when I connected via SSH to a remote Unix server and tried to run VI or VIM, I would encounter the following message:

ex: 0602-108 xterm-color is not a recognized terminal type.
[Press return to continue]

After I acknowledge the error, VI would be essentially unusable.

Luckily for me, I was able to find a post from back in 2004 about the same issue on earlier versions of Mac.

"Setting terminal to be recognized for SSH."
http://forums.macosxhints.com/showthread.php?t=19246

While the suggestion they had for creating the ~/.ssh/environment file did not work for me, setting TERM=vt100 before I ran ssh in Terminal did allow me to use VI properly in the SSH session.

iPad Test Drive: Day 4.5 at Last

So, without much emotion, I handed the iPad back to Tom today after erasing all of my data from the device...

--

Goodbye, pretty, shiny piece of modern technology with no apparent business use. I wish I could justify having you at my desk all the time to make me look cool at the center of everyone's attention, but I simply can't at this moment. Your battery life is awesome; your screen resolution and graphical rendering capabilities are second-to-none; and you're probably one of the sexiest gadgets I've seen in a long time. But you're just not for me, or for any regular office-dwelling employee.

However, I would really like to try out your evil arch-nemisis (if it turns out to be that way): the WePad. Don't take offense. You were the first of your kind, and you definitely made a bold statement about the new age of computing to come.

Thanks for the ride.

iPad Test Drive: Day 3.5

I bumped into a guy on the T today, and the next thing I knew he was asking me about my thoughts on "my" iPad. I explained that I was testing the iPad for work-related uses but that so far I'm drawing blanks (except for the two applications previously mentioned). He seemed really worried about my response and immediately pulled out his own iPad to show me his note-taking app. It turns out that he's a BU student who works at e Apple Store on Boylston. I'm happy for him that he's so loyal to his employer, but I really do think that the iPad is only a taste of the real tablet products to come.

A quick read of the iPad's upcoming competition gives me great hope that eventually I will have a tablet that is also a laptop replacement. Lenovo's take on the tablet is the closest to what I would consider the next-generation workplace computer, and everything else is a cool gadget with limited uses.

I still haven't thought of a paid app to try yet. Maybe something will come to me in my sleep tonight.

iPad Test Drive: Day 2.5

While it's sad to say that I probably can't justify getting one of these for my own personal use, I think that to Kevin and Leanda this iPad may be of some value for applications they've already identified. The keyword is "may", because a lot of functionality is theoretical at this moment and may even require in-house development.

Leanda believes that recruitment may benefit from using the device at live events to both woo prospects and facilitate quickener and more accurate data entry. This is dependent upon the ability to develop either a native app or a web app that enforces data validity and is easy-to-use.

Kevin sees that as course content consumption shifts more and more into the virtual realm, a device like the iPad would be the medium through which students view lectures, complete homework assignments and take tests. Again, the potential is there, but execution will depend on how user-friendly and functional the final app or web app truly is.

One good thing to report: I have to say that reading the pizza menu in PDF format on the iPad was a very enjoyable experience, although I do wish that I could've searched for keywords Ike "pepperoni".

I'll try to think of a useful paid app that I can try out tomorrow for a different twist on the iPad.

iPad Test Drive: MobileMe

Okay, so... MobleMe is an interesting product from Apple designed to get around the fact that you can't store files directly on the iPad and you can't connect it up to your computer as an external hard drive.  There are actually two apps that you have to download to use the online storage features that I personally thought could be all obtained within one app.

For instance, if you upload a picture from your iPhone to MobileMe, wouldn't you expect the picture to show up in the iDisk app's Picture section?  No, Apple didn't think so.  Apple wants you to download their second app, Gallery.

Fine, I can handle that.  But the Gallery app isn't even made for the iPad.  Apple simply took an iPhone app and threw it into the iPad section of the store.  Even the interface is iPhone-sized, forcing you to use the iPhone-style keypad for data entry instead of the native iPad keyboard.  This from the same company that couldn't be bothered to throw in foreign language input support that already exists for the iPhone...

But still!  No big deal, right?  Until you get to the final kicker of the whole ordeal:  There is no way to delete a picture that you've uploaded to MobileMe using either iDisk or Gallery.  You have to log on to the MobileMe website to manage or delete the pictures you uploaded.

Oh, and by the way, you can't do this from the iPad because Safari for iPad is not a real browser.