Extension talk:FCKeditor (by Mafs)/Archive

FCKeditor.php
Where is it? im think there is someting wrong with the layout. Is the text under "Finally check your FCKeditor installation:" the php code for FCKeditor.php?

Thanks

How can I add FCKEditor to Special:Emailuser
I wanted to add FCKEditor for Emailuser textarea but I have hard time to find out the entry point. What is the best way to do this, please?

Ypae 23:50, 23 February 2007 (UTC)

Cleanup HTML Tags on search results after using FCKEditor
Some of you might want to remove HTML Tags showing up on the search results after you integrate FCKEditor. You can strip off those tags just before it highlights the keywords as following:

On /includes/SpecialSearch.php, change the following:

 $line = htmlspecialchars( $pre . $found . $post ); 

to:

 $pre=strip_tags($pre); // Strip out any tags BEFORE the keywords $post=strip_tags($post); // Strip out any tags AFTER the keywords

$line = htmlspecialchars( $pre . $found . $post ); 

Ypae 23:58, 23 February 2007 (UTC)

Doesn't work with MediaWiki 1.90
Proth 13:41, 17 January 2007 (UTC) Fatal error: Call to a member function mergeArray on a non-object in D:\WikiCCHD\xampp\www\wiki\includes\Parser.php on line 622 Thanks
 * I've tested the configuration under 1.90, but received message


 * This has been discussed farther down on this page: http://meta.wikimedia.org/wiki/Talk:FCKeditor#Fatal_Error_on_Parser.php_using_MediaWiki_1.9


 * So far, no solution has been found.


 * --AdrienP 19:27, 17 January 2007 (UTC)

I just find out the error might have something to do with this part

$wgHooks['ParserAfterTidy'][] 			= 'wfFCKeditorBypassParserPaste';

in FCKeditor.php

If I have time, I will try to figure out, but most likely ... I don't have time.

My FCKeditor intergration will not need this function :D

--Mihu 19:34, 22 January 2007 (UTC)--209.76.245.64 19:33, 22 January 2007 (UTC)

I am having the same problem. The sample page shows up properly. However if i turn the $wgFCKUseEditor to true, it all breaks down. I cant even access the index page of the wiki. I am running the wiki on an intranet. Its on a Windows machine with WAMP server...Apache, PHP. The fact that the sample shows up means that there is something in the LocalSettings, or somewhere else thats broken.

Mihu if you can post something that would be awesome.

--24.39.146.178 19:59, 26 January 2007 (UTC)

Missing TOC in Mediawiki
Have installed FCKeditior to Mediawiki 1.7.1. Looks promising. I am facing couple of stumps - 1. After reformating the page with header 1 & header 2, i am missing mediawiki's TOC (which suppose to show once there are 4 sections in a page). What is the equivalent in FCKeditor format?

2. Still couldn't get the insert image icon to work. Solved the ajax error as suggested in this page but what is the format/syntax for inserting the image to the page? local url? or http?

Images/flash uploads for mediawiki
Are there some kind of FAQ, Guidelines or tutorial for setting up images and flash files uploads for mediawiki? Did anybody tryied to implement such functions?

1.6.2 Integration leaves both toolbars
I just finished fresh installing MediaWiki 1.6.2, and then followed the instructions to integrate FCKeditor. Oddly enough, both toolbars now appear. The wiki toolbar of course doesn't work in the FCKeditors editbox, but it still shows up. I am also still having the problem with FCKeditor not loading old versions of pages.


 * The toolbar issue has been fixed (see FCKeditor/function_editForm). Concerning your second problem I can only say that there are no problems on my installation, I also checked http://www.wikipage.org/wikinaut/index.php/WYSIWYG-Editor/Sandbox where editing old version does not appear to be a problem. Mafs 20:11, 11 April 2006 (UTC)

Oh, I also wanted to know if you are aware of this site toolswysiwyg.org, google translated from french, and their demonstration of FCKeditor integrated into Mediawiki. What I can't figure out is what method they used to integrate it. It doesn't seem to be the one listed here. Thanks again.

Opposite of __USE_EDITOR__
I'm using the line:

$wgUseEditor        = true;

So I have FCKeditor as the default editor of my Wiki.

Is there any way to designate certain pages to not use FCKeditor, like the opposite of a _use_editor_ tag?


 * There is a line in showEditForm

