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.
* Article constructor needs to be called with zero as second parameter
* Run stylize.php over new files
* Add Action::getLang() for consistency with other context accessors
* Fix declaration of FormAction::alterForm(), doesn't need to be passed by reference
* Fix inline use of Credits::getCredits() in SkinTemplate and SkinLegacy
* Also moved there generic <meta> and removed OutputPage::addDefaultMeta() with its $called static local variable which was breaking the output when generating multiple pages on the same request (rebuildFileCache.php, dumpHTML.php) since that function could only be executed completely once for all instances, and not once per instance
* Moved default module from OutputPage::output() to its own function and don't call it when executing a body only request, since it's useless in that case
* Call Skin::setMembers() from Skin::initPage() instead of Skin::outputPage()
TODO:
* Are there instances where we might want to restrict CSS as well as JS?
* Would a $wg config option and/or user preference and/or index.php GET parameter to limit inclusion be useful?
* Can we deprecate any of the existing $wg config options?
* What's going on with the duplicated code between OutputPage and SkinTemplate?
Additionally, *cough* *cough*:
* Add a Title::isMainPage helper for the fairly common $title->equals( Title::newMainPage() ); test.
* Update wfMessageFallback to also accept an array of message keys instead of requiring them listed as arguments to the function.
* Move the bulk of wfMessageFallback code into Message.php instead of leaving it in GlobalFunctions.php
* Change the wfMessageFallback implementation so that the Message class handles the fallbacks themselves eliminating any side effects caused by the fact that wfEmptyMsg always used usedb=false, language=userlang when one might actually use a different language or usedb setting in the message object that actually returned the text (this may be considered a wfEmptyMsg regression in 1.18).
* Make blank "" message contents fallback like nonexistant messages do.
* Re use the new tabAction array handling used to support mainpage-nstab in the talk and view tabs instead of making wfEmptyMsg calls directly in SkinTemplate.
* replaced calls to Article::getLatest() by Title::getLatestRevID()
* introduced Skin::isRevisionCurrent()
* made checks on Skin::pageStats() more coherent
Did this by moving RL <link> generation from getHeadLinks() to buildCssLinks() (Trevor did this earlier), but did it right this time:
* Updated callers for buildCssLinks() parameter list change so stuff doesn't explode
* Considered making buildCssLinks() tolerant of a missing $sk parameter, but decided against this: it's not used in SVN extensions anywhere
* Changed addInlineStyle() to add styles to $this->mInlineStyles instead of $this->mScripts. This unbreaks addInlineStyle(), which was used for CSS previews
* Added styles added through addStyle()/addInlineStyle() in the right place (right after normal RL styles)
Note that in vector this does move the fixalpha stuff above bottomscripts while it was after it before, theoretically though this shouldn't cause any trouble.
A "Relevant" is used by the skin to determine what title to display tabs for. This setting allows pages like Special:MovePage (which is linked to from the tabs themselves) to retain the tabs specific to the page relevant to it when switching to the special page.
Similaly a "Relevant" user is used by the skin to display things in the toolbox which would usually only be displayed on the user's userpage and talkpage, pages like Special:Contributions which are linked to by the toolbox can use this to retain the toolbox links when switching between the user pages and these special pages.
content_actions hooks no longer work and have been dropped from the code, the hooks that affected vector before now affect all skins.
A few logic changes were made to make for a clean merge:
- vector was using vector-???-??? messages while SkinTemplate was using '???' messages. So as a side effect of merging that together all skins now support messages like '$skinname-view-history' which will fallback to the standard message if not defined.
- For MediaWiki: pages where the page does not exist but the message does in the i18n system SkinTemplate displayed "Edit" while Vector displayed "Create"; All skins now display "Edit".
- For users without undelete permissions SkinTemplate displayed an "Undelete" tab if the user had deletedhistory and deletedtext permissions. Vector would only display the tab for users with both deletedhistory and undelete permissions; The new behavior in all skins is to always display a tab if you have deletedhistory (since Special:Undelete will always have something to display) but display a "View ... deleted" instead of "Undelete" message if you do not have undelete permissions.
- Skins no longer need to hardcode tests for the &action= to decide if they should ignore the accesskey on some tabs, tabs which should not have an accesskey in the current page now have a "tooltiponly" key set to true.
This is partially made because there are skins where separate login and createaccount links are made, not giving them proper login and createaccount links in the personal_urls means partial reimplementation of personal_urls code in the skin (or worse, no support for features like $wgSecureLogin in these skins when they don't keep up with core).
