Last modified: 2012-04-18 16:05:30 UTC
Right now these paths are hardcoded everywhere. However just like /skins/ and /extensions/, things in /resources/ are accessed from the client side as well and need to be customizable for setups such as the one at WMF where there are multiple directories and where web-access sometimes goes through different domains or paths. A temporary fix was done in 1.18wmf1, see also bug 31051.
Search results for /trunk: http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=293&hash=0ba1fbf527a479463bb4db6decfdd33f http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=294&hash=3252094e4d5b9dcedd8c8b9a907ab3ba
switch to milestone, remove release tracking dep
Given we made it through this deployment without having a problem (I think), this probably isn't high priority. Still, it looks like Aaron has already done work on this, so I'm assigning to him.
I still believe this is a blocker because 'resources' just like 'skins' and 'extensions' are directories that are both * accessed directly from the web * have changes between each version it would only be a matter of time before there is a version incompatibility that isn't an incompatibility within a version, but a failure due to mismatch of intended file requested by the versionA client and response of the versionB directory.
There was a livehack for this in 1.18wmf1 but not for 1.19 and 1.20 so supposedly there are no breaking changes in ./resources/ in 1.19/1.20 lucky us :)
So it turns out the work-around for this for 1.19 is quite ugly and abusing variables (may be unintentional due to the unfortunate naming of the variables). Right now neither wgResourcesPath or wgResourcesDirectory has been added to core. And not in a live hack to 1.19wmf1 or 1.20wmf1 either. The current 1.19wmf1/1.20wmf1 config (accidentally) (ab)uses the variable $wgResourceBasePath. $wgResourceBasePath was implemented a while ago although never really used. It is an option to override the internal 'remoteBasePath' property default value of ResourceLoader modules. By default it falls back to $wgScript. In general this means it applies to everything in root, including tests, resources, skins and other paths that may be references in a module. Right now wmf-config (1.19wmf1/1.20wmf1) has a docroot alias named "resources-{version}", so far so good, except that it points to the mwversion-target docroot, not to the 'resources' subdirectory. It works fine but mostly redundant since the default is fine. Moreover the subpages for `extensions` and `skins` overwrite all that since wmf-config also set $wgExtensionAssetsPath and wgStyleSheetPath (pointing to the appropriate version-alias on bits.wikimedia.org). So the few places not over-over-overwritten left that use wgResourceBasePath (some embedded icons in html and locally linked ./resources) don't make use of bits.wikimedia.org caching. So proposing to either: * Implement $wgResourcesPath and $wgResourcesDirectory * Use them everywhere in core, no hardcoded links to ./resources left, just like we do with extensions, skins and uploads already * Remove the weird resources-version=>versiondocroot alias on wmf-config * Instead add one from resources-version=>versiondocroot/resources Or: * Make broader use of $wgResourceBasePath like "wgResourceBasePath/resources", "wgResourceBasePath/skins", "wgResourceBasePath/extensions" * Phase out extensionassets/skinsstylepath variables * Which means we only need 1 alias for resources from now on instead of all these separate ones (e.g. ./stuff-1.20/skins ./stuff-1.20/extensions and ./stuff-1.20/resources on bits.wm.o and on the other domains) Not sure which is better or maybe an alternative solution?
btw, to give an example of what the resulting url structure is now: https://www.mediawiki.org/w/resources-1.20wmf1/resources/jquery/jquery.suggestions.js (w + resource base path + version + ./resources ) should probably just be https://www.mediawiki.org/w/resources-1.20wmf1/jquery/jquery.suggestions.js or https://bits.wikimedia.org/w/resources-1.20wmf1/jquery/jquery.suggestions.js
Marking this as WONTFIX. The features supplied by MediaWiki are more than enough. They were just mis-configured at wmf. We're going to use "wgResourceBasePath/resources" as way to access the resources directlry (which already works as such).
