On Wed, May 21, 2014 at 12:25 AM, Bartosz Dziewoński matma.rex@gmail.comwrote:
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 [0] (https://www.mediawiki.org/ wiki/Separating_skins_from_core_MediaWiki).
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 today.
- $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 [2]), 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 [3] or Nimbus [4].
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 core skins).
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, -- Jack Phoenix MediaWiki developer