Last modified: 2012-09-19 18:13:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T33051, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31051 - References to /resources should target the correct mwversion
References to /resources should target the correct mwversion
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: High critical (vote)
: ---
Assigned To: Aaron Schulz
:
Depends on:
Blocks: 29068
  Show dependency treegraph
 
Reported: 2011-09-21 00:24 UTC by Krinkle
Modified: 2012-09-19 18:13 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2011-09-21 00:24:40 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.
Comment 1 Roan Kattouw 2011-09-21 00:29:41 UTC
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.
Comment 2 Aaron Schulz 2011-09-21 00:42:16 UTC
There is already a resources-1.18 symlink in live-1.5. Is the problem that nothing is using it?
Comment 3 Aaron Schulz 2011-09-21 00:46:39 UTC
(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.
Comment 4 Aaron Schulz 2011-09-21 19:47:54 UTC
What are some example URLs for getting the 404s?
Comment 5 Krinkle 2011-09-21 22:29:25 UTC
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)
Comment 7 Krinkle 2011-09-21 22:34:14 UTC
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.
Comment 8 Aaron Schulz 2011-09-26 18:06:27 UTC
Fixed with $wgResourceBasePath var in 1.18wmf1. This could probably be ported to /trunk.
Comment 10 Krinkle 2012-04-11 18:15:23 UTC
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
Comment 11 Sam Reed (reedy) 2012-04-11 18:51:36 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links