Thank you for all the comments! I've had a few busy days, sorry for only
replying now. I'm going to try summarizing everything.
I have replied to a few tangenial messages separately. Many things have been
said here (and in several disconnected threads), so I might have missed
something – please remind us if you think I did :)
Table of contents:
* Skin autodiscovery
* Capitalization of skin names and their file/directory names
* On 'skins/' vs 'extensions/'
* Handling WMF deployment
First of all, something we all agree on: let's murder skin autodiscovery. I'll
submit patches to emit deprecation warnings if a skin using it is found (to
master and 1.23 LTS release), and another patch that will remove it entirely
(intended for MW 1.24 or MW 1.25).
I will also convert the core skins not to use autodiscovery first. I'll keep
them in 'skins/' for now, it'll be less disruptive in WMF environment and
to change later if we decide to.
As for Daniel's concerns about capitalization differences (which are valid
regardless of which directory we want to place the skins in), forcing
everything to be lowercase is a solution, but one that I don't like very much.
Keeping the status quo is also a solution, but clearly no one at all likes
I'm going to name the three names we have 'skin file name' (same as skin
directory name), 'skin name' (the one used in $wgValidSkins, saved in user
preferences etc., used for site and user JS and CSS pages) and 'proper skin
name' (localised one displayed on Special:Preferences).
Let me propose two more ways we could do this. (All of the back-compat
concerns below don't apply to new skins, only existing ones that we'd want to
retro-fit to the new way. We could also avoid them by not retro-fitting.)
* Instead of switching file name to lowercase, why not switch skin name to
CamelCase? We'd have a maintenance script to update user preferences in the
database, and a little back-compat layer to allow skins to define
non-canonical names they want to respond to (for site admins who can't run
the maintenance script).
This will, however, break back-compat for JS user scripts (that implement
different behavior per-skin), as well as very poorly written PHP-side code
(which should have no reason to care about skins). This might be acceptable.
* Always compare skin names case-insensitively (which is easy if they're
all-ASCII), in 'useskin', in database user preferences data, everywhere –
and use CamelCased names in "user-visible" areas. We could keep the
canonical skin names the way they are in existing skins for back-compat of
user preferences, but site admins would be able to set $wgDefaultSkin =
'CologneBlue' even if the canonical skin name was 'cologneblue'.
As far as I can tell this will not break back-compat at all, and would let
us move forward leaving very little tech debt behind.
* (Or maybe sidestep the issue, say that you can do this in whichever way and
just keep the current way in existing skins – this would be lowercase
everywhere for most, if not all. This would suck though. :) )
As for where to put the skins, which is what most people care about.
Reading the replies, most people who actually make skins seem to prefer the
'skins/' directory, and have provided some excellent reasoning for this
(better than mine, thanks people!). I've been undecided myself, but right now
I really feel this is the way we should go.
On Tue, 20 May 2014 23:38:14 +0200, Tyler Romeo <tylerromeo(a)gmail.com> wrote:
I do agree with keeping
skins in a separate directory than extensions. It implies a bit of control
on our part concerning how skins need to be structured, whereas if they
were extensions, we cannot place any requirements on the structure.
On Wed, 21 May 2014 00:06:57 +0200, Jack Phoenix <jack(a)countervandalism.net> wrote:
CamelCase is how we name things consisting of
multiple words (i.e. BlueSky, DuskToDawn, HowTo, ...), so it's only
reasonable to use CamelCase here too.
On Wed, 21 May 2014 20:10:40 +0200, Nick White <nick.white(a)durham.ac.uk> wrote:
the skins/ directory is a sensible place for skins,
and the fact
that they in practise aren't fundamentally different to extensions
is largely irrelevant.
On Wed, 21 May 2014 22:38:00 +0200, Stephan Gambke <s7eph4n(a)gmail.com> wrote:
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.
On Thu, 22 May 2014 01:31:57 +0200, Isarra Yos <zhorishna(a)gmail.com> wrote:
From a sysadmin standpoint, the extensions
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. (…)
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. (…)
However, WMF ops/core/platform people seem to prefer 'extensions/', because
we've already worked out the process for extensions so it'd be nice not to
have to do anything else for skins ;).
Given the arguments above and overwhelming support of people who actually do
this stuff, I think that putting skins in 'extensions/' should really be a
last-resort solution if everything else fails.
Are there any fundamental, insurmountable issues with having skins in 'skins/'
in WMF production? Or is it just a matter of performing some boring, but
simple changes to deployment scripts and processes (wrapping things in
`foreach ( ['skins', 'extensions'] as $dir )` etc.)? If it's just
that, I'd be
more than willing to help applying them (I generally have some idea on how
this stuff works and where to find it, but I'd probably need help and of
course code reviews).
So, I'm proposing an experiment: We can evaluate this almost painlessly by
converting the current Nostalgia extension-skin to a skin in my proposed
format, deploying it on nostalgia.wikimedia.org
(after doing whatever changes
are necessary to deployment things first) and seeing what happens. This should
not affect the rest of the cluster, and even catastrophic failures would have
a very tiny "surface area". If it turns out that this is really not going to
work, we can always revert all changes and stick with stuffing skins in
Tim, Brion, Dan: How does this look to you?
Thank you for all the comments again!