if (($wgUseEditor or eregi($wgEditorToken, $tbox, $eregi_result )) and $wgTitle->getNamespace != 8 ) {

which disables the editor in namespace 8. You can use this to exclude more namespaces. For excluding particular pages from using the editor you have to do some coding. Mafs 20:31, 10 April 2006 (UTC)

Again, thanks for the quick reply. I will do this after the update. It seems to me that the special namespace is best done like this too, from my own observation.

I haven't been able to modify this properly. What would be the correct code to exclude the Mediawiki namespace and the Special namespace?

The easiest way to set a namespace to use the mediawiki editor instead of the FCK editor is to go to your LocalSettings.php file and add the namespace you want excluded to the line that looks like this : $wgFCKexcludedNamespaces = array(8,1,-1);   // eg. "8" for disabling the editor within the MediaWiki namespace. You can find a list of what number refers to what namespace Here.


 * I've created two custom namespaces, 100 and 101. How do I add them to the array so that 8, 100 and 101 are all disabled from using FCK? --ivan, 20 Nov 2006

--Hi, I'm using Mediawiki-1.8.2 and FCKEditor 2.3.2 and I set FCKEditor as my default editor. If I want to switch back to wiki editor just for one particular page (Main_page), what should I do? You mentioned I need to do some coding, could you please tell me more details about the coding? Thank you. Hunglin 16:29, 19 December 2006 (UTC)

-- I was able to do this, a couple changes need to be made. You need to add to your LocalSettings.php:

$wgFCKNoEditorToken     = "__NOFCK_EDITOR__";

Then edit the FCKeditor.php and add the following:

In the "function wfFCKeditorCheck" you need to add at the top:

global $wgFCKNoEditorToken;

Then after the 1st preg_match section in the same function add:

if (preg_match("/$wgFCKNoEditorToken/i", $text, $a)) { $wgFCKUseEditor = false; }

At the top of "function wfFCKeditorBypassParserPaste" add:

global $wgFCKNoEditorToken;

Down farther you'll find a line like this:

$fcktext = preg_replace("/$wgFCKEditorToken/i","", $fcktext);

You need to add just below it:

$fcktext = preg_replace("/$wgFCKNoEditorToken/i","", $fcktext);

Then just add at the top of a Page, the token: "__NOFCK_EDITOR__" (or whatever you define as $wgFCKNoEditorToken).

This appears to work for the latest version. (0.7.2) Perhaps it can be incorporated into it? --Meddaugh 13:48, 24 January 2007 (UTC)

Escaping __USE_EDITOR__
Still related to the above question, I have a problem how to escape the __USE_EDITOR__ magic word just like the way I escape other magic words. I have used the  and   tag but they do not work. The wiki still use the FCKEditor to edit. I want to display __USE_EDITOR__ without being interpreted like other magic words. Is it possible? --Semut 04:52, 31 May 2006 (UTC)
 * On a page which does not contain the real magic word __use_editor__ you can display the magic word using this expression
 * &amp;#x5f;&amp;#x5f;use&amp;#x5f;editor&amp;#x5f;&amp;#x5f;
 * (to be copied directly from this html-page, do not use source text).
 * Mafs 09:00, 3 June 2006 (UTC)
 * But what about on a page that DOES contain the real magic word? DavidJameson 14:02, 4 August 2006 (UTC)
 * Then you just put __USE_ EDITOR__ when viewing in source mode. It will parse out the font portions and, because it is broken up, will not parse out the magic word. Paul Barkley 13:20, 23 August 2006 (UTC)

Mediawiki 1.5.8 + fckeditor 2.2
1. Thank you for your work! Its great! Please continue.

2. after all the patches i got

Parse error: syntax error, unexpected T_VARIABLE, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /usr/home/unknownplanet.ru/test/htdocs/includes/EditPage.php on line 841

rechecked editpage.php, everything done ok like in the instruction what could be wrong?

I ask you please just put patched files of 1.5.8v here, maybe its some free spaces problem like someone mantion. Mafs please!!!

What could be wrong?
I've just installed mediawiki 1.5.7, installed fckeditor, applied all the patches, but nothing seems to have changed. Even the __USE_EDITOR__ token shows up on the content pages...

I'm running on mediawiki 1.6.7, and had the same problem. I solved it by going to the link FCKeditor/extension copying and pasting the code into my /mediawiki/extensions/FCKeditor.php Also take careful note of the capitalization of the file names.

Not enduser ready
I am a SysAdmin and I would love to deploy a company wide wiki. The problem is that Mediawiki is only half ready for the enduser. The presentation aspect works, while the editor is hopelessly beyond the abilities of your average office drone.

So I for one am very eager to see this FCKeditor/Mediawiki graft go somewhere.

A few suggestions:


 * The __USE_EDITOR__ token should serve the reverse of it's current function. FCKeditor should be the default editor, and if the IT staff wants a special page like MediaWiki:Sidebar to use the "mediawiki editor" then they should place the token on that page.   Endusers will immediately delete something like that token no matter how explicitly you tell them not to.


 * Answer: Your can set $wgUseEditor = true; in LocalSettings.php. In this case all pages execept the pages of the Mediawiki-namespace will use the fckeditor.


 * Rebuttal: This solution can break functionality for end users on wiki instances using extentions that use wikitext format (eg: GNUPlot). Even while such pages can be edited with 'view source' in FCK, the FCK parser pulls out newlines and parses cheveron tags on subsequent edits.  Obviously, allowing users to modify php files so their wikitext pages work is NOT an acceptable solution.  Translation: Still not enduser ready.  --verlocs, 7.6.2006


 * While in editor mode, I get two sets of scrollbars, one for the page one for the editor box. This screws up users, as they use their mousewheel to reach to bottom of the article, loosing sight of the editor-toolbar....then they scroll up find the toolbar, loosing sight of the text they wanted to highlight.  While in editor-mode the vertical page-scollbars need to be disabled.


 * Sorry, I do not have a solution to this problem.

on a related note: the $wgEditorHeight variable does not seem to do anything on my install


 * This bug has been fixed in the new version of the function editForm (EditPage.php).

Mediawiki's little goto another page / upload your image / remember it's name / write some code  dance ...is never going to get used by average people. It should be possible to modify FCKeditor's dialog box so that it browses the user's machine instead of the server, and handles the upload.
 * The original FCKeditor has an insert-picture dialog which is enduser compatible.


 * This is related to above. Images need to be displayed while in editor-mode.  Endusers need that kind of feedback.


 * You are right. However, this would require a massive recoding of both the mediawiki and the fckeditor code, which I do not intend to do.

The sad truth is: Even idiots know something! If we can't get them to use a wiki, it won't fulfill it's potential.

- Martin


 * Martin, thank you for your contributions Mafs 16:42, 3 December 2005 (UTC)

Doesn´t this work for Mediawiki 1.4?
-Josh

P.S.: Will there be any support for (more complex) formulas in FCKEditor in future?


 * See the page Computer algebra. This extension also works when using the fck editor. Mafs 19:57, 1 March 2006 (UTC)

links and images
has anyone gotten links or images to work correctly with FCKeditor in 1.5 of mediawiki?

if i insert a link, it looks fine in the editor, but when i view the page, it's like a link within a link. if i do view source, it looks like this:

&lt;a href="http://www.yahoo.com"&gt;

i know i'm probably missing something simple here. has anyone gotten this to work?


 * Image links and other html tags (eg ) are not allowed on a (media)wiki page. Therefore, you cannot add such tags using the fckeditor. However, you can upload an image and you can refer to that image using normal wiki syntax: eg [[image:example.jpg]] . For links you can write.
 * The fckeditor is just semi-wysiwyg.
 * Markus


 * i understand that it is currently semi-wysiwyg. but can i configure it to be full (or 90%?) wysiwyg in mediawiki?  i almost had it working, but then all the mediawiki text (in the database) links were messed up.  i'm just trying to implement this without my users having to learn a whole new markup (not very technical).  i'll keep plugging away in the meantime!  thanks for your help.
 * steve

by the way, i found this extension which accomplishes what i was trying to do:



steve

FCKeditor doesn't allow you to use wikipedia markup extensions on your pages. I've created a new tag called expand_info which works perfeclty on pages I edit without FCKeditor but I can't use the tag if I use FCKeditor because of course its enclosed in < >. Is there anyway of telling FCKeditor to allow certain wiki tags through? Steve A


 * This should work. Please check whether your patched function strip contains the section

# Extensions foreach ( $this->mTagHooks as $tag => $callback ) { $ext_content[$tag] = array;

# patch if ($wgUseEditor) { TWO PREG_REPLACE CALLS WHICH CANNOT CORRECTLY BE DISPLAYED ON THIS PAGE. }
 * Mafs 19:54, 1 March 2006 (UTC)

It was in there and it wasn't working. However I started digging round in EditPage and found that Johan has made a modification to handle tags properly. If I put expand_info into there (to flag it as a tag) and modify the Extensions preg_replace so it matches the nowiki handling code (which uses the html code for the less than and greater than tags) then expand_info is parsed and handled correctly. This however doesn't work if you have arguments inside the opening extension tag (which is allowed in extensions) because the preg_replace strings look for $tag which is the text of the tag, not the complete tag - so we need to work out what the full tag is (including any parameters inside the opening tag) BEFORE we do the preg_replace for the opening tag, and that needs to be done in both EditPage.php (which currently has no way of identifying extension tags) and Parser.php Steve A


 * Sorry, for my note from the 1 March. I did not copy the code from the source text (!) and therefore it was wrong. I have reverted the function strip page as special characters are not correctly be displayed on the page. Mafs 18:17, 22 March 2006 (UTC)


 * The "\s*" statement within the preg_replace call could be replaced by ".*?". Than the extension tag should be correctly treated. However, I have not tested it Mafs 18:17, 22 March 2006 (UTC)


 * If you do that then the following happens: Edit the page in the editor, change the opening tag so it its tagname arg=value, save the file and it renders perfeclty. Go back in and the opening tag is just the tag name again as the preg_replace call matches tag arg=value and replaces it with tag.   So we somehow need to ensure that the $tag in the replacement part of the preg_replace contains everything between the tag limiters and not just the tag name. Steve A 20:25, 22 March 2006 (UTC)

This should not happen as the parser function does not alter the text of the database. However, the preg_replace call should not be applied in the editForm function. Mafs 17:59, 25 March 2006 (UTC)


 * Doesn't work - I'm giving up on it. I suspect that unless the GUI editor uses Wiki markup natively rather than munging it in and out out HTML formats its never going to work properly and its always going to be a fudged job. 84.51.153.46

full wysiwyg
hi steve,

you must be aware that enabling raw html to be used on your wiki renders the wiki unsecure. However, if this is not a problem to you, you can also apply this patch

$wgRawHtml = true;

$wgHooks['ParserBeforeStrip'][] = 'wfRenderYourWikiUnsecure';
 * 1) REGISTER HOOK

function wfRenderYourWikiUnsecure ($q, $text) { global $wgRawHtml;
 * 1) HOOK FUNCTION

if (preg_match("/__use_editor__/i", $text, $a) and $wgRawHtml) { $text = preg_replace("/__use_editor__/i", "", $text); $text = " ".$text." "; } }

which could be placed in LocalSettings.php and which allows any htlm tag to be used on a wiki page. I would never use this patch or the patch you pointed to on a public site.
 * Mafs 16:43, 14 October 2005 (UTC)

thanks for the information. at this point, the potential for a breach of security is not much of an issue. but i will definitely keep it in mind as my experimentation continues. right now, this is not being used on a public site.

steve

