The problem is that in this case $wgOut's Title object is not exactely the same $wgTitle because of line 600 of SpecialPage:
$wgTitle = $page->getTitle();
which strips the subpage parameter. Now using SpecialPage::resolveAliasWithSubpage() so that it works in all cases.
Also PHP strikes again for not allowing SpecialPage::resolveAliasWithSubpage( $title->getDBkey() )[0] syntax. YAY :)
TODO: Since the alias is globally available from the start, the 'mw' argument in the wrapper is redundant, so that should be removed at some point as well.
Done by adding isKnownEmpty() to ResourceLoaderModule and overriding it to check for page existence in ResourceLoaderWikiModule. Needed to rearrange some code in OutputPage::makeResourceLoaderLink() to have the emptiness check and dropping of modules work properly. Also factored the page_touched check in ResourceLoaderWikiModule::getModifiedTime() out to a separate method (getTitleMtimes()) and moved in-object caching there as well, so getModifiedTime() and isKnownEmpty() share code and caching for their timestamp/existence checks.
This does not account for the case where e.g. a user has user CSS but no user JS: I had implemented this by checking for $context->getOnly() in getTitleMtimes(), but then realized it's not safe to do this in a function called by getModifiedTime(): it causes the timestamp list in the startup module to only take scripts in account for wiki modules, because the startup module has &only=scripts set
* merged <script> and if ( window.mediaWiki ) block with the one of mediaWiki.loader as stated in the doc
* removed dependency of $wgTitle
* the two only calls to this functions are in SemanticForms, but will not affect current version of MediaWiki:
** specials/SF_UploadWindow.php: this file is only used before 1.16
** specials/SF_UploadWindow2.php: the call is part of the else branch of a "method_exists( $wgOut, 'addModules' )" check, which means it's not called since 1.17
Also eliminate some duplicate code introduced into SpecialPage::headElement() in r61071 by calling Skin::getPageClasses() instead, and use $sk parameter instead of $wgUser->getSkin() to get skin name.
* Now replacing parameter before parsing where possible
* Used 'parseinline' for 'nosuchuser' message in Special:Userlogin for consistency with other error messages
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?
This should coerce nulls to empty arrays to make them play a little nicer.
Also added a doc comment that the format and contents of the $option parameter need to be described in some way; judging by the below getXVO() function they're used to produce the X-Vary-Options header along with the vary cookie settings, but offhand wouldn't know what acceptable options are or how to look them up (X-Vary-Options is something we made up as an extension for our patched Squid servers, so there's no public standard like the HTTP RFCs to look it up in.)
This is following a pair session with Zak Greant on november 12th 2010.
Please review, ammend and commit your changes if you have anything useful
to add.
Please note you will find some humoristics quotes.
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)
- = ChangesList::flag( 'minor' );
- The jquery effects plugin and collapsible implementation, also in those commits, are redundant now.
- If/when skins.commons is needed again, we can simply add that part back in.
- (r78891 is not reverted because the file it altered was deleted while r78865 was -merged)
