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):
1. "New user", "out of habit"? Umm...
2. Nothing. And any decently written skin should not care.
3. 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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