error`
Hi gang, I've copied the changes into the files both from the html and from the edit page and consistently receive this error:

Parse error: parse error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in D:\content\mediawiki-1.5rc4\includes\EditPage.php on line 1021

have you seen this and does it mean anything to you? thanks!


 * Answer: The patches cannot be applied to the rc4 version. I will prepare fresh patches for the current version (1.5.2), however, it will take some times (days). Mafs 21:08, 9 November 2005 (UTC)

Hello again, fixed the error above by editing in a text editor that took out extra spaces. However, now eregi function is emtpry. I'm using MW1.5rc4 and compatible FCKeditor (editor works in the sample page). why would the function be empty? I'm obviously not filling it, but can't figure out where it's supposed to be set? thanks!


 * Answer: I would recommend that you upgrade to mw 1.5.2 and that you use the corresponding patches which I have just published. Mafs 19:36, 12 November 2005 (UTC)

Undefined variables
When I edit a page, using FCKeditor or not, I get the following Notices at the top of the website:


 * Notice: Undefined variable: tbox in c:\program files\easyphp1-8\www\eccwiki\includes\EditPage.php on line 590


 * Notice: Undefined variable: toolbar in c:\program files\easyphp1-8\www\eccwiki\includes\EditPage.php on line 724

Also, I cannot see the standard edit toolbar on non-html pages.

they both seem to come from the patched editpage function. Can you tell me what might be going wrong?

Another issue that may be related..i get a error on math functions as follows:


 * Failed to parse (unknown error): \sqrt{1-e^2}

Jason

Update:

Fixed the standard toolbar, by restoring this patch that was recently updated:

Current version:

# patch fckeditor global $wgUseEditor, $wgEditorToken; if ($wgUseEditor or eregi($wgEditorToken, $tbox, $eregi_result ) ) { if( $wgUser->getOption('showtoolbar') and !$isCssJsSubpage ) { # prepare toolbar for edit buttons $toolbar = $this->getEditToolbar; } else { $toolbar = ''; }               }

Restored version:

# Patch for FCKeditor global $wgUseEditor, $eregi_result, $wgEditorToken; if ( $wgUseEditor || ( isset($wgEditorToken) && eregi($wgEditorToken, $this->textbox1, $eregi_result ) ) ) { $toolbar = ''; } elseif( $wgUser->getOption('showtoolbar') and !$isCssJsSubpage ) { # prepare toolbar for edit buttons $toolbar = $this->getEditToolbar; } else { $toolbar = ''; }

Looks like the only issue I have now is the math tags. I dont know it this is caused by fckeditor or not as I never tried to use them before.

Made a FCKeditor patch from the diffs
After a bunch of work, I succeed in actually making a patch for FCKeditor on mediawiki 1.5.2 with the above change. It works ok but whenever the __USE_EDITOR__ tag is on, the wiki formatting is totally ignored :( So Im probably not going to even use the patch until this is fixed

The patch is meant to replace all of that tedious mucking about with the include/*, Smiley.php, and skins/monobook/main.css.

cd wikidir patch -p1 < ../FCKeditor.patch.txt
 * 1) Install FCKeditor yourself and make sure it works like normal.
 * 2) Apply the patch by.
 * 1) Modify the LocalSettings.php as per Mags instructions.

Cheeers, Ben

"The wiki formatting is totally ignored"
So it is intended, however, the patched file Parser.php contains several statements like

if (!$wgUseEditor) $text = $this->doBlockLevels( $text, $linestart );

which supresses the wiki formatting. Feel free to remove "if (!$wgUseEditor)" and watch the result.

Thank you for the diff          Mafs

I tried this and it didn't seem to make any difference. Then I put back the original Parser.php (i.e. without the FCKEditor mods) and it doesn't make any difference either! - Steve

Using $wgUseEditor = true in the LocalSettings.php file
Works well but any pages in the Help Area which I downloaded from wikimedia dont work! Is there any way to exclude these pages from being processed? Actually is there any way to make it only apply when the namespace is the main namespace (0 in the Database?)

I have confirmed that setting the $wgUseEditor flag to true is what is causing the problem. The problem seems to be in the Parser.php code. If I put the original version back in then it all seems to work fine... including the editor. But no doubt I'll find some problems!


 * Answer:
 * You can specify exeptions by changing this line in function editForm (EditPage.php)

if (($wgUseEditor or eregi($wgEditorToken, $tbox, $eregi_result )) and $wgTitle->getNamespace != 8 ) {


 * eg

if (($wgUseEditor or eregi($wgEditorToken, $tbox, $eregi_result )) and ($wgTitle->getNamespace != 8 or $wgTitle->getNamespace != 4) ) {


 * Mafs 19:14, 4 January 2006 (UTC)

Canges
Where must i change the things from "Adapt the 1.5.2 - mediawiki script" ?

UNIQ_PREFIX error
Notice: Use of undefined constant UNIQ_PREFIX - assumed 'UNIQ_PREFIX' in [wikidir]\includes\Parser.php on line 818

I get this error since launching the changes though I'm oblivious to what it's in reference to. Examining the code does not help and I'm running 1.5.5

1. Googled it and found that adding the following line to the parser.php script did the trick

define( "UNIQ_PREFIX", "NaodW29");
 * 1) prefix for escaping, used in two functions at least

Formatting dropped when adding __USE_EDITOR__ Tag
I've encountered an odd error whenever including the __USE_EDITOR__ tag. it seems my wiki formating for the page I add it to is dropped.

Basically things that used to be on multiple lines are now all compressed onto one.

Any suggestions? I'd like to be able to turn the editor live on all pages but i'm afread of losing all my formatting and having to go back and redo every page

I'm having the same problem, does anyone have a solution? Thanks. - C

same problem :-( Thanks henning


 * For copying wiki text into the FCKeditor try one of these [[image:icoFCK.png]]. After copying you will see the raw wiki text. If you want to automatically convert raw wiki text into html text editabe by the FCKeditor your will have to write some code. Mafs 21:16, 2 August 2006 (UTC)
 * If you want to use the magic word in Javascript (like monobook.js) and don't want to mess up the JS code, break up the magic word into pieces. Example: Create a variable for the "_" character ("var sUL = '_';") and use that in your code like this: "document.write(sUL+sUL+'USE'+sUL+'EDITOR'+sUL+sUL);". It's a lot of code and nothing you want to use over and over again, so better store the whole thing in another variable like "var sFCKmw=sUL+sUL+'USE'+sUL+'EDITOR'+sUL+sUL;" and use the new and short "sFCKmw" variable whenever needed.--Cumbrowski 03:08, 16 December 2006 (UTC)

WYSIWYG: A leap for mediawikis :O)
I agree from a developer standpoint that WYSIWYG can be a very tedious thing to integrate into Wikis and CMS systems, but as an end user I really look forward to them. I think WYSIWYG editors will bring in more new comers who were scared at first because they don't enjoy seeing markup. I believe the hardwork required to do this task will be well worth it. :O) --Depakote 07:18, 25 January 2006 (UTC)

I think they can easily make it work but they chose not to. I think it's sort of violate with the original concept of wiki. They are trying to avoid fancy css stuff. It's not realli nice to ask them to change their target to joy majority population.

Is this working with mediawiki 1.4.4 ?
Running Mediawiki on a System
 * MediaWiki : 1.4.4
 * PHP      : 4.2.1 (apache)
 * MySQL    : 3.23.41

I would like to kindly ask if it's possible to get FCKeditor running. FCKeditor (php) is working fine. As there is already a lot of "productive" data on this system, I don't want to play around too much.

Any help greately appreciated.


 * Sorry, I do not have a version for MediWiki 1.4.4. But I am sure the patches can be adapted for this version. Mafs 19:39, 26 February 2006 (UTC)

How to enable default wikisyntax for pages in NS_SPECIAL
integrating the FCK Editor removes/disables the parsing of some wikitags. The tags for links and some more are still parsed but I'd like to parse at some specialpages headline, lists and such things with the default wiki syntax. Is there any chance to get mediawiki default tags (like ==text==) working again for the pages in the namespace NS_SPECIAL?

Thanks

alx


 * Anwer:
 * Hi alx,


 * You can disable the editor-support for specified namespaces in "LocalSetting.php" in the variable
 * see

Star 12:50, 21 August 2006 (UTC)

MediaWIKI 1.5.7 and FCKEditor 2.2
I'm trying to run FCKEditor on following System :

unning Mediawiki on a System
 * MediaWiki : 1.5.7
 * PHP      : 4.4.0 (apache)
 * MySQL    : 4.1.13

I'm a beginner in PHP - so i'm modified all the php scripts, as shown in the tour to run the FCKEditor 1.5.2.

The FCKEditor STandalone works fine - but when i try to edit a page on my WIKI, i get a warning Popup "Toolbar set "WIKI" doesn't exist !" - and an empty Toolbar is show on top of my Page to edit.

Hope someone can help in this case. Thanks


 * Do not forget to adapt the fckconfig.js file,
 * see http://meta.wikimedia.org/wiki/FCKeditor#Install_FCKeditor


 * Ran into the same problem - the fckconfig.js was already properly adapted. I had to remove the line $wgFCKEditorToolbarSet  = "Wiki"; from LocalSettings.php

I tried to patch 1.5.6
Worked a little bit,

errors right after patching all the php files Notice: Use of undefined constant UNIQ_PREFIX - assumed 'UNIQ_PREFIX' in includes\Parser.php on line 366 after adding the lines from above, (the patch for UNIQ_PREFIX) it went away.

couldn't get this to go away after editing Notice: Undefined variable: eregi_result in C:\htdocs\mediawiki-1.5.6\includes\Parser.php on line 210

I also could not get it to display 'old' wikitext formated content, even after deleteing the line:

if (!$wgUseEditor)

Can FCKEditor and Mediawiki editor work simutaneouly
Some folks in my company prefer FCKEditor to be able to work on Excel-like tables, but others prefer the media editor. Is there any way to let them work simutaneously? I already found out if I use FCKEditor to edit an article that was entered through wikiEditor, then all formats are screwed up, specially links. I have to manually fix the links. Any suggestions for such conversion? Thanks a lot.


 * The answer to your question is "no". The links are a problem, the tables are another problem, as the fckeditor formats the raw html code by inserting blanks. Therefore, any mediawiki syntax which has to be placed at the beginning of a line, eg, ":", does not work anymore. Mafs 17:48, 25 March 2006 (UTC)


 * Another answer is "maybe". See FCKeditor and HTML::WikiConverter.

Is FCKeditor in MediaWiki 1.6
According to MediaWiki roadmap, FCKeditor is in 1.6 which is running in WikiMediaCommons. However, when I insert the __USE_EDITOR__ line in the sandbox and save the edit, I don't see the FCKeditor buttons in subsequent edit pages of Sandbox? Am I missing something?


 * This editor is _only_ in my special version called EnotifWiki see http://www.enotifwiki.org . --Wikinaut 19:00, 7 April 2006 (UTC)


 * Is there an updated roadmap for the integration of FCKeditor into the mainline MediaWiki releases? -- Jonathanking 00:55, 11 April 2006 (UTC)


 * I don't know. Mafs 20:11, 11 April 2006 (UTC)

Mediawiki 1.5.8 and FCKEdi 2.2
Hello, I#d tried to patch mediakwiki to use the FCKEditor 2.2 but I got some errors. Can you help me to correct these problems?`

