He suggested protected, because of the @private comment, but as we have made more methods public static in the Linker class recently, this seems appropriate.
Breaks unit tests as below, not going to be able to fix them before I disappear for the evening, so might aswell leave trunk clean
ArticleTablesTest testbug14404
Error:
ArticleTablesTest::testbug14404
Undefined offset: 0
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/ArticleTablesTest.php:31
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiTestCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiPHPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.php:60
ParserTests testParserTest #552 - testParserTest with data set #551
Failure:
ParserTests::testParserTest with data set #551 ('RAW magic word', '{{RAW:QUERTY}}', '<p><a href="/index.php?title=Template:QUERTY&action=edit&redlink=1" class="new" title="Template:QUERTY (page does not exist)">Template:QUERTY</a>
</p>', '', '')
RAW magic word
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-<p><a href="/index.php?title=Template:QUERTY&action=edit&redlink=1" class="new" title="Template:QUERTY (page does not exist)">Template:QUERTY</a>
+<p><a href="/index.php?title=Template:RAW:QUERTY&action=edit&redlink=1" class="new" title="Template:RAW:QUERTY (page does not exist)">Template:RAW:QUERTY</a>
</p>
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/parser/NewParserTest.php:545
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiTestCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiPHPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.php:60
Definitely shows different padding with the old cached markup and new styles in FF 5 though it's not a huge difference. Haven't tested in other browsers; IE needs testing in particular as it has funky special style bits.
Recommend:
* old markup should work uncahnged with the new styles -- this avoids any transition problems
* secondarily, consider updating parser cache version to force updates .... but you'd still want to do the above for pages that have been HTTP-cached!
* test all these renderings in all supported browsers and confirm that all is well with old & new markup
Patch by Aryeh Gregor, updated by Roan Kattouw, and updated again by me. I also fixed one bug with modern.css.
Tested in IE6,7,8, Chrome & FF in all skins and both LTR and RTL contexts. I tested with floating images above and below the headers and couldn't find regressions.
commentBlock() exists for the sole purpose of embedding a comment into parentheses if it exists so you can append it to a line of text -- if you're not putting stuff in parentheses, don't use commentBlock() because you're not generating a parenthesized comment block.
Opaque boolean parameters are also very poor form, especially when tacking on multiple ones. There was already a nasty optional '$local' boolean param, forcing all uses of this other parameter to add *two* parameters, making illegible stuff like 'false, false'.
PHP Notice: Use of Linker::makeLinkObj is deprecated. [Called from call_user_func_array in (internal function)] for /w/i.php?title=Special:RecentChanges&translations=filter<ul>
<li>- line - calls Linker::makeLinkObj()</li>
<li>Skin.php line 1552 calls call_user_func_array()</li>
<li>- line - calls Skin::__call()</li>
<li>Renameuser.php line 58 calls SkinVector::makeLinkObj()</li>
<li>- line - calls wfRenameUserLogActionText()</li>
Also make a few changes to the functions available. SpecialPageFactory::resolveAlias() now takes an optional subpage and returns array(<name>,<subpage>). Similarly merge getPage() and getPageByAlias(). There were many examples of (extensions particularly) making dubious assumptions about the presence or absence of subpages or canonical-ness.
I didn't deprecate SpecialPage::getTitleFor() as it's got over six hundred calls. I'm rather undecided on the best position of getPage()/executePath(). Although the latter needs cleanup anyway.
