Last modified: 2011-08-12 13:34:08 UTC
Created attachment 8887 [details] screenshot of problem breakage in flaggedrevs due to upcoming switch to protocol relative uris ./presentation/language/FlaggedRevs.i18n.php: 'revreview-quick-basic' => '\'\'\'[[{{MediaWiki:Validationpage}}|Checked]]\'\'\' [[{{fullurl:{{FULLPAGENAMEE}}|oldid=$1&diff=cur{{MediaWiki:flaggedrevs-diffonly}}}} review pending changes]]', ./presentation/language/FlaggedRevs.i18n.php: 'revreview-quick-quality' => '\'\'\'[[{{MediaWiki:Validationpage}}|Quality]]\'\'\' [[{{fullurl:{{FULLPAGENAMEE}}|oldid=$1&diff=cur{{MediaWiki:flaggedrevs-diffonly}}}} review pending changes]]', ./presentation/language/FlaggedRevs.i18n.php: 'revreview-quick-see-basic' => '[[{{fullurl:{{FULLPAGENAMEE}}|oldid=$1&diff=cur{{MediaWiki:flaggedrevs-diffonly}}}} review pending changes]]', ./presentation/language/FlaggedRevs.i18n.php: 'revreview-quick-see-quality' => '[[{{fullurl:{{FULLPAGENAMEE}}|oldid=$1&diff=cur{{MediaWiki:flaggedrevs-diffonly}}}} review pending changes]]',
Compare: http://en.wikipedia.org/wiki/User:Aaron_Schulz/test2 http://test.wikipedia.org/wiki/User:Aaron_Schulz/test2
Possible reason: Test Wikipedia's server is set at "//test.wikipedia.org".
(In reply to comment #2) > Possible reason: Test Wikipedia's server is set at "//test.wikipedia.org". That's probably the reason, yes, but whatever FlaggedRevs is doing should account for $wgServer being protocol-relative. I suspect it's prepending $wgServer directly instead of using wfExpandUrl() properly.
FlaggedRevs is just using parser on some wikitext, see comment #1.
So the problem is that wfExpandUrl is called for {{fullurl:}} calls, but it doesn't support relative urls yet. Roan is working on that in trunk.
(In reply to comment #5) > So the problem is that wfExpandUrl is called for {{fullurl:}} calls, but it > doesn't support relative urls yet. > > Roan is working on that in trunk. No, that's not the problem, and it's not fixed in trunk. {{fullurl:}} does, and MUST, output protocol-relative URLs to prevent cache pollution. And constructs like [//foo bar] work just fine. However, there is a difference between how the parser parses [[http://foo bar]] (literal [, external link, literal ]) and [[//foo bar]] (internal link). I'll investigate this at some point this week. It probably needs to be fixed in the parser, and a new parser test.
Fixed in r94346.
