I've been chipping away at our skins system lately, there's a lot we can
improve to improve the skins system.
Right now there's a lot of it that doesn't work so nicely for an
ecosystem promoting the creation of a wide variety of skins.
- footerlinks is duplicated across skins and is hardcoded (I fixed this
in trunk, I did footericons too, however these could be improved with
helper methods, we still have unwanted boilerplate)
- our directory structure is odd
-- SkinName.php with skinname/ beside it means skins are not self
enclosed and can't simply be dropped into their own directory
-- having a first class skins directory we store skins in with proper
autoloading, stylepath and localstylepath (1.17) variables, and having
conventions for including skin resources like
skins/{skinname}/path/to/file.ext but saying that any skin we don't
include in core should instead go in extensions, use extensions assets
path, not have localstylepath, and not use the
skins/{skinname}/path/to/file.ext convention and be left without any
autoloading at all, and include extra boilerplate/code that native skins
don't need to, does not promote the creation of new third party skins
--- in fact, besides the 4 skins in extensions/skins/ that were in svn
which don't appear to be really notable skins and haven't been touched
in a half year, all the 3rd party skins out there don't even use the
extensions features, they all just have you place them inside skins/ the
same way the native skins are.
- we have page end boilerplate you have to copy into a skin (we can
probably fix this somewhat similarly to the way headelement was added)
- toolbox is hardcoded into the skin and needs to be copied (this one
definitely should be fixed)
- many of our toolboxes portlets nav links need very verbose loops and
things hardcoded which would be better inside of a common helper method
-- it should also be possible to differentiate between the page/talk and
other navlinks the way vector does, without having to hardcode it or add
a pile of extra php
- building a sidebar should be minimal in the specialcases and php you
have to hardcode (SEARCH, TOOLBOX, etc... special cases shouldn't be
hardcoded into the skin)
- we need a method of building a search form that is flexible to styles,
but minimizes what you have to hardcode and what boilerplate you need,
most skins should be able to call something and just drop a search box
or search bar in with a single method if they don't want to do any
special customization.
- the large block of common boilerplate inside the content area also
isn't that nice for building 3rd party skins
I've been working on improving the system for the past few days. And
I've also come up with a new idea for a skin packaging and installation
convention.
To show it off I ported WordPress' P2 theme into a wiki skin and
committed it to
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/skins/p2wiki/
The result being
http://trunk.new.wiki-tools.com/index.php?useskin=p2wiki
The convention should work with currently stable versions of MediaWiki
as well. And it is compatible with adding new features to newer versions
of MediaWiki to tear away boilerplate necessary to package up a skin for
distribution. As well as with $wgStylePath conventions.
Currently the convention can be done by packaging up a skin like I did
with p2wiki, using extension style techniques to add a new skin. It can
be installed into skins/skinname/ and
`require_once("$IP/skins/skinname/skinname.php");` can be added to
LocalSettings.php.
That convention will work in already released versions of MediaWiki. For
future versions we may want to consider adding autoloading code for this
style of skins, and adding some convention based defaults.
As an ideal, it would be nice if some way down the road it's possible to
build a skin without the use of any php, even if you have to enable an
extension to add the actual template system or whatever.
As for places for putting skins and distributing them, Lcawte proposed
adding a /trunk/skins/ for the new convention.
There was a bit of discussion in irc where some downsides, upsides, and
counter issues were brought up.
- Adding /trunk/skins would require some (possibly small?) changes to
the Translation extension.
- ExtensionDistributor would also need tweaks.
-- However it was brought up that ExtensionDistributor doesn't work with
/trunk/extensions/skins/ anyways, at least not if you're only trying to
get one skin out.
-- I think tweaking ExtensionDistributor to support /trunk/skins would
be quite easy (at the simplest it's probably a case of making small
tweaks to make a SkinDistributor that uses /trunk/skins instead of
/trunk/extensions and whatnot)
It's not part of distribution, but the new installer's ability to point
out extensions and allow you to install them from the installer was
pointed out. However generally each skin doesn't have it's own set of
configuration (vector does, but generally as an ideal having a bunch of
skins that are nothing but a separate theme for the site should not
require special configuration of each one of them) so there isn't really
much use for sharing configuration infrastructure. Additionally, if we
do add an autoloader for the new style of skin there's not really any
point to having the installer point out skins. If they're in a spot the
installer can find them, they'll already be autoloaded anyways.
Oh, and lastly... if anyone knows of any "really" good WordPress or
other CMS themes or templates I might consider porting some as examples.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]