Last modified: 2011-03-13 18:06:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13821 - FCKeditor extension (WYSIWYG): new hook needed
FCKeditor extension (WYSIWYG): new hook needed
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Wiktor Walc
: easy, patch, patch-need-review
Depends on:
  Show dependency treegraph
Reported: 2008-04-22 12:52 UTC by Wiktor Walc
Modified: 2011-03-13 18:06 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

adds new hook to Sanitizer (461 bytes, patch)
2008-04-22 12:52 UTC, Wiktor Walc
same as previous, corrected indentation (454 bytes, patch)
2008-04-22 13:01 UTC, Wiktor Walc

Description Wiktor Walc 2008-04-22 12:52:28 UTC
Created attachment 4833 [details]
adds new hook to Sanitizer


FCKeditor extension uses it's own parser in Ajax calls to convert wiki text into HTML.
This customized parser actually simply extends MediaWiki parser by overriding original methods and modifies the way how text is parsed (e.g it does not perform template substitution, keeps HTML comments).

There is one problem with templates (reported here:

The problem:

Suppose we have:

| {{Hl2}} | Cell 1 
| {{Hl2}} | Cell 2 

FCKeditor extension converts {{Prettytable}} to unique string identificator before sending text to internalParse(). This uniqueid is unfortunately later stripped by Sanitizer::fixTagAttributes(). 
I have already fixed the FCKeditor extension - adding SanitizerAfterFixTagAttributes hook allows me to add back required text to $attribs array, but the problem is that now users must apply manual changes in the MediaWiki core in order to have it fixed.

It would be great if this hook (SanitizerAfterFixTagAttributes) could be added to the core in MediaWiki 1.13.
Comment 1 Wiktor Walc 2008-04-22 13:01:14 UTC
Created attachment 4834 [details]
same as previous, corrected indentation
Comment 2 Andrew Garrett 2008-04-22 13:03:38 UTC
Fixed in r33726, r33725.
Comment 3 Brion Vibber 2008-04-22 17:30:33 UTC
Reverted in r33747. This seems like a really bad place to put such a hook, and it's ugly and weird to boot.
Comment 4 Wiktor Walc 2008-04-22 18:30:10 UTC
Ok, how about adding a hook at the end of Sanitizer::setupAttributeWhitelist()? Does it sound better?
It seems that this function is called only once by Sanitizer. Other users could possibly disallow some unwanted attributes with this hook.

With this hook I could change the $whitelist array a little bit, add another "fake" attribute to each element and pass unique id of a template definition.
All I need to do is to tell MediaWiki to not strip some fake attributes.
Comment 5 Brion Vibber 2008-04-22 18:47:46 UTC
A basic issue is that this is some global state... are you conditionally switching in this hook conditionally for special processing or is it always going to go to general HTML output?
Comment 6 Wiktor Walc 2008-04-22 19:50:43 UTC
Yes, this is a hook that could be enabled only in specific cases (when ajax call is requested by FCKeditor and wfSajaxWikiToHTML command is executed), I must admit that didn't think about that.
So, this hook wouldn't be used on each page request.
Comment 7 Siebrand Mazeland 2008-08-18 16:59:58 UTC
Assigned: Andrew. Hope he can bring this to a satisfactory close.
Comment 8 Andrew Garrett 2008-08-29 06:21:43 UTC
Reassigning to Wiktor. 
Comment 9 Chad H. 2008-09-22 16:46:17 UTC
Changing File/Repo ==> General/Unknown...definitely not a File/Repo issue.
Comment 10 Andrew Garrett 2009-03-05 00:49:05 UTC
Closing this bug as there doesn't seem to be a satisfactory resolution.

Note You need to log in before you can comment on or make changes to this bug.