tl;dr Let's adopt a better structure for skins. A more detailed proposal is at the
As you might know, I am doing a Google Summer of Code project aiming to disentangle the
mess of MediaWiki's skinning system a little bit, make creating custom skins a bit
less painful and improve the separation between MediaWiki and its core skins 
I want this thread to result in code changes :)
So, MediaWiki supports skins, and apart from the four core ones there's a couple dozen
of skins available for installation . And looking at them, it seems as if every single
one used a different directory structure, and this a different installation method.
I think this is bad, and that we should standardize on something – preferably one of the
widely used methods – and use it for the core skins as well to provide a good example.
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for assets, using an
autodiscovery mechanism to automagically make the skin available after the files are
copied in the right place. This is used by all of the core skins (Vector has some special
cases, but let's ignore that for now), as well as many external skins (e.g. Cavendish
), at a glance mostly older ones.
* $IP/skins/SkinName/ for both assets and PHP files ($IP/skins/skinname/SkinName.php
etc.), using require_once in LocalSettings like extensions to load the skin, manually
adding an entry to $wgValidSkinNames in the main PHP file. This seems to be the preferred
method among "modern" skins, for example Erudite  or Nimbus .
* $IP/extensions/SkinName/ for everything, the rest as above. This makes the skin work
exactly like an extension. The only example I could find on mediawiki.org
is the Nostalgia
The first one sounds like a no-go for me (in spite of being currently used for core skins,
* The directory structure makes it annoying to both manage and write such skins (you need
to copy/delete the PHP file and the directory separately, many text editors provide
additional features for files contained in a single directory, and just look at our
.gitignore file for skins oh god why ).
* The usage of autodiscovery, while making installation and testing a bit simpler, makes
it impossible or unpleasant to temporarily disable a skin or to provide configuration
settings for it (the last point doesn't affect core skins).
This leaves us with the two latter options: packaging skins similarly to extensions and
sticking them in /skins, or packaging them like extensions and treating them like
extensions. These two options are pretty similar and discussing them will be a bit
bikesheddy, but let's do it anyway.
(Note also that even if we wanted to, we can't stop anyone from using either of these
if they feel like it, as MediaWiki supports loading everything from anywhere if you really
want. We can, however, deprecate skin autodiscovery.)
Personally I'm leading towards the /skins/SkinName option. The pros are:
* It seems to be more widely used, which means that it "felt right" to a lot of
people, and that shouldn't be underestimated.
* It's less revolutionary, and rather a simple improvement over the current system.
* It's more intuitive when compared to how other applications / projects works.
(Corollary: just because MediaWiki skins can do everything that extensions can do, we
shouldn't encourage that.)
* Since it's still similar to how extensions work, adapting the current system (WMF
deployments, tarball packaging, installation via web installer) should be
* Switching current skins to this system within the mediawiki/core repo will be trivial.
The pros of using /extensions/SkinName are:
* We already have a battle-tested system for doing things with extensions (WMF
deployments, tarball packaging, installation via web installer).
* All non-core code in one place.
I would like to settle this within a week or two. Help! :)
I will document the result and, if feasible, convert core skins to be closer to the
recommended format afterwards.
tl;dr Let's start putting all skins files in a single directory, and let's use a
grown-up structure with one class per file + separate init code for them. Okay?
(this category tree is a mess, huh)