On Mon, 20 May 2013 08:56:00 -0700, Jason Lewis jason.lewis1991@gmail.com wrote:
Hello,
Let me start off by introducing myself. My name is Jason Lewis and I'm a developer and (some kind of) designer from Australia. I play a role in the community side of things for a PHP framework called Laravel.
...
The purpose of this thread is to give you an overview of how I went about skinning Media Wiki from the point of view of someone who has never attempted it before. I've used Media Wiki in the past but never done anything besides changing the default logo.* *During the process of skinning I used the following tutorial as a reference for some of the inner-workings of Media Wiki: http://www.mediawiki.org/wiki/Manual:Skinning/Tutorial
...
This wasn't as hard as I was imagining it to be. There aren't a lot of quality resources out there that go through skinning Media Wiki. Most just say copy "MonoBook" and change it to fit your needs. I don't like that. That, to me, feels very hacky. It was good to see the tutorial linked above actually go through the setup procedure and the required files. What's even better about this tutorial is that everything seemed separated. There were a few tutorials that I briefly skimmed over that seemed to do everything in the actual "skin" file.
Nice to know that tutorial I wrote was useful.
Next up I need to get the logged in user. I can't remember where but I managed to stumble upon the $wgUser global variable (shudders). Using this variable I could check if the user was logged in, if so output the users menu, or if not show the login or register links.
Directly using the internal classes rather than template keys is a hack from the skinning perspective. So I didn't include any documentation on doing stuff like that. Though maybe we should.
You do not want to use $wgUser to get the user. That should actually be $this->getSkin()->getUser() that'll get the User object from the relevant request context.
But the template actually has some keys in it directly related to the user: username, userpage, userpageurl, loggedin
Besides that you can also access the generated links like the personal urls userpage directly instead of looping over and outputting them all.
That pretty much covers my experience and case study. The source of the skin is available on GitHub for those interested: https://github.com/jasonlewis/laravel-io-wiki-skin
I guess I forgot about things like custom scripts when I wrote the tutorial. Rather than putting the scripts inline the typical practice is to create a second ResourceLoader module (like the skins.laravel-io-wiki-skin one) as something like 'skins.laravel-io-wiki-skin.js' and instead of defining a 'styles' array define a list of 'scripts' then use $out->addModules( 'skins.laravel-io-wiki-skin.js' ); inside the initPage method in your skin.
This also has the advantage of your JS being minified, combined, cached, and delivered with any dependencies you need.
Some other random tips: * bootstrap.php shouldn't really be the name you use, our practice for extensions and skins is for that file to have the same name as the folder it's in, so `laravel-io-wiki-skin/laravel-io-wiki-skin.php`. In the future when we start auto detecting things for you, providing helpers to make loading skins easier, etc... this is very likely the only pattern we'll support. * The url in $wgExtensionCredits should really just be a url. It's not a link, it's used as a url when turning the 'name' of the extension/skin into a link on Special:Version. So your Special:Version looks a little broken now http://wiki.laravel.io/Special:Version
Thanks for reading. I'd be happy to answer any further questions.
Jason