Support MW built-in tags (includeonly, noinclude and nowiki)

[barns]

This ticket aims at splitting ticket 1010 in 2. See ticket 1010 for more background on the request/proposed implementation. The pre tag should be moved from format select box to the custom tag/style one, ie be treated as noinclude, nowiki, etc... as it can span on several lines.

Proposal for styles (follow-up of request 1010): to make people realize their text is within a special tag, I would propose to have a background color for the style, with dashed border (uniform with pre, and avoids confusion with FCK tables that can only have solid borders). Dashed borders would then mean that we are within a special tag, such as:

fck_mw_nowiki {
	padding: 0.5em;
        margin: 1em;
	border: 1px dashed #2f6fab;
	background-color: #f9f9f9;
	line-height: 1.1em;
}

fck_mw_noinclude {
	padding: 0.5em;
        margin: 1em;
	border: 1px dashed #87f906;
	background-color: #d1f2ab;
	line-height: 1.1em;
}

fck_mw_includeonly {
	padding: 0.5em;
        margin: 1em;
	border: 1px dashed #fe1fbf;
	background-color: #f7d3ed;
	line-height: 1.1em;
}

[barns]

ok, got the php parser side implemented, in FCKeditorParser.body.php add:

    private $FCKeditorMwTags = array('<noinclude>' => '<div class="fck_mw_noinclude">', 
    '</noinclude>' => '</div>',
    '<includeonly>' => '<div class="fck_mw_includeonly">', 
    '</includeonly>' => '</div>',
    '<nowiki>' => '<div class="fck_mw_nowiki"><nowiki>', 
    '</nowiki>' => '</nowiki></div>'
    );

and in function , add

    function internalParse ( $text ) {
	$text = strtr($text,$this->FCKeditorMwTags);
        ...

in fckeditor.css, add:

div.fck_mw_includeonly {
	padding: 0.5em;
    margin: 1em;
	border: 1px dashed #fe1fbf;
	background-color: #f7d3ed;
	line-height: 1.1em;
}
div.fck_mw_noinclude {
	padding: 0.5em;
	margin: 1em;
	border: 1px dashed #87f906;
	background-color: #d1f2ab;
	line-height: 1.1em;
}
div.fck_mw_nowiki {
	padding: 0.5em;
    margin: 1em;
	border: 1px dashed #2f6fab;
	background-color: #f9f9f9;
	line-height: 1.1em;
}

[barns]

And in fckplugin.js, add:

case 'div':
	switch ( htmlNode.className )
	{
		case 'fck_mw_nowiki' :
			stringBuilder.push( '<nowiki>' ) ;
			this._AppendChildNodes( htmlNode, stringBuilder ) ;
			stringBuilder.push( '</nowiki>' ) ;
		return ;
		
		case 'fck_mw_noinclude' :
			stringBuilder.push( '<noinclude>' ) ;
			this._AppendChildNodes( htmlNode, stringBuilder ) ;
			stringBuilder.push( '</noinclude>' ) ;
		return ;
		
		case 'fck_mw_includeonly' :
			stringBuilder.push( '<includeonly>' ) ;
			this._AppendChildNodes( htmlNode, stringBuilder ) ;
			stringBuilder.push( '</includeonly>' ) ;
		return ;

	}						}

[barns]

Apparently, the nowiki parsing in FCKeditorParser.body.php is not good. We should probably extract the wikitext in between tags and put a keyword like for templates, run the wiki parser to html, and then re-insert back the text surrounded by divs.

[Frederico Caldeira Knabben]

I've just commented at #1010 that I've committed the JavaScript part of it with [613]. Actually, we are supposed to with with <span> tags instead of <div>, as those tags behave much like inline elements.

Witkor has worked on the server side for it. I'm sure he'll taking a look at your suggestions and commit it to the SVN.

[Wiktor Walc]

Thanks for tips! I made a couple of changes in FCKeditorParser, however text inside custom tags is currently parsed (only nowiki is not parsed)... which is rather wrong solution. Anything between includeonly, noinclude and any other tags, like feed should be left as it is... which may be done in fck_genericTagHook & fck_wikiTag if I'm correct. I mean instead

$ret .= htmlspecialchars($str);

I will add there some string that I'll replace later using strtr... and that should solve the problem.

However, currently to trace these hooks (which tag is it) in this line:

$this->fck_mw_taghook = $tagName;

I had to add the whole strip() function which duplicates a lot of code from mediawiki. Do you see any other way to do this so that we could avoid duplicating?

I know I could do this by setting hook for each tag to its own function and then use __call for that, but it would be quite messy don't you think?

[barns]

Replying to fredck:

I've just commented at #1010 that I've committed the JavaScript part of it with [613]. Actually, we are supposed to with with <span> tags instead of <div>, as those tags behave much like inline elements.

Using span tags as you did does not work for me, only DIVs so, try the following wikitext (tested after your patches above):

<noinclude>
==test title==
hello world
==2 titles==
ha
</noinclude>

and save, open with FCK, and go back to wikitext, you will get:

<noinclude></noinclude>
==test title==
hello world
==2 titles==
ha

With DIVs, I do not have this issue.

[barns]

Replying to wwalc:

Thanks for tips! I made a couple of changes in FCKeditorParser, however text inside custom tags is currently parsed (only nowiki is not parsed)... which is rather wrong solution. Anything between includeonly, noinclude and any other tags, like feed should be left as it is... which may be done in fck_genericTagHook & fck_wikiTag if I'm correct.

For me, there are 2 cases:
1) either we want things inside a tag to be parsed by the wiki parser, but keep a trace of the tag to be able to modify it later (this goes for noinclude and includeonly)

2) or we want things inside the tag to be left untouched (like nowiki, dpl, inputbox, etc...: text only between tags), and also keep a trace of the tag. The problem -as for templates- is to remove any additional formatting introduced by FCK (p or br tags for instance, or html special characters conversion

For case 2, why not use the html "code" tag for instance, and add classes to it to specify the type of tag?

I know I could do this by setting hook for each tag to its own function and then use __call for that, but it would be quite messy don't you think?

I think my programming skills are too limited, sorry. I will stick to try and help on the logic ;-).

[barns]

Replying to ycombarnous:

For case 2, why not use the html "code" tag for instance, and add classes to it to specify the type of tag?

Tried to do it by myself, but carriage returns still get stripped somehow or converted to paragraph, and FCK keeps converting special characters. Any help ?

[Wiktor Walc]

I've made a change in parser, so this should be handled better now:

<noinclude>
 ==test title==
 hello world
 ==2 titles==
 ha
</noinclude>

...however now we have another problem - white chars inside (e.g. new lines) <span class="fck_mw_noinclude"> are ignored/stripped.

If we don't parse text inside custom tags, perhaps it would be a good way to provide some tool to make an ajax call to see parsed result of that piece of text.

[barns]

Replying to wwalc:

I've made a change in parser, so this should be handled better now: ...however now we have another problem - white chars inside (e.g. new lines) <span class="fck_mw_noinclude"> are ignored/stripped.

I really have the feeling that noinclude and incudeonly should be treated as "div", not "span" tag, and that it would make the whole thing a lot easier. For nowiki, and custom tags, you could use span definitely.

If we don't parse text inside custom tags, perhaps it would be a good way to provide some tool to make an ajax call to see parsed result of that piece of text.

If FCK was already able to provide a text-only zone that would not skip new lines for nowiki and custom tags, nor transform special chars like < or > that might mean something inside the custom tag, that would already be a big step forward in not breaking wikitext.

The ajax call would be a plus, but the priority should be not to break any page, right ?

[barns]

Example of line stripping and "<" ">" conversion:

<inputbox>
type=create
width=30
break=no
default=<Enter definition name>
buttonlabel=Create a definition
preload=Definition example
</inputbox>

Becomes after loaded in FCK (broken):

<inputbox>
type=create width=30 break=no default=&amp;amp;lt;Enter definition name&amp;amp;gt; buttonlabel=Create a definition preload=Definition example
</inputbox>

[barns]

Ok, I think I got a bit forward:

1) I reverted change 616, and had in the php parser "fck_wikiTag" function create DIVs instead of SPANs. Then I had "fck_genericTagHook" function cretae PREs instead of SPANs.

2) Then in FCKplugin.js, I added (for custom tags, removes BRs and html special chars conversion):

case 'div' :
	switch ( htmlNode.className )
	{
		case 'fck_mw_nowiki' :
			sNodeName = 'nowiki' ;
			break ;

		case 'fck_mw_includeonly' :
			sNodeName = 'includeonly' ;
			break ;

		case 'fck_mw_noinclude' :
			sNodeName = 'noinclude' ;
			break ;

		case 'fck_mw_onlyinclude' :
			sNodeName = 'onlyinclude' ;
			break ;

	}
	
	// Change the node name and fell in the "default" case.
	if ( htmlNode.getAttribute( '_fck_mw_customtag' ) )
		sNodeName = htmlNode.getAttribute( '_fck_mw_tagname' ) ;