Thanks

WYSIWYG: Mediawiki versus TWIKI
I agree with you, WYSIWYG is a very important point for a "general" user(Editor). We love to use Wiki's in both ways, natural(Wiki-Noation) and WYSIWYG(for tables). You have done a great work.

What i have seen, is a very nice idea form the WYSIWYG-TWiki-Developer. They save the result in TWIKI-notation. The Concept sounds like this:
 * transform WIKI->HTML
 * user can edit in WYSIWYG form
 * transform from HTML->WIKI

My question: Can you think about this concept?

http://twiki.org/cgi-bin/view/Codev/TWikiVMDebianStable (TWiki 4.0 as VMplayer-Image)

Servus form Vienna

---

Yes, you definetly can do it. I am using it but you need to install lots of stuff. --Mihu 22:42, 9 February 2007 (UTC)

Allowing wikitext to be used
Is there a way to also allow wikitext to be used simultaneously? Now I have to edit every single system page as well to make sure it looks good, and I can't even find all of them!
 * I added the Special Namespace to the $wgFCKexcludedNamespaces array where most of the system messages are in addition to MediaWiki and Talk Namespaces. That fixes the pages like the search page where the wiki markup is used for headers and bold words.

$wgFCKexcludedNamespaces = array(8,-1,1);

Reply: Thanks a lot! This is exactly the information I needed. Just to make thinks clearer I'll say that you've got to add that line ($wgFCKexcludedNamespaces = array(8,-1,1);) in mediawiki/LocalSettings.php. The Sidebar menu, for instance, WON'T WORK when editing with FCKeditor (that was my problem)

Opera: bug/feature request.
FCKeditor fails in my favorite browser - Opera v8.54. Are there any plans about extending compatibility?


 * The FCKeditor is compatible with IE 5.5+ (Windows), Firefox 1.0+, Mozilla 1.3+ and Netscape 7+. Please consult http://www.fcdeditor.net directly for investigating whether there are any plans about extending compatibility. Mafs 09:20, 20 May 2006 (UTC)

bug found
When enabling user js and user css,the page for editing them will appear two fckeditor interface,for example http://yourdomain:port/wiki-path/User:Tony/monobook.css?action=edit  --148.235.86.114 02:08, 16 June 2006 (UTC)

Need for an 'FCK-mode' button
This isn't so much a specific bug but a general complaint about the mediawiki-FCK implementation. Yes, I'm aware of the general architecutral distinctions between HTML and wikitext and that FCK uses the former. That said...

Our wiki has (and increasingly will have) a number of users of various levels of expertise with using wiki and code languages in general. FCK of course is a good tool for those not familiar with using wikitext, but has the tradeoff of breaking wikitext functionality when used as the default editor. Some of our existing wikitext tables and wikitext code for other extensions would be broken if we went to FCK as the default editor.

For the moment we're using the 'by page' use editor flag. This is an acceptable solution, but not one we're particularly happy with since the whole point of having FCK is to make it easier for inexperienced users to create pages, but we don't want to do that at the cost of creating hassle for our experienced users.

The solution we'd like to see created would be an extension FOR this extension that would add an "FCKeditor" button to the default mediawiki editing buttons that a user could click enable FCKeditor. In a sense, we want FCKeditor to ALWAYS load, but be inactive until told to become active.

Of course, such functionality we could write ourselves, but honestly this is an oversight that should have been addressed as part of the development process, since the whole point of FCK is to eliminate code, but it forces a user to INPUT code to eliminate code (We do not see the exclude page solution as a viable solution since it makes it hard for users to create pages that use more powerful wikitext statements (such as statements for extensions)).

A good example our deployed gnuplot extension instance. GNUPlot for wiki statements, in wikitext, look like this: set output 'func_approx.png' plot '-' using 1:2 t 'quadratic approximation' with linesp lt 1 lw 3, \ '-' using 1:2 t 'cubic approximation' with linesp lt 2 lw 3 1 2 2 4  3 8  4 16  e  1 3 2 9 3 27  4 81  e

But when editing the page with FCKeditor, the gnuplot tags get moved around and all the newlines come out. (This is from the source view): set output 'func_approx.png' plot '-' using 1:2 t 'quadratic approximation' with linesp lt 1 lw 3, \ '-' using 1:2 t 'cubic approximation' with linesp lt 2 lw 3 1 2 2 4 3 8 4 16 e 1 3 2 9 3 27 4 81 e

We can reconstruct the first statement in source view with FCKeditor, but subsquent re-edits cause the same parsing issues. So from our perspective it looks like FCK isn't just not respecting some wikitext statements, but actively going out of it's way to break them by pulling out newlines and moving tags, which we feel it shouldn't be doing.

Not to mention that losing the regular wikitext format header statements is annoying. We have a saying where I work: It's not a step forward if someone else has to backtrack. That's sort of how we see FCK editor right now. Ideally, FCK should be transparent, so users can enter wikitext at will and have it be evaluated normally regardless of other formatting considerations. --verlocs, 7.6.2006


 * I completely agree with your analysis and I would be happy to see your end user ready implementation. Mafs 20:54, 6 July 2006 (UTC)


 * Fixed the extension problem (hopefully). Mafs 20:43, 7 July 2006 (UTC)

Possible desicion
As far as I know, FCKeditor doesn't understand wikitext at all. That's the reason why I've started my developments.

The key idea is to use visual editing in addition to standart and let's the user choose desired one. It can be archived by adding "Use visual editor" checkbox. When checked this checkbox triggers wiki2html transformation. The most suitable tool for that is InstaView. So, the user can visualy edit the articles.

When the checkbox's state is turned to unchecked js transforms html back to wikitext. The back transformation is also triggered on page save. I'm working over it now. Some results can be found at Wikificator's page.

So, in spite of the fact, that FCKeditor can't be used for wikitext editing, we can use it as a html-editor and then transform it's output to wikitext.

PS. Any feedback is apreciated. If you have some interesting idea - mail me. Another variant is to find me on irc://irc.freenode.net#mediawiki --Shtriter 21:11, 6 July 2006 (UTC)


 * This is an ambitious project. Not easy to implement and really complex to maintain. Mafs 20:43, 7 July 2006 (UTC)


 * Maybe so. But taking into consideration the open-source nature of each component, it can be maintained by the contributors of these separate projects and I'll try to bind them in one working tool! At that very moment I can easily set html for FCK editor that was generated from wikitext and transform it back to wikitext (no images and paragraphs transformations yet...). So, I'm full of optimistic ideas! --Shtriter 10:34, 8 July 2006 (UTC)

First beta released!
I've released the first beta version of wclEditor.

It's rather limited yet, but even now one can see the idea's potential! First of all, I want to say that this version has only demonstration purpose. FCKeditor breaks the formatting. I've partly solved it adding  as a line-break token, but FCK also adds spaces at the each line...

So if somebody knows how to make FCK preserve the formatting, please tell me - it is one of the biggest problem of wclEditor. However the testing of InstaView and Wikificator showed no diff's when comparing with the source wikitext. Also IV's output was successfully compared with MediaWiki's (at list paragraphs,, tables and simple lists).

I've also managed to use MW's monobook.css in FCKeditor. All we need to do it is to copy the contents of desired skin (i.e. monobook.css or main.css) to the end of the FCKeditor\editor\css\fck_editorarea.css If you also want FCK to use the skin's images - replace all occurances of "url(" with smth. like "url(/skins/monobook/". Customise it as you want and have fun using the best HTML-editor!

I realy do need the feedback and I will be glad to see any code improvements! --Shtriter 12:40, 28 July 2006 (UTC)

I would just like to say that i think this is a brilliant editor the best i have ever seen, keep it up. The only problem is the removing of line breaks. surely this can be solved. You have created something people probably said was impossible a few years ago and im no expert but couldnt someone write a simple function to handle the line breaks. it might go something like this

When the fckeditor reads the wiki page and parses the text into html. instead of removing the line breaks why no convert them into a special tag that fck understands and preserves but also ignores when inside an html tag. when the editor saves the page, return the special tags back into line breaks and everything is back to normal. i havent got a clue how you would do this i tried learning php but i have another degree to think about and dont have the time to learn it. If this cant be achieved then FCKeditor for all its benefits cannot be used on wikis. It is counterproductive as you keep loosing the formatting.

