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.