In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I am considering removing $wgStyleDirectory rather than further depending on it.
It seems that it's only partially used right now, and making the style directory variable but not other directories is inconsistent as well.
There was some point about this being a feature that makes MediaWiki more flexible, but I'm unsure this is actually adding flexibility, it seems more like unnecessary complexity.
I'm considering just removing it - any points to the contrary would help me make this decision.
- Trevor
Trevor Parscal wrote:
In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I am considering removing $wgStyleDirectory rather than further depending on it.
It seems that it's only partially used right now, and making the style directory variable but not other directories is inconsistent as well.
There was some point about this being a feature that makes MediaWiki more flexible, but I'm unsure this is actually adding flexibility, it seems more like unnecessary complexity.
I'm considering just removing it - any points to the contrary would help me make this decision.
- Trevor
Backwards compatibility. Some systems may not support symlinks $wgStylePath would be sad if you killed $wgStyleDirectory (we provide them in pairs)
Is it that hard to support it?
On 10-11-09 03:42 PM, Platonides wrote:
Trevor Parscal wrote:
In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I am considering removing $wgStyleDirectory rather than further depending on it.
It seems that it's only partially used right now, and making the style directory variable but not other directories is inconsistent as well.
There was some point about this being a feature that makes MediaWiki more flexible, but I'm unsure this is actually adding flexibility, it seems more like unnecessary complexity.
I'm considering just removing it - any points to the contrary would help me make this decision.
- Trevor
Backwards compatibility. Some systems may not support symlinks $wgStylePath would be sad if you killed $wgStyleDirectory (we provide them in pairs)
Is it that hard to support it?
That's a -1 here too, we should be trying to improve flexibility, not drop existing flexibility. If resourceloader isn't listening to $wgStyleDirectory then it's a bug that should be fixed, unless resourceloader has a damn good reason for ignoring existing configuration.
Frankly, for awhile now I've wanted to fix MediaWiki's dependence on a single directory for skins. Currently installing a new skin requires adding a file or two and a directory into skins/. Whilst installing an extension, besides the LocalSettings.php tweak only requires dropping in a single directory. IMHO extensions should be able to provide new skins, just as extensions can currently provide new Special Pages. And the path to where default skins are fetched should be left configurable for those wanting to share skins between installs.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
2010/11/10 Daniel Friesen lists@nadir-seen-fire.com:
If resourceloader isn't listening to $wgStyleDirectory then it's a bug that should be fixed, unless resourceloader has a damn good reason for ignoring existing configuration.
It's a bug that should be fixed and can be fixed relatively easily. However, Trevor also said that other parts of MW already don't obey $wgStyleDirectory . Maybe someone needs to try setting it and see if things break.
Roan Kattouw (Catrope)
Skin extensions exist. Look at extensions/skins.
- Trevor
On 11/10/10 12:32 AM, Daniel Friesen wrote:
On 10-11-09 03:42 PM, Platonides wrote:
Trevor Parscal wrote:
In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I am considering removing $wgStyleDirectory rather than further depending on it.
It seems that it's only partially used right now, and making the style directory variable but not other directories is inconsistent as well.
There was some point about this being a feature that makes MediaWiki more flexible, but I'm unsure this is actually adding flexibility, it seems more like unnecessary complexity.
I'm considering just removing it - any points to the contrary would help me make this decision.
- Trevor
Backwards compatibility. Some systems may not support symlinks $wgStylePath would be sad if you killed $wgStyleDirectory (we provide them in pairs)
Is it that hard to support it?
That's a -1 here too, we should be trying to improve flexibility, not drop existing flexibility. If resourceloader isn't listening to $wgStyleDirectory then it's a bug that should be fixed, unless resourceloader has a damn good reason for ignoring existing configuration.
Frankly, for awhile now I've wanted to fix MediaWiki's dependence on a single directory for skins. Currently installing a new skin requires adding a file or two and a directory into skins/. Whilst installing an extension, besides the LocalSettings.php tweak only requires dropping in a single directory. IMHO extensions should be able to provide new skins, just as extensions can currently provide new Special Pages. And the path to where default skins are fetched should be left configurable for those wanting to share skins between installs.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 10/11/10 08:56, Trevor Parscal wrote:
In relation to: https://bugzilla.wikimedia.org/show_bug.cgi?id=25124 - I am considering removing $wgStyleDirectory rather than further depending on it.
It seems that it's only partially used right now, and making the style directory variable but not other directories is inconsistent as well.
There was some point about this being a feature that makes MediaWiki more flexible, but I'm unsure this is actually adding flexibility, it seems more like unnecessary complexity.
I'm considering just removing it - any points to the contrary would help me make this decision.
I traced back the annotations of $wgStyleDirectory, thinking that it must have been added for some frivolous purpose. It turns out to have quite a long history.
It started off as $wgStyleSheetDirectory and was added by Lee. In the V_PHASE3REORG branch, there was an installer script (install.php) that copied files from a private source location to a web-accessible install path ($IP). The contents of the ./stylesheets directory was copied to $wgStyleSheetDirectory, which defaulted to $IP/style (i.e. a different layout to the source). This was the only use of $wgStyleSheetDirectory at the time.
Today, it doesn't really make sense to set $IP in LocalSettings.php, but originally it was necessary to set it manually, and Lee imagined that it would be some other directory than the place you unpacked the source tarball. It's entirely possible that nobody ever used this scheme other than Lee.
In 1.2, Brion introduced the web installer, which assumed a web-accessible source directory, effectively obsoleting the source/$IP distinction. The web installer set $wgStyleSheetDirectory to $IP/stylesheets, matching the source directory layout. However it wasn't actually used by anything, apart from the old installer.
The feature rotted until 1.7, when Rob Church resurrected it in r14449 and r14797, fixing bug 4033. Presumably it's been rotting again since then, if it's broken like Trevor says.
My preference is to remove it, if it's only going to work for one major version in every 10. I guess the point of it in today's MediaWiki is to allow different wikis to use different sets of skins, or different patched core skins with the same names. There's a number of other ways to achieve the same thing, and I don't think any of them would break so regularly.
Platonides wrote:
Backwards compatibility. Some systems may not support symlinks $wgStylePath would be sad if you killed $wgStyleDirectory (we provide them in pairs)
If you're on Windows XP, you could just use completely separate copies of MediaWiki, maybe with a deployment script to manage them. If you're on Windows Vista or Server 2008, symlinks are supported and you can use the same solutions as on Unix.
$wgStyle[Sheet]Path is a lot more useful than $wgStyleDirectory. We used it during the 1.5 upgrade on Wikimedia, to allow MW 1.4 and 1.5 to run on the cluster simultaneously, with skins-1.4 mapped to the 1.4 skins directory, and skins-1.5 mapped to the 1.5 skins directory. And we use it now to implement bits.wikimedia.org. It's not going to rot while it's in use on Wikimedia.
-- Tim Starling
Tim Starling wrote:
Platonides wrote:
Backwards compatibility. Some systems may not support symlinks $wgStylePath would be sad if you killed $wgStyleDirectory (we provide them in pairs)
If you're on Windows XP, you could just use completely separate copies of MediaWiki, maybe with a deployment script to manage them. If you're on Windows Vista or Server 2008, symlinks are supported and you can use the same solutions as on Unix.
I know. I could also have a unix box with a fat filesystem just for the sake of not having symlinks available ;) The only reason I think one would want to would be to provide a completely different set of skins without touching mediawiki tree and not as extensions. If $wgStyleDirectory is to be removed, seems a good time to also remove its directory listing and store it in DefaultSettings intead.
$wgStyle[Sheet]Path is a lot more useful than $wgStyleDirectory. We used it during the 1.5 upgrade on Wikimedia, to allow MW 1.4 and 1.5 to run on the cluster simultaneously, with skins-1.4 mapped to the 1.4 skins directory, and skins-1.5 mapped to the 1.5 skins directory. And we use it now to implement bits.wikimedia.org. It's not going to rot while it's in use on Wikimedia.
*Nod*. I was pointing out that we usually have one file path variable for each web path one.
wikitech-l@lists.wikimedia.org