One Solution (In Progress)
This an experimental solution I'm working on is modifying the FCKeditor.php file and how it executes code.

The avenue I'm taking is that I want the following cases:

1) Existing WikiText Pages will always load the mediawiki editor to prevent loss of functionality. 2) New pages will always load the FCKeditor. 3) Subsequent reedits to pages using FCKeditor will continue to use FCKeditor until indicated otherwise.

I'm working on using the $text parameter to do this by adding in the flag to new pages. --verlocs 7.7.2006


 * I'm looking forward to seeing the outcome. Mafs 20:43, 7 July 2006 (UTC)

Issues with FCK installation
I'm currently developing a Mediawiki installation and I was hoping to implement some more robust WYSIWYG support with FCK as a good portion of my user base is likely to be intimidated by code.

My problem is that I installed the FCK software just fine, made the FCKeditor.php file and added the appropriate lines to my Localsettings.php and now my wiki will not display at all, period. If I remove the code from the Localsettings file, it all works again.

Has anyone ever encountered this before?

PS: I'm using MW 1.6.7 and FCK 2.3

--Dave Pace 20:41, 8 July 2006 (UTC)


 * Some checks:
 * Are the directories and file names correct and consistent?
 * Did you copy the code for FCKeditor.php in edit mode?
 * Does the code in FCKeditor.php start with "" ?
 * Can you access the FCKeditor sample pages?
 * Mafs 06:32, 9 July 2006 (UTC)

As far as I can see everything is consistent. I can access the sample pages so I assume the problem has to be either in the extension or in the Localsettings, I'm just not sure what exactly I've managed to do wrong here or what I might not be seeing. I'm somewhat of a neophyte when it comes to php, so it's entirely possible I'm just not getting something.

--Dave Pace 03:58, 10 July 2006 (UTC)

I had the same problem as Dave, and found that having my $wgScriptPath = "" and FCKConfig.mwScriptPath = ""; was causing the problem. Unfortunately I could not use "." for them, probibly because I am running my wiki on a windows server instead of a linux one, so I had to direct IIS to the directory above the wiki and use /mediawiki as the script path. If anyone can think of a better way to do that I'd be greatfull.

--Paul Barkley 17:07, 16 August 2006 (UTC)

ajax request error
I'm using MW 1.7.1 and the FCKeditor itself works like a charm with it. Sadly, the image inserting/formatting doesn't work, all I get is a "ajax request error" after typing some chars.

Has this something to do with a wrong FCKConfig.mwScriptPath-Setting? I tried everything with that, as my $wgScriptPath is empty.

Thanks in advance.

Answer: yep you set the FCKConfig.mwScriptPath-Setting wrong.Dont leave it empty, pu atleas a dot. Now if you use the WYSIWYG Editor and use the tool to choose images you get an ajax error this occurs if you have set the wrong path in FCKeditor/fckconfig.js --> FCKConfig.mwScriptPath = "."; Set this variable to point from your root into your wiki folder. its "." if the wiki is in the webservers root otherwise something like "/mediawiki"


 * Thank you!. Seems like the FCKeditor doesn't like absolute paths, as I didn't have any luck with them. Anyhow, your solution works great. Thanks again.

I'm having this same problem with the latest releases of mediawiki and FCKEditor. THe image upload never did work for me, but more importantly the search on the image editor page comes up with that ajax request error. I modified the code of the fckconfig.js to isolate the error message is generated from function Searching_SetResult(result) {	//patch : remove first byte if (result.substr(0,1)==":") result = result.substr(1, result.length-1);

pat = /]*hidden[^>]*wfSajaxSearchImageFCKeditor[^>]*>/ if (!result.match(pat)) result = "ajax request error, yes this is it.";

I checked my mwscriptpath, which is set to /wiki/ and if I change it it stops working altogether. It also doesn't work in the _sample, so I'm really stumped. Is this a problem with FCK that has crept in and not been identified, or does someone know a fix on what I might have done wrong?

Doesn't work for me either
DavidJameson 14:57, 31 July 2006 (UTC)

Just installed everything - updated appropriate files, etc, etc.... but putting __USE_EDITOR__ seems to have no effect whatsoever - the standard mediawiki editor window always shows up. I also tried setting $wgFCKUseEditor to true in LocalSettings.php but that didn't work either. I looked at the source view after opening for editing but didn't see any references to any FCKeditor javascript code being pulled in.


 * In edit mode you should see some like

  function onLoadFCK { var oFCKeditor = new FCKeditor('wpTextbox1') ; ...

If I have time, I'll use PhpEd and try and debug this but I'm hoping that someone else has already seen this problem. I've written a number of other extensions for our wiki so I'm pretty familiar with the basic process. We have made very minor modifications to the main skin (monobook) to support some special toolbox entries but nothing else.
 * By the way, the normal test FCKeditor/_samples/default.html works fine so the problem is just that the mediawiki is not invoking FCKeditor, but I don't know why.


 * A first stupid question: Does your LocalSettings.php file contain the line

require_once("extensions/FCKeditor.php");
 * Such questions are never stupid but yes, I am including that line.


 * Do you use at least mw 1.6.x? Do you use other extensions which use hooks? Do all the corresponding hook functions return true at the end? Mafs 16:20, 31 July 2006 (UTC)
 * Ah - my version of MediaWiki is 1.5.8 it never even occurred to me that I had too old a wiki. I'll look into updating it (and hope I don't break anything else) DavidJameson 17:24, 31 July 2006 (UTC)


 * The hook $wgHooks['EditPage::showEditForm:initial'][] was introduced in 1.6. This hook adds the above mentioned js script to the output. Hence, upgrading would be a good idea. Mafs 19:12, 31 July 2006 (UTC)
 * Yep - I upgraded to the new 1.7 version and the editor works now. I had in fact discovered that the hook wasn't being triggered but hadn't figured out why until you pointed out that I might have had too old a version. Thank you so much for your quick responses - much appreciated. DavidJameson 20:42, 31 July 2006 (UTC)

'''Ajax request error. The next one. ''' Hi there, as of today (2006-11-20), I've got exactly the same problem My wiki resides in folder /it and I've set FCKConfig.mwScriptPath to FCKConfig.mwScriptPath = "/it"; I still get the error. My setup: (MediaWiki: 1.8.2, PHP: 5.1.2 (isapi), MySQL: 4.1.15-nt, Extensions: fck/mw-extension (0.7.2) 2006))

Any help is appreciated.

Same problem to me ajax request error.

Still broken: MediaWiki 1.8.2
Yep, same thing here: "ajax request error." -- Neverhood 03:01, 22 December 2006 (UTC)
 * MediaWiki: 1.8.2
 * PHP: 5.1.5 (cgi)
 * MySQL: 4.1.18-standard-log
 * fckeditor extension (version fck/mw-extension (0.7.2) 2006), integrating the fckeditor, by Mafs
 * FCKConfig.mwScriptPath = "/wiki";

How do I insert characters?
I'm trying to write some entries that explain the use of extensions. However, if I use the characters normally, the tags get processed (which is fine) but I found that I can't use the & lt ; syntax because that just gets escaped as well (i.e,  the & gets turned into & amp    etc., etc.) DavidJameson 14:49, 2 August 2006 (UTC)


 * Use the TeX Box  ;-)
 * for creating a png like [[image:mathTagFCK.png]] = $$<\mbox{math}>$$
 * Mafs 21:23, 2 August 2006 (UTC)
 * That's not a good solution - images are not searchable. FCKeditor needs to have an escape mechanism that allows literal characters to be inserted without interpretation. I think the problem I'm finding is that wile FCKeditor is a wonderful idea and well implemented so far, it has a few serious corner cases that unfortunately prevent it from actually being usable at all - at least in our environment. For example, apart from the need to to allow literal characters, the FCKeditor doesn't recognize(as far as I know) things like ==, ===, and so I can't create sections with an automatic table of contents at the top, for example. DavidJameson 13:21, 3 August 2006 (UTC)
 * As another example, I couldn't even write a page with FCKeditor to tell people that FCKeditor is available and how to use it. When I tried to explain that you have to insert __USE_EDITOR__ to make it work, the completed page hid that "word".


 * Thanks for your comments, have a look at the content page FCKeditor and search for the keywords "maturity", "headings" and "escaping". Mafs 20:49, 3 August 2006 (UTC)
 * Oh, I'm already familiar with that content page. I apologize if you misunderstood where I was coming from. I understand completely that the extension is experimental and I wasn't trying to be destructively critical. I guess my comments were intended to point out (or perhaps prioritise) key issues that need to be addressed to make FCKeditor really usable on a daily basis. DavidJameson 13:50, 4 August 2006 (UTC)


 * By the way, while the TeX editor itself is very nice, we've found that we can't depend on the &lt;math> &lt;/math> extension because the version of TeX supported through that extension is missing too much stuff, so we're back to using MimeTeX. DavidJameson 13:22, 3 August 2006 (UTC)

