Last modified: 2012-09-19 18:13:55 UTC
Right now /w/resources appears to point to 1.17 for all wikis (as it's still the default, which is fine for a default). However on test2.wikipedia.org, scripts referring to something in /resources from the web (such as ResourceLoader in debug mode) is getting numerous 404 errors for files It assumes exist (which do exist in 1.18). Either /resources should adhere the wiki of the hostname it's referred on, or we need something similar to /skins-1.xx. In the latter case core would have to be adjusted as it currently does not support a custom location for the resources directory.
CC Aaron. This was not a problem when I did my improvised het deploy thing for 1.17, because 1.16 didn't have a resources directory, so I never realized it until Krinkle reported this bug on IRC. We will need to have symlinks for resources-$VERSION like we already have for skins-$VERSION and extensions-$VERSION, and I will need to make the URL to the resources directory configurable in MediaWiki. The bug only affects a few new/changed files. In debug mode, all new/changed JS files in the resources directory are affected. In non-debug mode, only new/changed images in the resources directory (apart from jQuery UI themes, there's only one of those) are affected and only in IE7 and below.
There is already a resources-1.18 symlink in live-1.5. Is the problem that nothing is using it?
(In reply to comment #2) > There is already a resources-1.18 symlink in live-1.5. Is the problem that > nothing is using it? Nevermind, didn't catch the above.
What are some example URLs for getting the 404s?
Stating the obvious, but it's not just 404s, it's version incompatibility as well. For example: http://test2.wikipedia.org/w/resources/jquery/jquery.js loads 1.4.2 (which was the jQuery version in MediaWiki 1.17) instead of jQuery 1.6.3 (the one in MediaWiki 1.18). Example for 404 error: (anything added to resources since 1.17) * http://test2.wikipedia.org/w/resources/mediawiki.page/mediawiki.page.ready.js * http://test2.wikipedia.org/w/resources/mediawiki/mediawiki.user.js * etc. They are called in several places, but the most common scenario: * An image referenced from a css-stylesheet (icon or background image) - both in debug mode and in production mode * The javascript and stylesheets themselves (when in debug mode js is loaded from /resources/ instead of packed from load.php)
http://bits.wikimedia.org/test2.wikipedia.org/load.php?debug=true&lang=en&modules=mediawiki.user http://test2.wikipedia.org/w/resources/mediawiki/mediawiki.user.js
I just learned on IRC that a /resources-1.18/ alias does exist on the cluster. However there appears to be a problem with it. For some reason the following header is sent for .js files loaded from there: Content-Type:application/x-javascript That is causing browsers like Google Chrome to instead ask the user to download it (it should be text/javascript, since it's not an AJAX response, just a normal javascript file) Example: http://test2.wikipedia.org/w/resources-1.18/mediawiki/mediawiki.user.js -- So far we learned that it's probably impossible and/or unwanted to magically let /resources go to 1.17 or 1.18 depending on which hostname it is called on. Instead we want to make that directory not hardcoded but variable via a new wgResourcesPath ($wgScriptPath/resoruces) and wgResourcesDirectory( $IP/resources ). The former would be set per mwversion group (just like we do with wgStylePath for /skins-1.18/ and wgExtensionAssetsPath (/extensions-1.18) ). The latter can probably stay the default value since the folder on-disk isn't named differently it's just the web access to it using a symlink.
Fixed with $wgResourceBasePath var in 1.18wmf1. This could probably be ported to /trunk.
Same again with 1.20wfm1 https://test2.wikipedia.org/w/resources/jquery/jquery.js (testwiki2 1.20wmf1) https://www.mediawiki.org/w/resources/jquery/jquery.js (mediawikiwiki 1.20wmf1) https://en.wikipedia.org/w/resources/jquery/jquery.js (enwiki 1.19wmf1) All load the same file, whereas they should be different
reedy@fenari:/home/wikipedia/common$ mwscript eval.php test2wiki > var_dump( $wgResourceBasePath ); string(21) "/w/resources-1.20wmf1" Of course those are gonna work like that, /resources is set on the file system, so /resources should point to the main release in use. Stuff in MW should be using $wgResourceBasePath which is seemingly set correctly, and load it from there lrwxrwxrwx 1 reedy wikidev 44 2012-02-14 22:39 resources -> /usr/local/apache/common-local/php/resources lrwxrwxrwx 1 reedy wikidev 49 2012-04-10 20:31 resources-php-1.19 -> /usr/local/apache/common-local/php-1.19/resources lrwxrwxrwx 1 reedy wikidev 53 2012-04-10 20:31 resources-php-1.20wmf1 -> /usr/local/apache/common-local/php-1.20wmf1/resources