* (bug 27655) Require token for watching/unwatching pages
* Previously done for API (bug 29070) in r88522
* As with markpatrolled, the tokens are not compatible and made that way on purpose. The API requires the POST method and uses a universal token per-session. Since the front-end is all GET based (also per convention like in markpatrolled and rollback) they are stronger salted (title / action specific)
* ajax.watch used the API already and was switched in r88554.
* The actual watching/unwatching code was moved from WatchAction->onView to WatchAction::doWatch. This was done to allow the API to do the action without needing to generate a token like the front-end needs (or having to duplicate code). It is now similar to RecentChange::markPatrolled (in that it also a "central" function that does not care about tokens, it's called after the token-handling)
* JavaScript / Gadgets that utilize action=watch in their scripts:
** Effects should be minimal as they should be using the API (see r88522 and wikitech-l)
** If they use index.php and scrap the link from the page, they can continue to do so.
* There are links to the watch action all over the place. I've tried to catch most of them, but there may be some I miss. Migration in most cases is just a matter of adding an array item to the $query for:
'token' => WatchAction::getWatchToken( $title, $user [, $action] )
or changing:
Action::factory( 'watch', $article )->execute();
to:
WatchAction::doWatch( $title, $user );
While replacing the usages in some cases an instance of Article() no longer had to be created, in others $wgUser had to be retrieved from global (which was implied before but needs to be given directly now)
Other notes:
* Article->unwatch() and Article->watch(), which were deprecated as of 1.18 and are no longer used in core, may be broken in scenarios where the Request does not have a 'token' but is making a call to $article->watch()
* Some extensions need to be fixed, I'm currently running a grep search and will fix them a.s.a.p
[1] http://www.mediawiki.org/wiki/ResourceLoader/Default_modules?mw.user#tokens
* Fixed one check in Skin::addToSidebarPlain() that used user language for existence and content language for message's content
* Changed SkinTemplate::buildContentNavigationUrls() to use Title::getDefaultMessageText() instead of wfEmptyMsg()
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.