Magic words do not seem to work.
When I add magic words like I still get the TOC and the magic word gets printed. Is there something I need to do so the mediawiki magic words work with the FCKeditor?


 * This had been broken in mw 1.7 and should now be fixed, please use new version of FCKeditor/extension. Mafs 20:52, 3 August 2006 (UTC)


 * Thanks, works like a charm now. Kaehler 17:36, 4 August 2006 (UTC)

Pasting Microsoft Word documents
I was excited to discover that pasting a document from a Microsoft Word window almost works perfectly. During editing, the Word document seemed to display just fine, complete with the image that was in the document.

When I saved the wikipage, I ran into some issues.

1) Minor - there were tags of the form  displayed, representing paragraphs in Word. This is easily fixed.

2) Major - the URL of the pasted image reflected its location on my local drive, meaning that other people who look at the page won't get the image. Could there be a way to have FCKeditor automatically upload the pasted image during the Save process?

This would be a phenomenal feature.

-- DavidJameson 13:57, 7 August 2006 (UTC)


 * It could work, maybe, provided that you allow some script to access your local drive! In any case, I will not work on this feature. Mafs 20:09, 28 August 2006 (UTC)

Making lists inside of lists
When you make a list inside of a list, it displays correctly inside of the editor, but when you save the page it shows the "  " and "  " tags instead of making a list inside a list. I found a workaround: you go into the "source mode" and delete the  at the very end and insert it right after the text after the  tag, everything works. As this is not a very clear discription, I'm going to show you: <ul> This is in the first list. If you now close the tag it works</li> <ul>This is the second list</li></ul></ul> The reason why this workaround is not sufficient is that when you exit the source mode and save, your changes will be reversed by the editor. This essentially means that you can never edit the page again without breaking your list.

A fix would be nice.

Almost forgot: I'm running MediaWiki-1.6.8 and FCKeditor-2.3.1.


 * I could not reproduce your findings on 1.7.1. Mafs 19:48, 28 August 2006 (UTC)
 * I'd have to say that I'm in agreement that there is a bug in the editor. Although the source of the problem is not accurately described.  Basically, the editor is messing with the placement of the close tag </li> or it's messing with the insertion of the <ul> block.  For example:

EDITOR SOURCE <ul> Test first list <ul> Test second list</li> </ul> </li> < erroneous end tag </ul>

CORRECT SOURCE <ul> Test first list</li> < correct place to place end tag <ul> Test second list</li> </ul> </ul>

Windows Script Error
I have installed FCKeditor 2.3.1 on Wikimedia 1.7.1 as per the detailed instructions and for the most part works quite well until I select the Image button on the toolbar and I get the following script error message...

Line 727 CHAR: 1 Error: expected '}' Code: 0 URL: http://205.189.23.16/wiki17/FCKeditor/editor/dialog/fck_image.html


 * Add the expected '}' at the end of the file fck_image.html. ;-)
 * Hopefully, this will solve also the next error. Mafs 19:05, 28 August 2006 (UTC)

When I agree to continue I get the following message:

Line:30 Char:1 Error: 'window.parent.FCKConfig.SkinPath' is null or not an object Code:0 URL: http://205.189.23.16/wiki17/FCKeditor/editor/dialog/fck_image/fck_image_preview.html

When I agree to continue the script I do get the Image Properties popup box however although there is a search image box there is no way to browse to an image. Any help is appreciated.

Rene Paquin August 10, 2006

Use of ArticleSaveComplete Hook
I wan't to use the FCKeditor extension and a own extension, that inserts information into the db. Therefore i call a function by the ArticleSaveComplete Hook and extract the content of my extension with

function saveTasks( $article, $user, $text ) { ...   Parser::extractTagsAndParams( array('tasks'), $text, $matches); ... } But in $text the  -tag  is already escaped and can't be found by extractTagsAndParams. How can i get this tags in my extension? Can i use another hook instead?


 * I would suggest that an other hook be used, which is called before the paser hooks. Mafs 19:07, 28 August 2006 (UTC)

I'm running under MediaWiki 1.7 and FCKeditor 2.3...

--Broon 14:14, 16 August 2006 (UTC)

FCKeditor with SemanticMediaWiki
--Broon 18:00, 16 August 2006 (UTC)

Second Problem... As far as i have seen, the FCKeditor extension bypasses the wikisource to avoid that the wiki parser modifies the code. To parse links and Images, the extension calls the functions itself in function FCKeditor.php: wfFCKeditorBypassParserPaste.

Now i have the problem, that other functions, hooked into the parser, doesn't work anymore. For example SemanticMediaWiki.


 * Sorry, bad news, see http://mail.wikipedia.org/pipermail/mediawiki-l/2006-July/013991.html

There exist links with the format relation::target or attribute:=value. This Tags are ignored by the FCKeditor parser calls...

Is there a way to don't bypass and use the usual wiki parser calls? (Without using a workaround with perl and that stuff like described in FCKeditor and HTML::WikiConverter). Or does somebody know another WYSIWYG Editor, that gan handle mediawiki sourcecode?

My user's are crying for a editor. Thanks or evey hint...


 * Broon, I've fought this battle with the FCK devs


 * Just to be correct: It is exactly one dev working on this extension. Mafs 19:14, 28 August 2006 (UTC)

(you know, that name just makes more sense every day...), and as far as I can tell, it's not going to change. If you go with FCKeditor, you're going to break every single extension you use that extends wikitext. Not some, not most, all. FCKeditor's parsing capacities have all the subtlety of an ape in a vase museum, and pretty much every extension tag you create will be destroyed when you next edit the page (assuming you used the source code view to make it work in the first place). The best solution at the moment is to just sit down with your users and teach them wikitext until mediawiki gets it in gear and makes their own version of FCK that's better integrated. Unfortunately, FCK is presently the the closest thing to a functional visual editor there is for mediawiki. -Verlocs 12.104.195.32

Include special pages doesn't work
Using the FCKEditor-extension it seems easily to be possible using -tags to include other pages into the actual page.

This seems to break when you try to include special pages.

I.e.:

ends up in the following:
 * UNIQ3d49fec24d129f39-item1e59046632a34fdb

When I include a special page in an excluded namespace, the special page is included correctly.

Does someone has an idea to resolve this problem?

Star 12:50, 21 August 2006 (UTC)


 * I would have thought that the function replaceVariables in Parser.php which is called by the extension replaces also  . Unfortunately, this function is called by various functions of the parser, not only by internalParse which was the template the extension. Hence, I do not have a solution to your problem. Mafs 19:40, 28 August 2006 (UTC)

Mediawiki 1.7.1+ FCKeditor 2.3.1
Well, I have just downloaded and installed both current versions of mediawiki and FCKeditor ... I have followed all the steps twice when installing FCKeditor so I'm sure I didn't missed anything. Have already edited LocalSettings.php and the other files.

For some strange reason the FCKeditor isn't showing up when editing an article, the wikimedia editor is still appearing ... and no matter if I put the Magic Words or not the FCKeditor still doesn't show up ...

I have already tested the FCKeditor/_samples/default.html and it seems to work just fine ...

The only clue I have is that when I change the $wgFCKUseEditor to true the headings got messed up ... it's almost like the wiki markups and codes no longer were being understood ...

Since I'm kinda of newbie on this webmastering stuff and site constructions I'm sure that there must be something I'm doing wrong ... if anyone could help me I would appreciate cause I have tried evrething I know and I just can't figure it out !

Same problem
I am having the EXACT same problem. It doesn't work unless I set $wgFCKUseEditor to true, then all pages get messed up. Is there a fix for this? Thanks! 206.132.94.6 15:15, 4 October 2006 (UTC)

I use the latest version on Sep. 13
I can only see the default editor but if I do per page base, the editor will show up BUT the content of article will show the magic word, which shouldn't happen.

Any suggestions?

Did you copy the updated code using edit mode in mediawiki? also did you upload and clear your cache when uploading your localsettings file? --Priced80 23:35, 3 October 2006 (UTC)

I have decided to just use extra buttons like wikipedia instead this is too much hasstle, its obviously not meant for mediawiki. i just wish it worked becuase it looks great.

Bug: Links in Headers
It looks like using links in headers causes problems with this extension in MW 1.7.1. So links get replaced with a random string of numbers (around line 218). Then in Parser::formatHeadings, when HTML would normally be stripped out of the anchor links for headings, it just sees the random number and doesn't strip anything. Later, when the random numbers are converted back into links (line 288), you get an anchor link that looks like this: <a name="<a title="Arg" href="Arg">Arg</a>"></a> Moving: $fcktext = $q->formatHeadings( $fcktext, true ); from line 272 down to the end of the if loop (line 292 or so) seems to fix the problem but may break other quirky parser stuff.

