On Tue, May 20, 2014 at 5:25 PM, Bartosz Dziewoński <matma.rex(a)gmail.com>wrote;wrote: I wouldn't consider this change to be truly revolutionary. Would would really be a great restructuring of the skinning system is if I could make a skin by just writing a couple of HTML templates (probably using Gabriel's DOM-based templating language), throw them in a directory and then tell MediaWiki where the directory is. However, staying on the topic that you brought up, I do agree with keeping skins in a separate directory than extensions. It implies a bit of control on our part concerning how skins need to be structured, whereas if they were extensions, we cannot place any requirements on the structure. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

On Tue, May 20, 2014 at 2:25 PM, Bartosz Dziewoński <matma.rex(a)gmail.com>wrote;wrote: Sounds good to me. I agree with Tyler that there's more to wish for, but what you're proposing doesn't at all foreclose further innovation, so I think it's a practical way forward.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... ... I'd go for a mixture of option 2 and 3: $IP/skins/SkinName/SkinName.php I agree that skins and extensions should be installed in the same way as much as possible. But I do not agree that this should go so far as to install them in the same directory. They are fundamentally different things - one concerns (ideally) the functionality of the wiki, the other (ideally) its presentation. "But it can both be pulled in using require_once, let's put it in the same place." does not sound right to me. Using that reasoning you could just put all of MW in one directory (or in one file, even) and be done with it. At the same time I do not agree that the skin absolutely has be called the same in all contexts so admins do not get too confused. That's what installation instructions are for. "Plop it into yaddayadda. Done. Activate it using blahdiblah. Done." And, incidentally, what's wrong with &useskin=MonoBook? Btw: "What stops a new user from plopping the folder into the extensions directory by accident out of habit?" Three answers - 1 serious, 1 half-serious, 1 not helpful at all (you can pick which is which): 1. "New user", "out of habit"? Umm... 2. Nothing. And any decently written skin should not care. 3. Composer. :P And a decent extension/skin manager built on top of that. (But that's a completely different discussion, agreed.) Cheers, Stephan

Thank you for all the comments! I've had a few busy days, sorry for only replying now. I'm going to try summarizing everything. I have replied to a few tangenial messages separately. Many things have been said here (and in several disconnected threads), so I might have missed something – please remind us if you think I did :) Table of contents: * Skin autodiscovery * Capitalization of skin names and their file/directory names * On 'skins/' vs 'extensions/' * Handling WMF deployment ---- First of all, something we all agree on: let's murder skin autodiscovery. I'll submit patches to emit deprecation warnings if a skin using it is found (to master and 1.23 LTS release), and another patch that will remove it entirely (intended for MW 1.24 or MW 1.25). I will also convert the core skins not to use autodiscovery first. I'll keep them in 'skins/' for now, it'll be less disruptive in WMF environment and easy to change later if we decide to. ---- As for Daniel's concerns about capitalization differences (which are valid regardless of which directory we want to place the skins in), forcing everything to be lowercase is a solution, but one that I don't like very much. Keeping the status quo is also a solution, but clearly no one at all likes this one. I'm going to name the three names we have 'skin file name' (same as skin directory name), 'skin name' (the one used in $wgValidSkins, saved in user preferences etc., used for site and user JS and CSS pages) and 'proper skin name' (localised one displayed on Special:Preferences). Let me propose two more ways we could do this. (All of the back-compat concerns below don't apply to new skins, only existing ones that we'd want to retro-fit to the new way. We could also avoid them by not retro-fitting.) * Instead of switching file name to lowercase, why not switch skin name to CamelCase? We'd have a maintenance script to update user preferences in the database, and a little back-compat layer to allow skins to define non-canonical names they want to respond to (for site admins who can't run the maintenance script). This will, however, break back-compat for JS user scripts (that implement different behavior per-skin), as well as very poorly written PHP-side code (which should have no reason to care about skins). This might be acceptable. * Always compare skin names case-insensitively (which is easy if they're all-ASCII), in 'useskin', in database user preferences data, everywhere – and use CamelCased names in "user-visible" areas. We could keep the canonical skin names the way they are in existing skins for back-compat of user preferences, but site admins would be able to set $wgDefaultSkin = 'CologneBlue' even if the canonical skin name was 'cologneblue'. As far as I can tell this will not break back-compat at all, and would let us move forward leaving very little tech debt behind. * (Or maybe sidestep the issue, say that you can do this in whichever way and just keep the current way in existing skins – this would be lowercase everywhere for most, if not all. This would suck though. :) ) ---- As for where to put the skins, which is what most people care about. Reading the replies, most people who actually make skins seem to prefer the 'skins/' directory, and have provided some excellent reasoning for this (better than mine, thanks people!). I've been undecided myself, but right now I really feel this is the way we should go. Excerpts: On Tue, 20 May 2014 23:38:14 +0200, Tyler Romeo <tylerromeo(a)gmail.com> wrote: On Wed, 21 May 2014 00:06:57 +0200, Jack Phoenix <jack(a)countervandalism.net> wrote: On Wed, 21 May 2014 20:10:40 +0200, Nick White <nick.white(a)durham.ac.uk> wrote: On Wed, 21 May 2014 22:38:00 +0200, Stephan Gambke <s7eph4n(a)gmail.com> wrote: On Thu, 22 May 2014 01:31:57 +0200, Isarra Yos <zhorishna(a)gmail.com> wrote: ---- However, WMF ops/core/platform people seem to prefer 'extensions/', because we've already worked out the process for extensions so it'd be nice not to have to do anything else for skins ;). Given the arguments above and overwhelming support of people who actually do this stuff, I think that putting skins in 'extensions/' should really be a last-resort solution if everything else fails. Are there any fundamental, insurmountable issues with having skins in 'skins/' in WMF production? Or is it just a matter of performing some boring, but simple changes to deployment scripts and processes (wrapping things in `foreach ( ['skins', 'extensions'] as $dir )` etc.)? If it's just that, I'd be more than willing to help applying them (I generally have some idea on how this stuff works and where to find it, but I'd probably need help and of course code reviews). So, I'm proposing an experiment: We can evaluate this almost painlessly by converting the current Nostalgia extension-skin to a skin in my proposed format, deploying it on nostalgia.wikimedia.org (after doing whatever changes are necessary to deployment things first) and seeing what happens. This should not affect the rest of the cluster, and even catastrophic failures would have a very tiny "surface area". If it turns out that this is really not going to work, we can always revert all changes and stick with stuffing skins in 'extensions/' instead. Tim, Brion, Dan: How does this look to you? ---- Thank you for all the comments again! -- Matma Rex

