Last modified: 2012-07-04 16:01:17 UTC
Suppose you have a third party skin and you want to update it to use Resource Loader to get all the benefits of combined, minified style sheets and javascript without the horrors of having to manage that stuff by hand. The first obvious approach is to do what this guide advises for extensions: https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader Only, do it in a skins context, so add something to $wgResourceModules like 'skins.myskin' and call addModules in SkinTemplate::initPage. Except that doesn't work. $wgResourceModules needs to be declared global to be usefully populated, but even if you do that, such that your declarations are visible when you examine them next to the addModule calls, none of them get actualised by the system, regardless of whether you use skins.myskin or ext.myskin. So plan B is to plug this stuff into Resources.php. This sucks because it turns a data file into a site specific configuration file, but it does work. Sorta. The 'dependencies' key doesn't seem to do anything in the skins context for some inadequately documented reason. Plan C is to move all the resources into an extension, along with images and such. This works well, reducing the actual skin to just one php file. In principle, it ought to be possible but I've got no clue how you might push something into the skins subsystem form an extension, and I've had enough debugging PHP for the time being. So this is kind of a big omnibus bug because it's not really clear what behaviour is intentional or defective, beyond the perpetual need for better docs. Really, a design decision as to how third party skins should be handled is in order.
Registration of modules indeed has to happen before the "Setup" point in time. Either through wgResourceModules or the ResourceLoaderRegisterModules hook. Since skin files are loaded on-demand some time after that, whatever is in the global scope in those files is too late (you can't register hooks, enqueue functions, register modules or whatever). On the other hand this is somewhat the expected (and intended) behavior as Skin files are class files, and class files must only define a class, not execute anything. This seems more like a bug for the Skin system to allow an extension to create a skin, as much as bug for ResourceLoader - which is working as it should. Although I've never tried to create or use an extension that provides a skin, there appears to be a repository in our gerrit system that claims to do that: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/skins.git;a=tree I'd say check that out and report back how it turned out :)
Sounds reasonable. I'll look into using the pattern under that git repos. Looks pleasantly straight forward at a glance. If it works, it looks like the bug really turns into “update the docs”.
I'd say that this is definitely a duplicate of bug #1; docs suck, but it's totally possible to use the ResouceLoader system with custom (non-core) skins; take a look at how the [[mw:Nimbus skin]] does it. Basically, instead of one file for the skin, you need three files -- just like when developing an extension. A setup file, an i18n file and the main body file. In the setup file you register the module(s) (see https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/skins.git;a=blob;f=Nimbus/Nimbus.php;h=50c77cd228bb15975108bf741f3f78276a401ec8;hb=HEAD for an example) and do whatever magic is necessary, and then in the body file you use the newly-registered modules: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/skins.git;a=blob;f=Nimbus/Nimbus.skin.php;h=e56031352f65267bd08056e8afa213d7e8ab87a2;hb=HEAD Et voilà ! It works just as you'd expect. ;)
I covered creating skins with RL and i18n support in my tutorial already: http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/ Please stick to the "skinname/skinname.php" pattern. One of the advantages of being in skins/ over extensions/ is in the future we can start to try to automatically handle conventions and start stripping out boilerplate used by skins. And if we do that the "skinname/skinname.php" pattern is inevitably the pattern I will be coding into core.
