On 21/05/14 20:38, Stephan Gambke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
There seem to be three popular ways:
- $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for
...
- $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.), using require_once in
...
- $IP/extensions/SkinName/ for everything, the rest as above. This
makes
I'd go for a mixture of option 2 and 3: $IP/skins/SkinName/SkinName.php I agree that skins and extensions should be installed in the same way as much as possible. But I do not agree that this should go so far as to install them in the same directory. They are fundamentally different things - one concerns (ideally) the functionality of the wiki, the other (ideally) its presentation. "But it can both be pulled in using require_once, let's put it in the same place." does not sound right to me. Using that reasoning you could just put all of MW in one directory (or in one file, even) and be done with it. At the same time I do not agree that the skin absolutely has be called the same in all contexts so admins do not get too confused. That's what installation instructions are for. "Plop it into yaddayadda. Done. Activate it using blahdiblah. Done." And, incidentally, what's wrong with &useskin=MonoBook?
Btw: "What stops a new user from plopping the folder into the extensions directory by accident out of habit?"
Three answers - 1 serious, 1 half-serious, 1 not helpful at all (you can pick which is which):
- "New user", "out of habit"? Umm...
- Nothing. And any decently written skin should not care.
- Composer. :P And a decent extension/skin manager built on top of that. (But that's a completely different discussion, agreed.)
Cheers, Stephan
This. All of this.
"And, incidentally, what's wrong with &useskin=MonoBook?"
I think the only thing really wrong with it is that support for it hasn't been implemented; the expected use on the user end is indeed the that, the normal capitalisation, and I've had a few regular users on my talkpage confused about it in the past, especially since everything else in the url string tends to be case-insensitive or may even automatically convert lowercase to camelcase in other instances.
If the other internals all expect lowercase, internal functions should be more than capable of automatically converting the name for their use. This, however, has also not been implemented in core; as is most skin extensions just have an extra line in the definition file to convert it for those.
Also some more on why putting skins in the extensions directory is a bad idea:
From a sysadmin standpoint, the extensions repository/directory is basically a horrible pit of extreme darkness full of many things that that you basically have no idea what they are because their names are completely unhelpful. This is kind of not good, and we do not want to make it worse, because unlike extension names, which sometimes are helpful, skin names basically NEVER give the slightest indication what they are. Skin names are generally completely random things that sounded good, or seemed like a good idea at the time, or were made up as drunken placeholders that nobody got around to replacing. When they even resemble the appearance of the skin itself, it is often a complete coincidence (with a some exceptions - for instance I named a skin 'greystuff' once and indeed it is basically a bunch of grey stuff, but that was only because I did remember replace the original drunken placeholder).
Whereas if we put them somewhere else, such as in 'skins', a place where people would probably expect to find skins, it is immediately clear what they are, both in the filesystem and in the settings files. This is very nice, and leads to fewer incidents of fellow sysadmins killing themselves with shovels.
-I