Can't get FCKeditor working for all discussions
Installed everything, works great. Had to tweak some of the files dealing with "images" because of several small errors, but now it seems to work fine. I am unable to get FCKeditor working with all the "discussion" sections (like this page). I have it defaulted on the content page, but when I click "discussion", I only see the standard MediaWiki editor. Other pages seem to work fine, but I can't figure out why some work/some don't. Any suggestions?

Go to your LocalSettings.php file and find "$wgFCKexcludedNamespaces"

Remove "1" from the exclude array list, because 1 means talk namespace

--Mihu 19:04, 30 November 2006 (UTC)

What can be wrong? Mediawiki 1.6.8
I have installed and modified everything as written. At the test page everything shows up correctly in the /FCKeditor/_samples/default.html url - I see the toolbar, can edit the demo page, change skins well.

Problem: toolbar doesn't show up in editbox, whatever I do. When I set $wgFCKUseEditor to true and reload, my pages (I have some already) show up differently, like the == signs from headers and other wiki syntax are becoming visible. So something works, just the toolbar... when I edit, it's still the old wikimedia one. I double checked everything I could.

I thought that the extension might be accidentally corrupted (edited when copied), so I even tried older versions, like the 12 September 2006 version from Mafs.


 * Answer: 1.7.x is required.

Well I don't want to argue at all but I have seen some posts above talking about 1.6 environment working fine.


 * These posts refer to various versions of the extension. Indeed, once uppon a time, there had been a version working with 1.6. However, the current version does solely work within the 1.7 environment.

Migrating from old wiki to FCK-enabled wiki?
We have some wikis using the FCKEditor extension, and people are loving it despite its warts. So is there any straightforward way to migrate older wikis that didn't use it, to newer ones that do? Difference in the database format makes a simple export/import fail. I'm actually considering a hack to convert from wikitext to FCK-formatted HTML, which is less awful than it sounds because our wiki users aren't using much beyond the most basic wikitext constructs. Are there any tools or techniques I can use to smooth this transition? (Nweinstock)


 * You have to write your own hack. I would suggest the following procedure:
 * 1. Copy your wikis into a new environment.
 * 2. Upgrade the wikis.
 * 3. Create a list of all the pages of a wiki and dump the pages using the wiki export function.
 * 4. Create a special page which has an input text area where the exported text (xml) can be inserted. Write a script for the special page which performs the following steps:
 * 4.1 For each page the wiki content is extracted
 * 4.2 This content is transformed using the parse function :

global $wgOut; $html = $wgOut->parse($wikisyntax);


 * 4.3 You may want to disable some functions of the wiki parser, eg creating edit section links. This can be done manually within the internalParse function of Parser.php. You will have to perform some experiments.
 * 4.4 The timestamps have to be adjusted.
 * 4.5 The transformed xml text should be displayed on the special page, or saved to some location, ...
 * 5. Finally, send the transformed xml text to you wiki using the import function.


 * Good luck,  Mafs 16:35, 28 October 2006 (UTC)

MediaWiki 1.8.2 and FCKEditor 2.3
I have followed the instructions for installing the FCKeditor into mediawiki, however I am getting the dreaded 'ajax request error' when I use the image button. I have double checked the installation and everything else seems to work just fine.<BR> My $wgScriptPath      = ""; and my FCKConfig.mwScriptPath = "."; <BR> I have tried to figure out what is happening by turining on the debug in the fck_image.js and tracing the steps.<BR> No dice, I get a return of: RSD: wfSajaxSearchFCKeditor uri = /./index.php?action=ajax&rs=wfSajaxSearchImageFCKeditor&rsargs[]=abe/post = null

If I paste this into the browser, it returns a blank page.

Any Ideas why this would be? Is there something that changed in 1.8?

137.82.224.173 00:30, 4 November 2006 (UTC)

I have exactly the same problem which is not related to FCKConfig.mwScriptPath. The php error log says: [error] PHP Fatal error: Call to a member function setPolicy on a non-object in /Library/WebServer/Documents/wiki/extensions/FCKeditor.php on line 313

Thanks a lot for any ideas!


 * Ajax support is completely broken in 1.8.x, see also http://mail.wikipedia.org/pipermail/mediawiki-l/2006-October/015520.html
 * Mafs 15:43, 5 November 2006 (UTC)

fix "ajax request error"
Modify fck_image.js line 128 pat = /<input[^>]*hidden[^>]*wfSajaxSearchImageFCKeditor[^>]*>/ to pat = /put[^>]*hidden[^>]*wfSajaxSearchImageFCKeditor[^>]*>/

Well .. I am not sure what am I doing ...

1. comment this line $wgAjaxCachePolicy->setPolicy( 30*60 ); from FCKeditor.php in your extensions folder.

2. Modify fck_image.js line 128 pat = /<input[^>]*hidden[^>]*wfSajaxSearchImageFCKeditor[^>]*>/ to pat = /nput[^>]*hidden[^>]*wfSajaxSearchImageFCKeditor[^>]*>/ --Mihu 19:54, 29 November 2006 (UTC)

Is FCKeditor compatible with 1.8.2??
As far as I can tell, I've followed these installation instructions exactly.: http://meta.wikimedia.org/wiki/FCKeditor

However, the FCKeditor WYSIWYG is not appearing on any pages, it basically acts as though I haven't done anything.

If anyone has any suggestions, I would appreciate it.

Please check your LocalSettings.php $wgFCKUseEditor         = true;      // When set to 'true' the FCKeditor is the default editor.

This will make FCKEditor to every page.

$wgFCKexcludedNamespaces = array(8,-1);

Remove 1 from the array to use editor for "discussion" page.

I hope those help.

--Mihu 19:49, 4 December 2006 (UTC)

--

Hi Mihu, Thanks for the suggestion, I have already changed the $wgFCKUseEditor value. Doing this seems to break the wiki formatting (the wiki code is displayed when viewing an article), and the WYSIWYG editor still does not appear.

Any other suggestions? This has been setup to work on 1.8.2 by someone before correct?

--

that is a known issue with this FCKeditor approach which is destroy the original post.

Beside this known issue, you should be able to see WYSIWYG editor. You must set up something wrong.

I suggest you go over everything again. I am using 1.8.2 and it works fine w/ me.

I think it should work fine for you too.

I am working on some alternated way to fix destroy original post, but it requires to install perl extension.

-- Gotcha, I've already installed it twice and I'm fairly competent usually ;) But I'll give it another go and see what happens.

Thanks

-- let me know if you can't make it, I will try to help you.

-- Ok, well I'm still having the same problem unfortunately. Would the fact that I'm using URL redirects with .htaccess require any different configuration settings?

Chris

-- I didn't use URL redirect so I am not sure about this.

Maybe you can instal a fresh one for testing and see if it work on the new install one.

-- Took of the redirects, same thing. Installed 1.7.1, copied over my configs...worked instantly. I think I'll just stick with 1.7.1 for now :)

chris

-- That's weird .. well .. glad u can make it works. Can you install perl on your server?

Text of Page Disapearing from FCKeditor
After editing a page once with the FCKeditor and then returning to edit the page again, the text of the page does not appear in the FCKeditor window. When I press the source button, the text appears and then disapears if I go back to the other view. FCKeditor has been setup with the instructions on this page. It also does not save the changes.

I have version 1.8.2 of MediaWiki and 2.3.2 of FCKeditor. I am also using ssl for the site. Does someone know what is happening?

Thank you, Hal15900 13:58, 6 December 2006 (UTC)

Fatal Error on Parser.php using MediaWiki 1.9
I installed MediaWiki 1.9 and I tried installing this extension. I tried installing it twice to make sure it all worked properly. I enabled $wgFCKUseEditor. Now when I go to my wiki, this is the message that I get:

Fatal error: Call to a member function mergeArray on a non-object in /home/.lorre/ihotrobotics/ihotrobotics.org/wiki/includes/Parser.php on line 622

That line is $state->nowiki->mergeArray( $nowikiItems );

When I make $wgFCKUseEditor false, everything works fine at first. I go to edit a page, and I put __USE_EDITOR__, I save the page. When I go back to edit it, I get the same fatal error.

How do I fix this? Is it because I'm using v.1.9?

Thanks, --AdrienP 04:20, 13 January 2007 (UTC)

It would be nice to know wheater this interesting extension is still active


 * Exactly the same problem here
 * someone know what to do ?
 * Nifrou

--Anonymous 15:15, 13 January 2007 GMT

I am also experiencing the same issue using MediaWiki 1.9.

Fatal error: Call to a member function mergeArray on a non-object in /includes/Parser.php on line 622

--JSpirko 18:55, 17 January 2007 (UTC)

