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.