Saturday, June 12, 2010

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

Saturday, June 5, 2010

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.