Same problem: Fatal Error on Parser.php using MediaWiki 1.9
Hi, I have same problem. Is there any solutions?

Thanks, Alex. --199.203.223.3 13:08, 14 January 2007 (UTC)


 * Well, I finally decided to change to MediaWiki 1.7.1. I tried 1.8.3, but it didn't work on that one either. It works fine in 1.7.1.
 * --AdrienP 18:01, 14 January 2007 (UTC)


 * I'm not familiar with the versioning scheme of MediaWiki - are those older versions still secure enough for a sometimes-out-on-the-internet site or do I have to go with the latest version for security patches? I'd love to use FCKedit on my site and would be willing to downgrade, but if downgrading opens well-known security holes...
 * --217.225.42.6 22:08, 25 January 2007 (UTC)

I also have the same problem. Double checked everything but still I get the same error.

possible solution
I has a similar problem with another extension. In the source code the must be a line similar to $local_parser->parse( $text, $parser->mTitle, $parser->mOptions, true, false ); Set the last parameter to true and it should work. --Dschwen 16:23, 31 January 2007 (UTC)

Can you please elaborate. I desperately need it to work and am not a pro in PHP --24.39.146.178 21:12, 1 February 2007 (UTC)

A temporary solution
Disclaimer: I don't know what exactly this does. I just know that it gets it working again.

In the extensions folder, in the file FCKeditor.php that you made, at line 264, where it says:

$x =& $state;

insert a line above it, and put:

$state = new StripState;

This will stop that fatal error.

But it mucks with the "state machine" code in Parser.php. My new line just creates a default object. It doesn't have any real data in it. I think that state is supposed to keep track of wiki markup during the conversion to HTML and back. I do know this: the rendering of wiki markup is totally disabled with my hack. I have to use HTML for everything -- no wiki markup -- which is what I personally wanted anyway, but that may not be what you want.

This hack is, at best, just a temporary fix for some people until the developer of this extension (not me) presents the right, official patch for MediaWiki 1.9.

I don't recall creating a FCKeditor.php in the extensions folder. At least not according to the directions on the previous page. Can you reference that file on the previous page? 24.127.37.76 03:11, 9 February 2007 (UTC)

Got it. Someone has removed a section of the instructions. They are in this version of the previous page. I'm working on MW 1.9.1 and will post progress shortly. 24.127.37.76 03:21, 9 February 2007 (UTC)

{didn't realize I was anonymous earlier} The above mentioned hack works with 1.9.1. I haven't noticed much of a problem with wikitext/html yet, but I have only had it up for a few hours. Sidboswell 03:58, 9 February 2007 (UTC)

The toolbar "wiki" does not exist
Hello,

I have instal the FCKeditor with the instruction of this page, but I have error :

The toolbar "wiki" does not exist

(in french version : La barre d'outils "wiki" n'existe pas)

The sample work :

but at the end of the instal I have this error (I put $wgFCKUseEditor = true; and $wgScriptPath	   = ""; and FCKConfig.mwScriptPath = "";)

Thank you for your help, its possible I havent anderstand one point because my english is poor.

--82.139.255.241 11:17, 30 January 2007 (UTC)

You have forget to creat the FCKeditor.php in \extensions.

I am having the same problem. If I comment out the line in LocalSettings.php the it runs fine, but the image and link tool are still the FCKeditor default tools. I have made the changes to wiki/FCKeditor/fckconfig.js, I still get the error. I'm somehow passing up the block: FCKConfig.ToolbarSets["Wiki"] = [ ['Source','-','Save','NewPage','-'], ['Cut','Copy','Paste','PasteText','PasteWord','-','Print'], ['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'], ['Bold','Italic','Underline','StrikeThrough','-','Subscript','Superscript'], ['OrderedList','UnorderedList','-','Outdent','Indent'], ['JustifyLeft','JustifyCenter','JustifyRight','JustifyFull'], ['Link','Unlink','Anchor'], ['Image','Table','Rule','Smiley','SpecialChar','PageBreak','UniversalKey'], ['Style','FontFormat','FontName','FontSize'], ['TextColor','BGColor'], ['FitWindow','-','About'] ] ; in that file. I'm also not getting to that block. Even if I move way up in the fckconfig.js file and replace the word 'Basic' with 'Wiki' (on line 116) I'm still getting the error. Is there anyway I can be referencing another config file? Sidboswell 20:11, 9 February 2007 (UTC)
 * 1) $wgFCKEditorToolbarSet  = "Wiki";

fckeditor.js does not "compile" (FCK version 2.4, MW version 1.9.2)
Thanks to Firefox' error console and the Venkman debugger it became clear that the file fckeditor.js is not valid. First at line 188 it said:

Changed to (added the backslash):

The first quote leaves the line open. After changing that I got further (added some alert calls). But then the debugger got confused about the FCKeditor_IsCompatibleBrowser function (line 195). After the

there was no closing bracket, }, so the lines with FCKConfig were unreachable.

My first approach was to add the }, but the it found a surplus } just before the end of file. Removing that made the script fail at the first FCKConfig line. Better reading of the scripts, but also this discussion, revealed that those lines belong in the fckconfig.js.

Moving it there, only left the warning about UniversalKey, as described below. Removing all undesired buttons, now left me with a working combination.

HaKr 14:53, 23 February 2007 (UTC)

`Unknown toolbar item "UniversalKey"' on MediaWiki-1.6.9/FCKEditor 2.4
Hello all, I was able to enable FCKeditor onto my MediaWiki 1.6.9, and it seems to work fine, but everytime I reload (browser reload) on the page which I was editing (at that particular moment), the message I get was the `Unknown toolbar item "UniversalKey"'.

What I did after that was I remarked the word 'UniversalKey' in the FCKeditor/fckconfig.js and it doesn't prompt me anymore (the message I've stated above). My question is what is this UniversalKey toolbar?

The code (intended for FCKeditor/fckconfig.js

['Image','Table','Rule','Smiley','SpecialChar','PageBreak','UniversalKey'],

Which I have replace with the following (working code, assumingly):

//['Image','Table','Rule','Smiley','SpecialChar','PageBreak','UniversalKey'], ['Image','Table','Rule','Smiley','SpecialChar','PageBreak'],

According to this article, this is a known issue with FKeditor 2.4. Comments suggest either dropping back to FCKeditor 2.3.2 (which is what I did, and it worked) or making the change you mentioned. In either case, be sure to clear your browser's cache. Greywinters 17:26, 9 February 2007 (UTC)

FCKeditor Not Working - Please Help
Hey everyone,

I would love nothing more then to implement the FCKeditor into my wiki. MediaWiki 1.71, and FCKeditor version 2.3. I have followed the steps word for word, however am faced with a problems others have seemd to have as well.

When I try to edit a page that has be declared to have it as the editor, the page doesnt show. All that is seen is a blank white page. I took a look at the source and all it was is a basic HTML tags with no content in them.

When I set it to be the default it causes the same effect, however it does it to the entire wiki. I have tried changing paths, and even hard coding things, however I end up with the same result regardless.

Any and all help will truly be appreciated.

There was a step in the instructions for including the extensions/FCKeditor.php file that was missing for a while.

What do you see when you go to Special:Version? You should see the .php file listed under the Extensions section. Mine is [here]. My FCKeditor still isn't 100% smooth (I'm still having issues with the image buttons and can't seem to get the "wiki" specific toolbar to work) but I'm (slowly) hacking my way through. Feel free to contact me via the wiki page I listed above ....

Good Luck, 24.127.37.76 02:05, 16 February 2007 (UTC)

Hey there Sid,

Thanks for the info, however I do have that plugin and it is listing. I think from reading the previous posts this has to do with path issues however I have no idea how to fix them.

I pasted a bunch of stuff on my site for you at here and here are my configs.

But the main solution to your problem may actually be here. 24.127.37.76 03:54, 18 February 2007 (UTC)

Ok just to update others here that may be reading and wondering. I checked the article Sid gave me and it turned out those lines already existed. So what I did was uncomment it out.

The good news is the Wiki no longer crashes - Yay!

The bad new is the FCKeditor doesnt display at all, it appears its not even being called. So any help is appreciated.

StripState error
We are trying to do a test installation of this editor on MediaWiki 1.8.2 with FCKEditor 2.4. We get the following error after trying to edit a page that has the text __USE_EDITOR__ :

We can't track down this StripState class. Does anyone know how to resolve this issue? I'd appreciate help with this because having a WYSIWYG editor would REALLY help with wiki adoption. --VanessaV 23:30, 19 March 2007 (UTC)

I had this exact same problem about the StripState class. I found in the parser.php, but I didn't do anything within that file to make it work. I believe that the StripState class was added for MediaWiki 1.9 as they were speaking about above. I took out the line $state = new StripState; and it fixed the problem. Hope this works for you. --72.189.82.119 03:19, 22 March 2007 (UTC)