Last modified: 2010-12-03 00:12:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15474, the corresponding Phabricator task for complete and up-to-date bug report information.
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...
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Markus Krötzsch
http://ontoworld.org/wiki/SMW_unit_te...
:
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: ---


Attachments

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.


Navigation
Links