I've always found it silly that skins are installed in a different way to extensions. It seems silly to teach a user 2 ways. To be honest I still haven't got the hang of skin installation. I usually crudely plop a folder in the skins directory which I'm pretty sure is wrong.
Thus, I would personally make skins installable in the same way.
If there is a need to manage that process better, I would steer someone in the direction of writing a SkinInstaller extension. Such an extension could protect the end user from the installation process and could also provide lots of MediaWiki coolness such as reviewing skins, updating skins and publishing skins.
This would be my vision to steer towards any how...
On Wed, May 21, 2014 at 8:48 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On 2014-05-20, 10:28 PM, Isarra Yos wrote:
On 20/05/14 23:05, Daniel Friesen wrote:
* The skinname you require is the same one assigned to $wgValidSkins and set on $wgDefaultSkin and set on $skinname, and $stylepath. * For all skins using the old autoload pattern the assets directory remains them same, so nothing has to be re-cached.But that sounds more like an oversight with the autoloader implementation and class setup than an actual reason why it would be good practice to use lowercase. Was there a particular design reason to set those up to be that way?
I'm not sure which item, you think you're replying to but you might be misunderstanding what I'm saying.
The key used for $wgValidSkins/$wgDefaultSkin/$skinname has always been lowercase, and I haven't seen anyone suggesting that we start using &useskin=MonoBook, which would be a bad idea since this key is used in i18n message keys and the skin- css class – places you don't want to use upper case letters. Plus of course using upper case letters there is just asking for a pile of brand new bugs as someone accidentally uses the wrong case and hard to debug errors start popping up.
And for the bit on re-caching that is simple. Assets for core skins like Vector and old skins that are implemented using the autoloader are currently at: {mediawiki}/skins/vector/* If you change the directory structure so we load $IP/skins/Vector/Vector.php (instead of $IP/skin/vector/vector.php) then the path to assets becomes: {mediawiki}/skins/Vector/*
Even though not a single one of the assets have changed the URL has, so, re-cache. ResourceLoader moves most CSS, JS, and some images to load.php but there are still resources that are referred to with an actual URL, like Vector's .htc file, all css images in IE without data: URI support, css images that aren't marked with @embed (because they're too big, use multi-backgrounds, etc...), anything in an <img> using $skin->getSkinStylePath(...), and any stylesheet still loaded with addStyle (IE stylesheets, etc...).
Two of those also apply to extensions in general - FooBar and Foo Bar. Has this sort of inconsistency between name presentations ever posed a problem there? And with skins in particular, why would the internal handling of the skin name be coupled to the filename at all? And why the case-sensitivity, especially when not all platforms that mw supports even use case-sensitive filesystems? Is this just a holdover from the autoloader implementation?
Two is fine, the problem is having three, or rather in essence inventing a third just for skins.
Extensions have two names visible outside of the internal API of the extension:
- FooBar is a canonical key, it's used in the dirname (plus the entry file name) and "usually" (there is some inconsistency) the 'name' key to extension credits (.
- Foo Bar is the human name, and well, sometimes it doesn't even exist even when an extension name has multiple words.
There is some inconsistency in what we use in extension credits, we have a 'name' key and sometimes a human name gets filled in there ('PDF Handler', 'Central Auth', 'Abuse Filter', ...) and in others the canonical key gets used (ParserFunctions, SyntaxHighlight, AntiBot, TorBlock, MobileFrontend, ...), the most common behavior seems to be to just use the canonical key, giving most extensions only one name. If we were serious about human names for extensions we would make it possible to i18n them.
Skins are different, they have two names visible outside of the internal API of the skin:
- foobar is a canonical key it's used on the key that registers the skin ($wgValidSkins['foobar'] = ...;), in &useskin=foobar, $wgDefaultSkin = 'foobar', the .skin-foobar css class, the skin's MediaWiki:Foobar.css (it's ucfirst-ed but it's still foobar not FooBar.css) and User:X/foobar.css, other i18n messages like skinname-foobar that defines the skin's other name and messages like foobar-action-addsection that allow the text used in tabs like "Add section" to be controlled on a per-skin basis, and currently used by every core skins and most 3rd party skins for the assets directory in $IP/skins/.
- Foo Bar is a human name, this name is visible to all users on the preference page and – unlike extensions' human name – this one has full i18n support and is defined by practically every skin. This name is defined by the skinname-foobar i18n message for the foobar skin.
So:
- Extensions often end up with one name not two.
- FooBar has never been exposed outside of the internal APIs for a skin (SkinFooBar class names aren't visible anywhere and if $IP/skins/FooBar.php is used it's autoloaded and not visible to anyone).
- If you did expose FooBar somewhere visible one skin now has three different names for it.
- And to top that off by using FooBar as the dirname a skin now basically has two different canonical names for it.
Let me detail the what I mean by multiple canonical names.
Pretend in the future we implemented a loader for extensions and skins into core, so instead of a raw require_once in your LocalSettings.php you'd drop a call to load an extension by name (maybe in this future we've moved some stuff into a .json file or something).
Something like: MWExtension::load('FooBar'); # Install $IP/extensions/FooBar
This works fine for extensions, you've got one canonical key, nothing else to deal with.
Skins using lowercase dirnames are fine too: MWSkin::load('foobar'); # Install $IP/skins/foobar/ $wgDefaultSkin = 'foobar';
The canonical keys are the same for both loading/installing skins and setting it as default.
With the introduction of FooBar "extension style" skin names that's a little different: MWSkin::load('FooBar'); # Install $IP/skins/FooBar/ $wgDefaultSkin = 'foobar';
This time two different supposedly canonical keys identifying the same skin are used for different areas of config, you'll probably end up looking them up, and anyone who tries mistakenly using `$wgDefaultSkin = 'FooBar';` is a poor soul.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l