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.