Last modified: 2011-12-14 13:39:14 UTC
Having FCKeditor installed, I get the following notice when I run the maintenance scripts: Notice: Undefined index: HTTP_USER_AGENT in extensions\FCKeditor\fckeditor\fckeditor_php5.php on line 37 The file in question attempts to access $_SERVER['HTTP_USER_AGENT'] which is not set in command line mode. People have already asked for a fix in CKEditor itself, however the CKEditor guys say they will not fix this issue. See http://dev.ckeditor.com/ticket/6279 I see no reason for FCKeditor to be loaded when running command line php scripts for mediawiki maintenance. I propose to fix the issue in the MediaWiki extension by adding an early return, if we are in command line mode: At the beginning of FCKeditor\FCKeditor.php: <code> // There is no reason for FCKeditor to run in commandline mode. // Returning avoids breakage of scripts like dumpBackup.php. if ( isset($wgCommandLineMode) && $wgCommandLineMode ) { return; // Simply return from the include, so no FCKeditor code is run } </code> I am running MediaWiki 1.17 and the according released version of FCKeditor.
Created attachment 9404 [details] Patch for the issue I attached the patch.
Joerg, just a quick question, does the problem still happen with MediaWiki 1.18?
Hi sumanah, thanks for the question. I was not yet able to install 1.18 to test this. I hope that other work in my wiki is completed during this week and that I can install 1.18 next weekend. I will definitely keep you updated here.
Shouldn't make a difference between 1.18 and earlier since it's a bug in the FCKEditor low-level classes, it looks like. These really shouldn't be getting invoked unless the editor is in use, though.... but I don't really want to mess around with its internals. ;)
Ok looks like the loader code is doing this: // Initialize FCKeditor and the MediaWiki extension $fckeditor = new FCKeditor('fake'); $wgFCKEditorIsCompatible = $fckeditor->IsCompatible(); so...... that kinda defeats the purpose of a loader script not being supposed to execute stuff that might not work. ;) Lemme see if we can disable that.... r106129 should do the job, seems to work for my testing. Joerg, can you confirm?
Hi Brion, yes, your patch solves the issue as well! Thank you! :-)
