FCKeditor extension does not recognize tags registered by other extensions

[Dan Barrett]

1. Edit a new MediaWiki page with FCKeditor.

2. Click the "Wikitext" button to switch to wikitext editing.

3. Enter this text:

<mytag>foobar</mytag>

4. Save the article.

5. Disable FCKEditor on the MediaWiki preferences page.

6. Edit the same page.

7. The wikitext is now:

&lt;mytag&gt;foobar&lt;/mytag&gt;

The wiki parser tag is now broken.

[cableguy]

Got right the same mistake trying to use the Imagemap tag fr the Impagemap extension

[Artur Formella]

Usage: Add in LocalSettings.php:

$RTEprotectedTags[ 'mytag' ] = array(

'protect' => true, false=wiki parsing, true=protect content as <special>

);

To define custom tag with attributes:

$RTEprotectedTags[ 'source' ] = array(

'args' => array('lang','arg2','arg3'),

'protect' => true,

);

[Wiktor Walc]

Looks good. Please initialize this variable in FCKeditor.php:

//associative array with definitions of tags to protect
$RTEprotectedTags = array();

and add some clean examples and a short comment. It may be an example with source tag:

/*
 * Use tag name as a key.
 * "protect" attribute tells FCKeditor how to proceed with content.
 * Set it to false to allow wiki text transformation.
 * When set to true, protect content as a <special> tag
 */
$RTEprotectedTags[ 'source' ] = array( 
'protect' => true, 
);

(at least until #2324 is solved).

One performance tip:

in_array($tagName, array_keys($RTEprotectedTags))

can probably changed into:

isset($RTEprotectedTags[$tagName])

AFAIK it executes much faster.

[Dan Barrett]

The code "looks good," but... is this really a good solution to the problem? It requires the administrator to predict what tags might exist in the future, and if he/she misses one, then FCKeditor silently modifies the author's text.

A much better solution, IMHO, is for FCKeditor+MediaWiki not to modify what people type! Is this not possible?

One of the things I love about FCKeditor+MediaWiki, compared to (say) some Drupal editors I've used, is that FCKeditor+MediaWiki gives you back what you put in. Write wikitext, get back the same wikitext. The last Drupal editor I used completely mangled my input, turning it into HTML with tons of extra tags, making it completely unmaintainable the next time I tried to edit it.

Silently changing the author's text is bad. Storage and retrieval of wikitext should occur as people expect -- what you put in is what you get out.

[Wiktor Walc]

Unfortunately Review- due to problems with protect set to "false" when using ImageMap and SyntaxHighlight_GeSHi extensions.

djb comment sounds reasonable. "What you put in is what you get out" is something that we would really like to have, however it's not easy to achieve.

Anyway, let's give at least one more configuration option to the administrator.

/*
 * Regardless of this setting, $RTEprotectedTags settings have higher priority.
 *
 * If set to 0, all unknown tags <tag> are changed into HTML entities: &lt;tag&gt;
 *
 * If set to 1, all unknown tags are treated by FCKeditor as a special tag.
 *   When switching back to wikitext, <tag> will be displayed as <tag>.
 *   When editing in WYSIWYG mode, all contents inside of this tag will be 
 *   transformed into HTML.
 *
 * If set to 2, all unknown tags are treated by FCKeditor as a special tag and  
 *   content inside of them is displayed as a raw wikitext.
 */
$RTEprotectAllUnknownTags = 0;

[Craig]

Can someone apply this to the trunk?

[Artur Formella]

The patch is not finished and didn't pass the review so please don't use it unless you know how to finish it.

[Greg]

This interferes with MANY extensions.

[Greg]

Is there a copy of the review? What failed? What needs to be fixed?

[Greg]

Note: When you use the SyntaxHighlight_GeSHi extension and then insert XML code you may protect the source tag, but I don't know if it would be possible to protect the main "source" tag, but it would be impractical to protect all tags used in xml... as they are infinite! We might need a magic word to disable the rich text editor for just a section of the wikitext.

[Greg]

After installing the patch "fckLR" replaces the return char within the protected tag. Any ideas?

[Andrew]

Found solution that allows to fix this bug at least for tag extensions (hooks) included in mediawiki...

All we need it init parser object ($wgParser) before use it methots (like $wgParser->getTags() ) in files : FCKeditorParser.body.php ( method construct() ); FCKeditorSajax.body.php ( method wfSajaxSearchSpecialTagFCKeditor() ); mw12/FCKeditorParser_OldPP.body.php ( method construct() );

    $wgParser->firstCallInit();

Sorry, but at that moment I don't have condition's to attach diff patch I also sorry for my english =)

[avran]

The editor is not also mangling links that are inserted via WikiText example:

Click this?

Would it be possible to add a tag so that the FCK editor would display all text inside of it as WikiText.

eg: <fck-no-parse> Click this? </fck-no-parse>

[avran]

Replying to avran:

The editor is not also mangling links that are inserted via WikiText example:

Click this?

Would it be possible to add a tag so that the FCK editor would display all text inside of it as WikiText.

eg: <fck-no-parse> Click this? </fck-no-parse>

Sorry the first line of my comment should read 'The editor IS also mangling links that are inserted via WikiText example:'

[Wiktor Walc]

The solution posted by atereshko worked with tested random extensions, good job!

Fixed with [3241].

@avran - please create a separate ticket for issue described in comments 15 & 16 (if this bug still occurs in the latest version of the extension).