Last modified: 2012-04-18 16:05:30 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 T33173, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31173 - Implement $wgResourcesPath and $wgResourcesDirectory
Implement $wgResourcesPath and $wgResourcesDirectory
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal major (vote)
: 1.20.0 release
Assigned To: Krinkle
Depends on:
  Show dependency treegraph
Reported: 2011-09-26 21:14 UTC by Krinkle
Modified: 2012-04-18 16:05 UTC (History)
2 users (show)

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


Description Krinkle 2011-09-26 21:14:56 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.
Comment 2 Mark A. Hershberger 2012-01-23 15:46:28 UTC
switch to milestone, remove release tracking dep
Comment 3 Rob Lanphier 2012-03-02 22:33:30 UTC
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.
Comment 4 Krinkle 2012-04-11 18:11:19 UTC
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.
Comment 5 Krinkle 2012-04-11 18:12:14 UTC
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 :)
Comment 6 Krinkle 2012-04-13 01:22:50 UTC
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 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 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

* 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?
Comment 7 Krinkle 2012-04-13 01:26:28 UTC
btw, to give an example of what the resulting url structure is now:

(w + resource base path + version + ./resources )

should probably just be
Comment 8 Krinkle 2012-04-18 16:05:30 UTC
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).

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