Last modified: 2012-12-13 15:37:54 UTC
The majority of the system messages that are used by Cite.php as error messages accept full wikimarkup; but those that are displayed in the references section (eg [[MediaWiki:Cite error refs without references]]) silently strip wikilinks. See [[Help talk:Cite errors#Problems]]
To clarify: These messages do not parse internal wikilinks: * MediaWiki:Cite error refs without references * MediaWiki:Cite error references no backlink label * MediaWiki:Cite error references no text You can work around this by using an external link, however MediaWiki:Cite error references no text mangles the link causing the HTML to show.
Correction: This message does not parse wikilinks: MediaWiki:Cite error refs without references These messages do not parse wikilinks or external links: MediaWiki:Cite error references no backlink label MediaWiki:Cite error references no text
*** Bug 24095 has been marked as a duplicate of this bug. ***
Per Platonides at wikitech-1 [1]: I don't see the problem with those messages, though. They look like the rest of Cite errors. Just through the parser instead of the wfMsg() calls (which would have its own problems). Seems that ParserBeforeTidy is too late for doing a recursiveTagParse(). Just replacing the call to Cite::parse() of Cite::error with a call to MessageCache::singleton()->parse() looks like the best solution. We don't need to keep the parser context for errors. And now MessageCache::parse() doesn't pollute the $wgParser state. [1] http://lists.wikimedia.org/pipermail/wikitech-l/2011-September/055208.html
MediaWiki:Cite error refs without references is the only one of these three called during ParserBeforeTidy. The specific problem seems to be that it misses the call to replaceLinkHolders(), although it would be easy to construct a message that missed the call to doBlockLevels() or some of the other operations in there. I don't know whether using MessageCache::singleton()->parse() would really be the best solution though; wouldn't that lose categories and such added by the error message? A "ParserAfterParse" hook (called just after the call to internalParse) might be better. As for the other two, it seems to be a completely different problem. Consider what happens when MediaWiki:Cite error references no text needs to be output: 1. Cite loads MediaWiki:Cite error references no text, via wfMsgNoTrans. Let's say that has the text "Cite error! [[help]]". 2. Cite passes that through recursiveTagParse. The message is now something like "Cite error! <!--LINK 12:0-->". 3. This error text gets embedded into the wikitext to be output for the <references/> tag. 4. The wikitext to be output from the <references/> gets run through recursiveTagParse again. So the link marker gets interpreted as a comment and gets removed. In this case, using MessageCache::singleton()->parse() would give the same sort of problem that using external links gives for those messages. The best fix would be to skip step 2 completely.
Created attachment 9421 [details] Fix double-parsed error messages Here is a patch to fix the second of the two issues, where MediaWiki:Cite error references no backlink label and MediaWiki:Cite error references no text are double-parsed and so cannot contain wikilinks or external links.
Created attachment 9422 [details] Add and use a "ParserAfterParse" hook Here is a proof-of-concept patch to add the "ParserAfterParse" hook mentioned above, and then use it in Cite to fix the problem with MediaWiki:Cite error refs without references. A real patch would update docs/hooks.txt too, and anything else that might be necessary. And might pick a better name than "ParserAfterParse".
(In reply to comment #6) > Created attachment 9421 [details] > Fix double-parsed error messages > > Here is a patch to fix the second of the two issues, where MediaWiki:Cite error > references no backlink label and MediaWiki:Cite error references no text are > double-parsed and so cannot contain wikilinks or external links. Modified patch applied in r102972.
Created attachment 9443 [details] Alternate solution using MessageCache::singleton()->parse() Alternate solution to Roan's committed one using MessageCache::singleton()->parse() for all error messages- we were working on the same bug. Does not support categories from error messages. Might be a good or bad thing.
(In reply to comment #9) > Alternate solution to Roan's committed one using > MessageCache::singleton()->parse() for all error messages- we were working on > the same bug. Does not support categories from error messages. Might be a good > or bad thing. Categories in the error messages are heavily used on enwiki. There are even bots that watch these categories to try to fix the errors. Also, did you test this with the other errors? In a quick test here, it seems to do just as I predicted in comment 5.
Specifically, en.wiki uses [[Template:Broken ref]] to add the message and the category, based on namespace. Also: [[MediaWiki:Cite error group refs without references]] does not support wikilinks, so it uses an external link hack.
Comment on attachment 9421 [details] Fix double-parsed error messages Roan applied this
(In reply to comment #7) > Created attachment 9422 [details] > Add and use a "ParserAfterParse" hook > A real patch would update docs/hooks.txt too, and anything else that might be > necessary. And might pick a better name than "ParserAfterParse". I'm looking at this today. Could you supply a modification to docs/hooks.txt so that I can apply this?
Created attachment 9504 [details] Patch to docs/hooks.txt (In reply to comment #13) > (In reply to comment #7) > > Created attachment 9422 [details] > > Add and use a "ParserAfterParse" hook > > > A real patch would update docs/hooks.txt too, and anything else that might be > > necessary. And might pick a better name than "ParserAfterParse". > > I'm looking at this today. Could you supply a modification to docs/hooks.txt > so that I can apply this? Ok.
Mark, where is this situated?
(In reply to comment #15) > Mark, where is this situated? r102972 is Roan's revision. It is without the hook, so I guess the other part isn't needed.
(In reply to comment #16) > r102972 is Roan's revision. It is without the hook, so I guess the other part > isn't needed. r102972 is the patch in attachment 9421 [details], which fixes the problem with MediaWiki:Cite error references no backlink label and MediaWiki:Cite error references no text. r102972 does not fix the problem with MediaWiki:Cite error refs without references; I have not checked to see whether that problem might have been fixed by some other revision or whether it is still outstanding.
Confirmed: The issue with all three messages is resolved. * MediaWiki:Cite error references no backlink label * MediaWiki:Cite error references no text * MediaWiki:Cite error refs without references
MediaWiki:Cite error refs without references This interface page is still not fixed. Have to use an external link as an internal wikilink does not work.
(In reply to comment #19) > MediaWiki:Cite error refs without references > > This interface page is still not fixed. Have to use an external link as an > internal wikilink does not work. Reopening then.
Brad, is this patch worth putting into Gerrit?
(In reply to comment #21) > Brad, is this patch worth putting into Gerrit? Yes, it is. But since it touches core and an extension, it apparently needs to be done in two parts: Gerrit change #11736 and Gerrit change #11737.
Both patches were merged.
There is the comment at https://en.wikipedia.org/w/index.php?title=MediaWiki%3ACite_error_refs_without_references&diff=512245290&oldid=512244781 that says that it isn't fixed. I haven't further tested.
Looks fixed to me. I've asked Gadget850 for details.
Can you please assign the bugs you mark as ASSIGNED or FIXED? Clicking the "take" link adds just an extra second to your work, improves our workflow and avoids any chance to get pointless notifications like this one. :) Background & discussion: http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/064874.html - please follow-up there is you wish. Thank you!
(In reply to comment #26) > and avoids any chance to get pointless notifications like this one. :) Especially pointless on bugs closed 4 months ago. ;)
(In reply to comment #25) > Looks fixed to me. I've asked Gadget850 for details. I restored the MediaWiki page and it now works. Close as fixed.
