Am Dienstag, 20. Mai 2014, 18:24:03 schrieb Sumana Harihareswara:
> 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

Hi Sumana, thanks for highlighting me :) I was not on that list, and as such 
my reply won't be threaded, but see below... (oh, and my main mail address 
changed)

> 
> 
> 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 
#1, and tbh, it is quite messy, especially when you want to maintain core mw 
files/folders and have your own skin separate. In the end we used a merged 
repo for mediawiki and the skin, which had other benefits, as we also did 
mediawiki hacks. 
So i am also all for solution #3

> 
> ----
> 
> 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.)

Option #2 sounds rather messy to me, for the above reasons. All files below 
/skins/ makes it harder (again) to have separate repos (not even talking about 
the visual mess :P).
I guess a lot of people have a custom skin as their only modification to 
mediawiki's functionality, and not everyone of them is a git hero, i guess, so 
it would be a very friendly attempt to go for #3 and having a separate 
directory for each skin.
Besides (as already mentioned) every other system does it like that as well, 
and it is well known.

> 
> ----
> 
> 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.

So from my POV, i am all for #3. Go Go! :)

Cheerio,
-- 
Ingo Malchow

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to