Manual talk:Skinning Part 1/Archive 1

Awesome tutorial. Thank you!

why an extension

Hi, I'm just seeking some clarity about why we should treat it like an extension now, instead of how it used to be and simply auto included by placing the php file in the skin directory. (I'm also wondering who came up with these conventions, and why they aren't documented anywhere) Dkpat (talk) 17:39, 14 August 2013 (UTC)

I started these conventions while doing other things to improve the skins system. There are several reasons I want to ditch the old auto-includes:

• Auto included skins have no way to add resource loader modules.
• Auto included skins have no way to add i18n messages.
• Auto included skins cannot declare anything for Special:Version to give their authors credit like in extensions.
• Auto included skins have to have their PHP file outside of their skin folder resulting in a directory structure that cannot easily be packaged up and distributed in a way that is easy for users to install.
• The auto-inclusion code has in the past lead to some bugs like the class name SkinMonoBook (two upper case letters) working for core but breaking when used in a skin in an extension and I'd like to eventually put core skins and 3rd party skins on the same level.

Daniel Friesen (Dantman) (talk) 20:05, 14 August 2013 (UTC)

Thank you for the response :) I'm certainly not opposed to making the skins this way, I just wish that the various pages here documenting skins had been updated to reflect this. Dkpat (talk) 20:24, 14 August 2013 (UTC)

Hi!

There are news on this topic: Simply placing the skin file in the folder skins/ and then having it available automatically has been deprecated with MediaWiki 1.23. See Manual:Skin_autodiscovery for how to adapt skins, that still use this old mechanism. It's actually going to the direction that skins will be even more structured the way extensions already are. --88.130.93.156 16:42, 23 June 2014 (UTC)

Default MySkin conflict

Hi, thanks for the tut. I have some issues about the default, auto-generated skin called "MySkin". In other words, I guess there's a conflict between MySkin provided by MW and the "MySkin" created by me. Thanks! Henrique B. R. (talk) 22:36, 15 August 2013 (UTC)

Solved: A (simple) solution is just rename the skin (duh!), taking care about replacing all references from myskin, MySkin and My Skin to a new name. By the way, I suggest to use another name in the tutorial, rather than MySkin. Henrique B. R. (talk) 22:55, 15 August 2013 (UTC)

Internal Error in css

Hi,

I've copied vector template which I want to work on I named in temp. I almost got it working but styles are not being loaded. When I look at the stylesheet I can see:

   Internal Error

if I change URL of the stylesheet from skins.temp to skins.vector it works fine. Everything was copied and replaced as per instructions and

   $wgResourceModules["skins.temp"] = array("styles"=>array("temp/screen.css",array("media"=>"screen"))); 

was also applied in LocalSettings.php

An ideas why the css doesn't want to load? — Preceding unsigned comment added by Edga (talk • contribs) 13:56, 16 October 2013

Set $wgShowExceptionDetails = true; in your LocalSettings.php and MW should give you a full stack trace that should help explain what went wrong. You can also enable debug comments/toolbar which might help too. Daniel Friesen (Dantman) (talk) 14:38, 16 October 2013 (UTC)

2014 update

I've reverted the changes to the info about skin names, a whole bunch of the information was incorrect.

This was the "new" info:

When building a skin you'll be working with your skin name in two forms (and a half):

• The localized skin name is displayed to wiki users in their preferences, where they can choose the skin to use. It may contain anything whatsoever, and may be translated into other languages.
• The skin name, usually CamelCased, is used as the name of the subdirectory under skins/ where your skin will be placed, as the name of repository if you put it in version control, as the name of skin description page here on mediawiki.org if you decide to create one, and displayed on Special:Version. It may only contain Latin letters and numbers (A-Z, a-z, 0-9).
  • The lowercase skin name, identical to the skin name but lowercased, exists mainly due to backwards-compatibility. It is used for names of site-wide and user CSS/JS customization pages, for the name of the localization message used to define the localized skin name, and internally as a value of the 'skin' user preference.

