On Wed, May 21, 2014 at 12:25 AM, Bartosz Dziewoński <matma.rex(a)gmail.com>wrote;wrote:
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  (https://www.mediawiki.org/
The skin system is likely rather intimidating for a newer developer; I know
my way around it, and so do you and some other core MediaWiki developers,
but we're not the target audience, since MW's default skin changes *very*
rarely. As such, it'd be beneficial to everyone to make the skin system a
bit friendlier and less of a gigantic mess, which is what it mostly is
* $IP/skins/SkinName.php for the main file plus
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.
I'd say that this method is a remnant from darker ages and it'd be nice if
we could forget it ever existed...
* $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 .
I'm going to assume that the lowercase "skinname" in
$IP/skins/skinname/SkinName.php is just a typo and you meant it to be
CamelCased as "SkinName". If and when so, yes, this is what should be our
recommended way of doing it. 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. Having written and cleaned up many
skins myself, this is the naming convention I prefer and that seems natural
right from the start.
* 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
This is why autodiscovery needs to go.
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.
Bikeshedding? In wikitech-l? You must be new here. ;-)
The pros of using /extensions/SkinName are:
* All non-core code in one place.
While this is true and somewhat handy, there can
be unexpected situations
such as two independent developers (or teams) coming up with two different
things that have...the exact same name -- this is true for "Nimbus"; there
is an extension and a skin with that name; the skin likely predates the
extension, but unlike the extension, the skin wasn't always FOSS.
Thanks and regards,