Last modified: 2011-07-07 17:29:21 UTC
Minimal test case: </div>{{Special:Newpages}} The div is not tidied or sanitized. There needs to be no new pages in the Recent Changes table for this to occur. Observed on iu.wikipedia (test URI may be unbroken if a new page is in the RC table). The extra closing tag and the transclusion of Newpages were quite far apart as well.
Another example: <nowiki>foo</nowiki> {{Special:Newpages/limit=5,offset=10000,shownav}} Causes nowiki to UNIQ-QINU out, but only if it preceeds the zero'd report
WTFBBQ: http://en.wikipedia.org/w/api.php?action=parse&text=%7B%7BSpecial%3ANewpages%2Foffset%3D-1%7D%7D <error code="internal_api_error_MWException" info="Exception Caught: Empty $wgTitle in OutputPage::parse">
(In reply to comment #2) > WTFBBQ: > http://en.wikipedia.org/w/api.php?action=parse&text=%7B%7BSpecial%3ANewpages%2Foffset%3D-1%7D%7D > > <error code="internal_api_error_MWException" info="Exception Caught: Empty > $wgTitle in OutputPage::parse"> > That's technically not an API bug. When $wgParser->mTitle is set, the parser should respect that and not be stubborn and use $wgTitle instead. I'll fix it by setting $wgTitle explicitly anyway, but note that this breaks parsing a non-$wgTitle page, which should be possible.
(In reply to comment #3) > (In reply to comment #2) > > WTFBBQ: > > http://en.wikipedia.org/w/api.php?action=parse&text=%7B%7BSpecial%3ANewpages%2Foffset%3D-1%7D%7D > > > > <error code="internal_api_error_MWException" info="Exception Caught: Empty > > $wgTitle in OutputPage::parse"> > > > > That's technically not an API bug. When $wgParser->mTitle is set, the parser > should respect that and not be stubborn and use $wgTitle instead. I'll fix it > by setting $wgTitle explicitly anyway, but note that this breaks parsing a > non-$wgTitle page, which should be possible. > This particular issue was fixed in r44858, bug as reported is still unresolved.
More testing: This also affects {{Special:NewImages}} (such as on a wiktionary with no images) the same. They have addWikiMsg() in common for zero results. It also exposes strip markers for all tested parser extension tags that appear *before* the call (but not after?). Renaming bug to clarify. {{Special:Prefixindex}} and {{Special:Recentchanges}} are not affected. I don't know how to get {{Special:Allpages}} to return zero results.
(In reply to comment #5) > I don't know how to get {{Special:Allpages}} to return zero results. Might be possible by using 'Show preview' and a wiki with no pages.
Bug 16744 may be related.
(In reply to comment #5) > More testing: > > This also affects {{Special:NewImages}} (such as on a wiktionary with no > images) the same. They have addWikiMsg() in common for zero results. It also > exposes strip markers for all tested parser extension tags that appear *before* > the call (but not after?). Renaming bug to clarify. Right. addWikiMsg() calls wfMsgExt() with option 'parse' so we have another case of recursively calling $wgParser->parse() which should be avoided. Fix could be to simply not output the message if the special page is included.
Tim, can you take a look at this?
Another test case: == Foo == {{Special:OldReviewedPages/limit=3,category=Biblia}} This is causing strip markers to be exposed on pl.wikipedia.org.
(In reply to comment #10) > Another test case: > > == Foo == > {{Special:OldReviewedPages/limit=3,category=Biblia}} > > This is causing strip markers to be exposed on pl.wikipedia.org. > It appears also on other wikis, where is enabled FlaggedRevs.
There is also a discussion of this at http://www.mediawiki.org/wiki/QINU_fix -- I'll add a link there into 17329 so Googlers find good info about the fix
Anyone know if bug 16744 is a duplicate or is it a different problem?
Not really a dupe IMHO (bug 16744 is fixed, this one not yet), but the same basic problem, yes. See bug 17329 for some thoughts on the topic.
Addendum: this seems to happen in Special:Newpages when an edit (page creation in this case) gets tagged, such as via an extension like Abuse Filter.
*** Bug 20689 has been marked as a duplicate of this bug. ***
*** Bug 22081 has been marked as a duplicate of this bug. ***
The simplest fix would be to make wfMsgExt() use the same parser instance as the one MessageCache::transform() uses. The reason MessageCache::transform() goes to all the trouble of setting up a separate parser instance is to avoid bugs like this.
*** Bug 23207 has been marked as a duplicate of this bug. ***
Adding dependancy against bug 28532, as that seems to be the action item for this bug
r86304
http://en.wikipedia.org/wiki/User:MarkAHershberger/Bug_Examples#bogus_heading_to_demo_next_bug Maybe Reedy's fix wasn't merged to 1.17wmf1
Indeed, but it's also not been fully reviewed Tag for backport if necessary (not all bug fixes have to be), don't need to reopen the bug
