Opened 12 years ago

Closed 11 years ago

#1010 closed New Feature (fixed)

FCK should support MW custom tags

Reported by: barns Owned by:
Priority: Normal Milestone:
Component: Project : MediaWiki+FCKeditor Version:
Keywords: Confirmed Cc:

Description

You can get a list of allowed custom tags inherited from MW extensions, for example for www.mediawiki.org, go to Special pages/version, and you will get:

Parser extension tags<br><timeline>, <hiero>, <charinsert>, <ref>, <references>, <inputbox>, <imagemap>, <source>, <poem>, <categorytree>, <fundraising>, <fundraisinglogo>, <fundraisingdonor2> and <pre>

Ideally you should have a button proposing to enter a custom tag, offering the list from above, for instance:

<tag_label param1 param 2> </tag_label param 1 param 2>

should be allowed.

In addition, manual tag entering should be allow, like the nowiki, noinclude, includeonly ones. FCK just removed my nowiki tags from my article.

Change History (10)

comment:1 Changed 12 years ago by Frederico Caldeira Knabben

#1018 has been marked as DUP of this one.

comment:2 Changed 12 years ago by barns

Ok, let's already implement the standard wiki tags: includeonly, noinclude, onlyinclude, nowiki.

To do so, I would recommend to add the "style" select box in FCK for Mediawiki, and add above tags as span id tags (each with its own color and id), like:

<span id="mw_nowiki">

Conversion to wikitext would be done through FCKeditor/plugins/mediawiki/fckplugin.js in the span case, switching based on the span id.

Conversion from wikitext could be done via a replace in the PHP parser, before wiki interpreter.

Important: the "pre" tag should be moved from "format" select to here, because there can be multiple lines ones.

comment:3 in reply to:  2 Changed 12 years ago by barns

Replying to ycombarnous:

<span id="mw_nowiki">

I mixed id and classes, I meant:

<span class="mw_nowiki">

comment:4 Changed 12 years ago by Frederico Caldeira Knabben

That's is certainly the way to go, but I would wait for FCKeditor 2.5 as it will bring a rework on the styles system.

In the mean time, we could already change our parser to substitute those wiki tags with <span class="fck_mw_xxx"> for the standard tags, and the JavaScript data processor to bring them back to theirs correct wiki representation.

For custom tags, we could do the same, adding two new attributes: _fck_mw_customtag="true" and _fck_mw_tagname="xyz". The class name will always have the "fck_mw_xyz" format, so one can define specific styles to tags.

BTW, should we display the four standard wiki tags with some style by default (like background color)? Any proposal in this sense?

comment:5 in reply to:  4 ; Changed 12 years ago by barns

Replying to fredck:

For custom tags, we could do the same, adding two new attributes: _fck_mw_customtag="true" and _fck_mw_tagname="xyz". The class name will always have the "fck_mw_xyz" format, so one can define specific styles to tags.

I would probably put custom tags into a separate request, as it is more complex generally speaking, and probably needs deeper analysis. For instance, most of them will require the CR to be honored, and text to be uninterpreted. So in a sense, it would probably be safer to treat them the same way as you do with templates, so that the text inside the tags do not get interpreted/altered by FCK.

BTW, should we display the four standard wiki tags with some style by default (like background color)? Any proposal in this sense?

For span style, I would advise very light background colors to differentiate them + a background image aligned on top-right hand corner that would be a small box with the name of the "style". For pre, just keep it the same as it is right now. What do you think?

comment:6 in reply to:  5 Changed 12 years ago by Frederico Caldeira Knabben

Replying to ycombarnous:

Replying to fredck: I would probably put custom tags into a separate request, as it is more complex generally speaking, and probably needs deeper analysis. For instance, most of them will require the CR to be honored, and text to be uninterpreted. So in a sense, it would probably be safer to treat them the same way as you do with templates, so that the text inside the tags do not get interpreted/altered by FCK.

Well... based on this ticket title, this one seams to be the right ticket for it :)

But you are correct, we should separate things here, so feel free to open a dedicated ticket for includeonly, noinclude, onlyinclude and nowiki, pointing it to this ticket for some reference.

For span style, I would advise very light background colors to differentiate them + a background image aligned on top-right hand corner that would be a small box with the name of the "style". For pre, just keep it the same as it is right now. What do you think?

The background color would definitively be good. The icon, could pollute too much the text, mainly for <nowiki>, which is extensively used. Maybe it would be a nice move to have a dedicated style for <nowiki>, and give a try for the icon thing to the others.

It would be wonderful if someone could come with a proposal style definition and icons for that.

comment:7 Changed 12 years ago by Frederico Caldeira Knabben

I've just added the JavaScript support for it with [613]. We can refine it later.

It's still needed the relative PHP code (Wiktor will be committing it soon).

comment:8 Changed 12 years ago by Wojciech Olchawa

Keywords: Confirmed(New Feature) added
Type: BugNew Feature

comment:9 Changed 12 years ago by Wojciech Olchawa

Keywords: Confirmed added; Confirmed(New Feature) removed

comment:10 Changed 11 years ago by Wiktor Walc

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy