[Mediawiki-l] Skin system new features (1.17): Footer links, Footer icons, just a few helper methods

Thu Sep 1 23:23:50 UTC 2011

MediaWiki 1.17 contains some new features for skin authors, most of my
skin system reform was backed out for later releases so it's only some
small stuff for now:

I'm not going to go over the ResourceLoader here since I didn't author
it. But do make note of it, skins should update themselves and take
advantage of the resource loader. If you ever thought that your skin's
css file was far too big this is now your chance to split it up into as
many cleanly separated stylesheets and have the resource loader combine
them all into a single stylesheet automatically so you can get the
organized code while keeping your skin nice and fast.
Also make note to use @embed rules and @noflip. You don't need a
separate rtl stylesheet anymore (though do test your skin in rtl
environments so you know what rules you need to @noflip). You don't need
to depend on css sprites anymore since images are embedded into
stylesheets with @embed. However do try to avoid using multiple @embed's
for the same image, if you use the same url() in multiple places in your
css try to consolidate them all into a single combined css rule.
Otherwise when you use @embed you'll be unnecessarily bloating your css
since they're now inline and not combined into one by the browser's cache.

Footer links:
Previously the list of links in the footer was hardcoded into individual
skins, there's now a new array managed by the skin template.
Skin authors can now use $this->data['footerlinks'] and it's sub-arrays,
the way to output the links is generally the same values in the
footericons sub-arrays are tpl keys.
Extensions can now tweak the list of footerlinks by registering a
SkinTemplateOutputPageBeforeExec hook, modifying the one of the
footerlinks sub-arrays in it by adding a new key, and setting a new key
of the same name on the $tpl.
One of these days the footericons may be replaced with a better system
that'll actually be customizable by system message config, but for now
for compatibility reasons this is what we've got.

Footer icons:
The previous copyrightico and poweredbyico keys are now depreciated in
favor of a new footericons setup. The icons are accessible by
$this->data['footericons'] which is populated from $wgFooterIcons, with
some extra guarantees like if "src" is set a width and height will
always be set so you don't need to test for them. There is a
Skin::makeFooterIcon method skins can use to simplify the creation of
the actual footer icons/text, actually I recommend that every skin makes
use of this method with the same kind of boilerplate used by
monobook/vector (for icons) or modern (for text).
Users can now use $wgFooterIcons to customize the icons in the footer.
Kill off the copyright icon, powered by, add an icon to wiki you host in
a wiki farm, add icons for someone responsible for managing your wiki,
etc... Extensions that want to customize this can look at how it's done
in SMW. However do so very sparingly, ONLY if you're a really big
extension like SMW that your users won't mind an icon showing up for (or
of course if your extension's only purpose is to customize that, eg: an
extension that creates a ui to let sysops add icons to the footer). If I
see extensions start to abuse this and bloat the footer with vanity
icons I'll personally go into svn and delete the icons from each extension.
Skin and Extensions authors and users can check the $wgFooterIcons
documentation for info.

Skins also have access to Skin::getCommonStylePath and
Skin::getSkinStylePath. These are helper methods you can use if you have
a need to include the url for a skin or common resource within your skin
itself. Mostly if you're doing something like inserting an image using
an actual <img> rather than a background-image.

Skins can override a new addToBodyAttributes method if there are any
attributes or css classes not in the built-in headelement <body> tag
that they want to be there.

By the way if you haven't already, please do start using the headelement
introduced in 1.16.

-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]