If an <nowiki> and firends is used inside an function, then instead of generating a result, the UNIQ key is exposed instead, for example: "{{#tag:source|<nowiki>foo</nowiki>|lang=java}}" gives UNIQ7f095fb854002218-nowiki-00000000-QINU in one instance.
Version: unspecified
Severity: normal
URL: http://en.wikipedia.org/wiki/User:AzaToth/X23
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T28213 Strip marker (UNIQ / QINU) issues (tracking) | |||
| Resolved | None | T16959 UNIQ... exposed to anonymous users when hook "InternalParseBeforeLinks" uses specific messages | |||
| Resolved | None | T16562 UNIQ key exposed when feeding strip markers into {{#tag:source |
The convention is that text inserted into the unstrip array should be fully unstripped already. This is because unstrip() is a performance hotspot, much more common than strip item insertion, so it makes sense to perform as much of the processing as possible during insertion.
Confirmed this with the latest SyntaxHighlight_GeSHi and SVN HEAD, but not with Cite.
Re-classifying as a SyntaxHighlight_GeSHi problem. It should be fixed there, not in core MW.
Assigning to robla since this is a "high" priority and X!'s user page says he is extremely busy IRL as of 17:57, 20 March 2011 (UTC)
(In reply to comment #6)
Why is it a high priority?
These sort of niggling little problems are piling up. Perhaps this particular one is something that we can live without fixing RIGHT now, but AFAICT, this and other dependencies of Bug #26213 are going to keep coming until we have something to tell authors to look for when trying to solve the problem or to test for when writing new code.
The priority was set after a triage that said deployed extensions are higher priority. This bug is on a deployed extension. See http://www.mediawiki.org/wiki/User:MarkAHershberger/BugDemo#Bug_14562 Also on that page, a demonstration of Bug #22555 which is a problem with ParserFunctions and can also be seen on Wikipedia: http://en.wikipedia.org/wiki/User:MarkAHershberger/Bug_Examples#Bug_14562
Reading back through the reports it is clear that some users think their wikitext is at fault ('basically a big flashing sign that says "BAD WIKICODE HERE".')
Ideally, I'd like to do a sprint to fix Bug #26213. This bug is a good place to start.
Mark and I discussed this one. This bug is going to low priority, because it's relatively minor, but there is some UNIQ cleanup work that could be high priority.
Change 141056 had a related patch set uploaded by Brian Wolff:
Prevent OutputPage::addWikiText and friends from causing UNIQ fails
Change 141056 merged by jenkins-bot:
Prevent OutputPage::addWikiText and friends from causing UNIQ fails
whoops, what am I doing. This one has a different cause for the UNIQ's. That patch won't fix it.
@Bawolff, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?
@Qgil I didn't even realize this was assigned to me (Its all Nemo's fault! (jk))
Basically this got assigned to me, because I submitted a patch, which got merged, and then the bug got marked fixed and at that time we were following the convention that bugs should be assigned to someone once they fix it. But then bug got re-opened (because I was actually fixing a different bug) and I was still assigned and didn't realize it.
I agree with priority. Without looking at the code, one could probably fix this by just doing unstrip on the input to the source tag, so probably not that hard a bug. However I don't have any plans to work on it right now.
I can no longer reproduce this bug on mediawiki.org.
{{#tag:source|<nowiki>foo</nowiki>|lang=java}}Renders the expected output of "foo" in a preformatted block for Java.