Hey, folks! Since I believe all of you have written, modded, or maintained MediaWiki skins, I thought you would want to see MatmaRex's proposal and give him a "sure, ok" or a "wait nooooo" or something in between. :-) Best, Sumana

tl;dr Let's adopt a better structure for skins. A more detailed proposal is at the bottom. 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). 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 [1]. 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 [2]), 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 [3] or Nimbus [4]. * $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 skin [5].

From my own experience for KDE back then we indeed also used the old method

---- The first one sounds like a no-go for me (in spite of being currently used for core skins, ugh): * 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 [6]). * 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 straightforward. * 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! :) Thoughts? I will document the result and, if feasible, convert core skins to be closer to the recommended format afterwards.