* Use Linker::linkKnown() instead of link() where possible
* Escape some messages that are escaped in other usages
* Use Title::isSpecial() instead of checking that getPrefixedDBkey() is equals to $wgContLang->specialPage()
* Use XmlSelect, Html::rawElement() and Xml::submitButton() to make sure things are correctly escaped
* Get a Title object instead of using $wgContLang->specialPage()
* Redirect to index.php and changed the name of the <select> to title to use the common way instead of linking to redirect.php?wpDropDown=...
* Made variant tabs hidden on special pages (has no or sometimes wrong/inconsistent effect there; plus it's mainly in the user language)
* Made redirects be in content language again (remove from Title->getPageLanguage())
* fix Fatal error: Call to undefined method CologneBlueTemplate::makeExternalLink()
* Use static Linker functions for all other link functions
CologneBlue: check if browseLinks is an array (in a rare case it isn't, which returns a Warning, see e.g. r91432#c19211)
* 'editfont' => 'sans-serif'; -> trivial (can be set in CSS)
* 'underline' => 0; by languages written in scripts that are hard to read with underlines -> now set in shared.css, which makes it work also when they are used as interface language (note that [lang="xx"] is not yet present on wikitext content by default but will be soon as part of my work on RTL improvements)
* 'quickbar' => 2; by RTL languages. For this, I introduced a new option (5) that sets left/right according to the directionality of your interface language (and automatic is better than setting it in MessagesXx files!). Note that the broken feature was in this case "corrected" by CSS flipping, causing preferences to say "left" while it was actually "right". This commit fixes that bug as well.
Third, it actually would have made more sense to have it them load for wgLang instead of wgContLang, but that's not possible because wgLang is itself dependent on preferences
* (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
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