I'm not happy at all with how the skin naming topic "ended". Throughout the discussion I explained a variety of reasons why switching to a CamelCased structure and skin name was a bad idea. We discussed them, some like the caching issue got valid comments back on why they're not issues, others remained. But while there was a lot of discussion on the points on why the change was a bad idea, almost no one seems to have bothered detailing points why it's a good idea and comparing them to the negative point. Reading through the discussion, the only person who bothered making a single point on why it was a good idea was Jack Phoenix: For why it's a bad idea, I made various other points, some of the remaining ones summed up: * Unlike extension names, skin names are used in a variety of locations which upper case letters are either considered bad or problematic, such as i18n keys, and keys to $wgValidSkinNames which is both used in those i18n keys and has to be lower cased if we want to make &useskin= case insensitive. So the lower cased keys will never actually go away. * ((Not a point in favour, but when someone pointed out that extensions already have 3 names I pointed out I explained that in most cases they actually only have 1, at most 2)) * Skins only expose 2 names to site admins and users, the canonical lower case key and a fully translatable key. Because the lower case key doesn't actually disappear exposing a CamelCase name now gives skins 3 names to deal with – more than people installing extensions deal with – and makes 2 of those names "canonical" names that are supposed to uniquely identify the skin outside of the internals. ((Btw, I'll also point out that if we ever managed to implement real class-less skins using templates our current only need for CamelCase names – skin class names – would actually disappear)) As the discussion and attempts to implement this move on: Krinkle chimes in that skins should only have a lowercase non-ASCII id and a localized skin name. I help out reviewing the various patchsets trying to implement this, giving normal reviews, and also giving tips on how to properly write a skin that uses an upper case directory (because most people here trying it don't know how to do so without doing things like completely breaking the IE compatibility features in a skin). Bartosz agrees to leave skin directory names as-is while moving stuff out of core, at least while the discussion hasn't finished. Then all of a sudden, while the discussion is still open, it's reported that someone who isn't even a maintainer for skin related stuff +2s something that changes skinname -> SkinName directories for some core skins, and documentation starts getting changed to say that skins use CamelCased directory names. As unhappy as I am with my job revolving around themes and skins, I'm probably currently the one with the most knowledge on how the internals of our skinning system work. And it feels like me and one of the +2 maintainers for this skinning stuff in core are being ignored. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

I finally implemented most of the ideas discussed here into documentation, and I think I settled on something that should be acceptable to everyone. The canonical recommended way to do skins, and one we hopefully all agree on, is now described at <https://www.mediawiki.org/wiki/Manual:Skinning#Skin_structure>. Thanks for the comments! -- Matma Rex