Last modified: 2010-12-03 00:12:36 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 13474 - using nowiki to disable markup in a string property garbles factbox and inline query
using nowiki to disable markup in a string property garbles factbox and inlin...
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Markus Krötzsch
Depends on:
Blocks: UNIQ
  Show dependency treegraph
Reported: 2008-03-21 22:22 UTC by S Page
Modified: 2010-12-03 00:12 UTC (History)
2 users (show)

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


Description S Page 2008-03-21 22:22:25 UTC
User Volker Wulf (in message "wikisyntax in text attribute") tried to disable parsing in string using <nowiki> tag and reported "funny characters when I ask".

I reproduced for Type:String.  I found the annotation
  [[String test::<nowiki>Don't parse this [[Test relation::Sandbox2]], what happens?]]

* Displays the exact text in the page (good!).
* Displays "UNIQ4771b2c964a25267-nowiki-0000001C-QINU" in inline queries.
* Displays garbled wiki markup instead of the magnifying glass in the factbox (bad).

It was hard to get MediaWiki to parse wiki markup in strings for SMW 1.0, now it's hard to turn it off!

There's undoubtedly some tricky way to use markup or HTML to disable parsing but it won't be easy for naive users or automatically-generated semantic annotation to apply it.

SMW could provide a different datatype for unparsed text, e.g. Type:Unparsed_string, or a special Property:DontParse that you put on certain properties.  Neither is attractive.
Comment 1 Markus Krötzsch 2008-03-25 10:00:28 UTC
The problem here is once more the order of text processing in MediaWiki. MediaWiki strips out <nowiki>-blocks and inserts placeholder strings UNIQ... instead. It would be possible to expand the UNIQ... placeholders (and the MediaWiki parser does that later on anyway, which is why the page displays properly), but I think we cannot find out how the UNIQ... part was generated (i.e. the orignial user input is lost). Various tags are handled in a similar fashion, including HTML comments and <math> blocks.

It would also be hard to have a datatype for un-parsed strings, since MediaWiki parses (and escapes) strings before SMW even looks for annotations. The only option would be to hook into MediaWiki at some earlier stage, creating extra load and possibly breaking template compatibility.

I do not know how to solve that problem. But a simple workaround would be to omit <nowiki> and to use other escapes for wiki markup instead (e.g. by using hex encoding for "["). I agree that Type:Text should probably do something to expand UNIQ... before storing the result (but then how would we get that expanded text back into a wiki page, without having special markup escaped?).
Comment 2 Markus Krötzsch 2008-04-17 19:57:25 UTC
At leat we now catch this case properly and raise a generic error. No more mess in Factbox or elsewhere.
Comment 3 Andrew Garrett 2010-09-06 03:55:21 UTC
This is causing problems for some work that I'm doing (I'd like to be able to put tag extensions in property values).

What's wrong with just expanding out the strip markers with $wgParser->unstripAll() in the assignment? Is Semantic MediaWiki supposed to store the original wikitext in the database, or the formatted HTML?

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