case 'pre' :

	if  ( htmlNode.className ) {
		switch ( htmlNode.className )
		{
			case 'fck_mw_nowiki' :
				sNodeName = 'nowiki' ;
				break ;

			default:
				// Change the node name and fell in the "default" case.
				if ( htmlNode.getAttribute( '_fck_mw_customtag' ) )
					sNodeName = htmlNode.getAttribute( '_fck_mw_tagname' ) ;	
				stringBuilder.push( '<' + sNodeName + '>' ) ;
				var aRegExp = new RegExp ("<br>","g");
				stringBuilder.push( FCKTools.HTMLDecode(htmlNode.innerHTML.replace( aRegExp, "\n" ))  ) ;
				stringBuilder.push( '<\/' + sNodeName + '>' ) ;
				return ;
		}
	}

[barns]

FYI, I tested my changes above against the inputbox extension/tag and DPL. It works (meaning going back and forth between wikitext and FCK leaves text formatting unaltered) with things as complex as:

<dpl>
  resultsheader=__NOTOC__
  category =-second flat
  category =-Towns
  category =+Countries|Data
  includepage=definition
  ordermethod=category,sortkey
  headingmode=H3
  mode=userformat
  listseparators=¶{|class="sortable" width=100% border=1 ¶|-bgcolor=#cccccc ¶!Countries ¶!Definition  ¶|-,¶|-¶|[[%PAGE%]] ¶,¶,¶|}
  secseparators=¶|
</dpl> 

[barns]

Replying to ycombarnous:

Ok, I think I got a bit forward:

Noticed I need an additional case for pre:

else {
	stringBuilder.push( '<pre>\n' ) ;
	this._AppendChildNodes( htmlNode, stringBuilder ) ;
	stringBuilder.push( '\n<\/pre>\n' ) ;
	break;
}

There is still one thing that is not working properly now: we cannot use the carriage return in FCK editors inside PRE format. Every time we use the carriage return (ie create a new line), the line is surrounded by PRE tags. PRE should behave more like paragraphs. Any idea how to modify this bahavior ?

[barns]

Replying to ycombarnous:

There is still one thing that is not working properly now: we cannot use the carriage return in FCK editors inside PRE format. Every time we use the carriage return (ie create a new line), the line is surrounded by PRE tags. PRE should behave more like paragraphs. Any idea how to modify this bahavior ?

Removed some potential errors on else case:

else {
	if (!htmlNode.parentNode.nodeName.IEquals( 'pre' ) )
		stringBuilder.push( '<' + sNodeName + '>\n' ) ;
	this._AppendChildNodes( htmlNode, stringBuilder ) ;
	if (!htmlNode.parentNode.nodeName.IEquals( 'pre' ) )
		stringBuilder.push( '\n<\/' + sNodeName + '>\n' ) ;
	break;
}

Now to bypass the PRE issue, I suggest that when clicking on a PRE zone, a dialog with a textbox opens as for Templates. That should resolve above issues ,wouldn't it ?

[Frederico Caldeira Knabben]

The fact is that those tags, like <nowiki> have no block/inline definition. Those are just markers to the parser, nothing more than that. So, using <span> will be correct on some cases (like the [[Link]]<nowiki>s</nowiki> case), but on other cases they should behave like <div>, when holding blocks of text for example.

So, we have two real possibilities: the parser uses the correct <span> or <div> tag depending on the case, or we just place an icon to replace those tags, making them editable through a dialog window, just like we do with templates. Probably the later is the way to go here.

The same thing is valid for custom tags. While some of them will be ok as normal <span> tags, other need to have their format preserved and so on. So, here again, I see that the icon solution is the right choice to make it work in all cases.

The <pre> idea would be good for some tags, but I'm sure it would sound really strange in other cases, so we must leave <pre> limited to <pre>, and that's it.

So, what about creating icons for the four standard tags, added to a generic icon for others?

[barns]

Thanks for the feedback. I agree with you on most things.

For noinclude, includeonly, and onlyinclude tags, it is probably safe to treat them as blocks (ie DIVs). I do not have any example that I know of where it would make sense to treat them as inline, but maybe you do.

For nowiki, inline (ie SPAN) is definitely the way to go in most cases.

For other tags, an icon with a dialog to edit them is the safest way to go, given the number of extensions around.

The tricky thing for you is that you will have to decide the level of compatibility you want with wikitext. Putting too many icons+dialogs for compatibility reasons will make the WYSIWYG less powerful/user-friendly but more compatible.

[Wiktor Walc]

This has been solved by a patch provided by ycombarnous in #1437.

Separate dialog box for Special Tags is now also used for nowiki, noinclude, includeonly tags.

Previous handling of <nowiki> tags was invalid, because line breaks were lost in IE. It is much safter to handle all special tags like we do with templates.

It is probably not the ideal way of dealing with it, but it seems to work.

Feel free to reopen the ticket.