In our example skin, these are, respectively, "My Skin", "MySkin" and "myskin". (For new skins, it's possible to have the latter two be exactly identical. Other deviations from these conventions are also possible, but not recommended.)

The problems:

• CamelCased 'skin name' which "may only contain Latin letters and numbers (A-Z, a-z, 0-9)"
  • "is used as the name of the subdirectory under skins/ where your skin will be placed, as the name of repository if you put it in version control"
    • Strictly speaking we already have a bunch of skins that are using – and will continue to – a lowercase directory and repository name, it's fine for future skins to use as well, and I still don't believe we have a true enough consensus about this to declare it as a fact in the skinning manual (the manual also wasn't even fully updated on this, it still used a lowercase directory throughout the rest of the file making it inconsistent).
      • "Strictly speaking", I wrote that "it's possible to have the latter two be exactly identical" below. The model I described is used by both non-core skins deployed on WMF wikis (Modern and Cologne Blue, they were recently split from core; see bug 65868 for details), and frankly it seemed like you were the only person opposed to it. Either way, I'll remove this bit, mention both ways that are possible and valid, and hopefully we can work this out later. Matma Rex (talk) 21:36, 1 June 2014 (UTC)
  • "as the name of skin description page here on mediawiki.org if you decide to create one"
    • The Skin: page names here aren't required to be the camel cased skin names. Quite frankly as these are page titles on a primarily English wiki and users usually see the i18ned name, the English version of the i18ned name makes much more sense for the title of the English name. Assuming we have the facilities here for it (I would hope so) the translated pages would have a display title of the translated name.
      • This sounds reasonable. Fixed. Matma Rex (talk) 21:36, 1 June 2014 (UTC)
  • "and displayed on Special:Version"
    • The 'name' property of extension credits has no such restriction. Plenty of extensions include a space in here and it often ends up becoming equivalent to the English version of what would be an i18ned extension name. In fact I think we should do away with one of $wgExtensionCredits' flaws by introducing an 'namemsg' key (to match descriptionmsg) which skins can simply set to 'skinname-{skinname}' to copy the i18ned name we already have for them onto Special:Version. Then eventually Extensions can use it too.
      • (For posterity, the patch for this is https://gerrit.wikimedia.org/r/#/c/136699/.) Good point, I'll remove this for now and we can update the guide when the patch is merged :) Matma Rex (talk) 21:36, 1 June 2014 (UTC)
  • Actually, the line on a CamelCased 'skin name' completely missed and forgot to even mention the one real undebated use of it, as part of class names. There's not one mention in this entire new blurb.
    • Whoopsie, I totally forgot to mention that, I guess it was just too obvious. Matma Rex (talk) 21:36, 1 June 2014 (UTC)
• lowercase skin name
  • "exists mainly due to backwards-compatibility"
    • Considering the i18n system makes a point of not using any upper case letters in message keys and there are all sorts of issues with trying to match non-lowercase canonical keys I wouldn't call this backwards compatibility. The lower cased key will never go away.
      • I'm going to call [citation needed] on this. I see no reason why using camel-case here wouldn't work perfectly well, it seems to be avoided in existing skins only because 'useskin' parameter is case-sensitive and older skins used lowercase names. I kept this part in for now. Matma Rex (talk) 21:36, 1 June 2014 (UTC)

Daniel Friesen (Dantman) (talk) 05:52, 1 June 2014 (UTC)

Replied to each point inline, and updated the page (diff between reverted and current version). I would appreciate if you just edited the page instead of reverting changes entirely if there's anything else I've gotten wrong. Matma Rex (talk) 21:36, 1 June 2014 (UTC)

Localization still must be updated (done)

The article still shows how to use PHP files like MySkin.i18n.php as source for localization, however, using these files since MediaWiki 1.23 is deprecated.

The article should instead be changed to use JSON files for localization. Basically the result of what generateJsonI18n.php generates must be described in the article. --88.130.93.156 18:58, 23 June 2014 (UTC)

Done. Matma Rex (talk) 00:17, 4 July 2014 (UTC)

Nice, thank you! --88.130.109.101 09:45, 23 July 2014 (UTC)

subskins

Shouldn't this manual also cover how to make subskins, like http://blog.redwerks.org/2012/02/28/mediawiki-subskin-tutorial/ ? --Egel (talk) 13:05, 24 June 2014 (UTC)

I am not completely sure, what exactly the use-case for subskins would be. Having a look at your article it seems like another method, which somehow creates a skin based on another skin. Describing two different methods in one article will be confusing I fear - maybe it would be better to explain creation of subskins in another article. --88.130.109.101 09:48, 23 July 2014 (UTC)

You might be interested in Extension:Theme. --Jack Phoenix _(Contact) 03:29, 24 June 2015 (UTC)

A skin based on the new Vector

Hello, I’m trying to make a new skin by copying the Vector skin in 1.23.6.

If I make a copy of the vector folder and change every instance of ‘vector’ and ‘Vector’ inside the folder and the PHP file, should the new skin work? Because I tried that and I get a blank white screen when I try to access the site. — Preceding unsigned comment added by 212.34.12.126 (talk • contribs) 19:32, 6 November 2014‎

Yes, obviously it should work. A blank screen signifies a PHP error of some kind. See Manual:How to debug for information how to find the error(s) in question and fix them. --Jack Phoenix _(Contact) 03:29, 24 June 2015 (UTC)

What is in $this->data[]? What's in $this->html() ?

The tutorial doesn't explain what sets up $this->data['newtalk']. What sets that up? What's available in it? Nor does it explain $this->html('newtalk'). I've dumped $this->data and it holds many variations of the page name like 'displaytitle', 'thispage', and 'titletext'; what describes their differences? And there aren't html() rendering for all of them. So how do you know? -- SPage (WMF) (talk) 03:31, 23 June 2015 (UTC)

@SPage (WMF): They are set up in includes/skins/SkinTemplate.php; you're probably also interested in the BaseTemplate class found in the respectively named file in the same directory.

As for "how do you know", well, you just know. Once you've written enough skins, it mostly becomes obvious as to what you need to use and where. Alas, the skinning system is pretty awful; just ask any of the senior devs (like Isarra or Matma Rex) who have had to struggle with it.
Newbie skin developers usually copy the current default skin — nowadays Vector, MonoBook in the past — and modify it to their liking via trial-and-error. This can be a painstaking process and it doesn't exactly help that Vector's pretty messy, despite everything. This is probably one of the many reasons why currently only 49 skins (incl. former core skins) are listed on Category:All skins, whereas WordPress.org lists almost 2k "popular" themes (as they call skins over there — over here themes are a tad bit different). --Jack Phoenix _(Contact) 03:29, 24 June 2015 (UTC)

Splitting into three parts?

Does anybody have any objections to splitting up this page into three? There are currently three big headers, and I feel like each of these could be its own page. I believe I'd rename this page "Manual:Skinning Part 1", and create two additional pages with the content from the other big headers. I'm used to Wikipedia's "be bold" policy, and I would have just made these changes if this were Wikipedia. I wasn't sure what the policy is here, and didn't want to risk making a faux pas. • Supāsaru 14:54, 2 July 2015 (UTC)

Being bold is alright here too :) Although at least when it comes to code, the usual cycle is more like propose-discuss-commit rather than bold-revert-discuss. I don't think anyone would mind. Myself I don't really like the three-part split in general, but I have nothing better in mind. Matma Rex (talk) 10:47, 3 July 2015 (UTC)

Thanks for the answer, @Matma Rex: .

I feel like splitting up the page into three will help with readability, and allow us to do more with the content. I'll start working on it soon, and you'll have a good sense of what I'm trying to accomplish. Cheers!

• Supāsaru 12:40, 3 July 2015 (UTC)

Use wfLoadSkin

These manuals should probably be updated to reflect using wfLoadSkin instead of RequireOnly now per MW 1.25. (It would be wonderful if things would just stop changing) Dkpat (talk) 04:47, 14 July 2015 (UTC)

2017 revamp

Seems this page is too old, verbose and not direct enough toward the tools / pages needed to edit for skinning. I'am going to push a revamp.

Let's go ! Feel free to follow me :D --Yug (talk) 12:34, 17 January 2017 (UTC)