On Wed, 26 Sep 2012 00:08:14 -0700, Krinkle krinklemail@gmail.com wrote:
A few random points:
We should get some basic structure conventions in place before stuff goes wild.
I like the idea of installing a Skin as an extension, but placing it in the core skins directory feels wrong because it currently does auto-discovery to some degree, and of course it means wgExtensionAssetsPath can't be used as skins as it is outside that directory view.
Well, the outdated auto-discovery just applies to the skins/*.php pattern. It doesn't really affect this pattern at all.
Actually on that topic. I haven't really thought of it much. But I wonder how long we should keep doing that. Any 3rd party skin using that auto-loading is inherently either an outdated not using RL or uses a hack to do so. I wonder if we should remove the auto-loading in a few releases.
The way the skins in mediawiki/extensions/skins.git do it is by simply being installed as a completely valid extension.
Another problem I found in the current setup is that its a bit counter-intuitive how to manage the directory structure for developers. I mean, most of us probably have this:
- mediawiki
- /core (clone mediawiki/core.git)
- /extensions (directory with clones of individual extensions or clone
of mediawiki/extensions.git tracking repo)
- Set $wgExtensionAssetsPath accordingly
- Use require_once( "$IP/../extensions/Foo/Foo.php"); (whether or not
via a tmp variable) instead of require_once( "$IP/extensions/Foo/Foo.php");
But then, where to clone a skins repository (or mediawiki/skins.git tracking repo)?
Interesting problem. I've been using the mediawiki/extensions/ repo. But I've been creating a symlink whenever I actually install something. You generally don't actually need a path to something till you actually use it. And you never really just install every extension (you wouldn't have the individual configuration) so creating a symlink for each one I actually use hasn't been an issue.
Right now one way to work might be to do things the other way around. Instead of symlinking skin folders into skins/, symlink the few core stuff into the /skins tracking repo then point wgStylePath to the tracking repo.
Though yes we might want to find another solution to that issue.
Wherever it is, it needs to be scalable to more complex installations. A directory "skins" next to "extensions" next to "core" is not feasible as the paths would be incorrect (it wouldn't be in wgExtensionAssetsPath, nor in wgStylePath).
I think it'd be a lot easier if skins were installed as extensions, not as a (currently, unhandleable) hybrid.
Except skins aren't extensions. If you try to make a skin as an actual extension some skin features like getSkinStylePath and patterns using stylename don't work. And now instead of skins all being located in the same area they're scattered about. Some skins in an actual skin dir. While other skins are shoved into extensions/ among a huge pile of non-skins that make things impractical to handle.
Tbh, while it's not typically acknowledged we pretty much have this same issue in extensions. We only skirt by and say it's not an issue because few extensions use assets and we don't have built-in extensions that are always included. We have wgExtensionAssetsPath but that's frankly not enough. That's not flexibility that's a restriction saying that all extensions must be in the same directory. Which goes against the reality that someone may want to put some common extensions into a common folder, and some other extensions into a local folder, or maybe a user folder separate from the global extensions. What we may want to consider doing is fixing our assets and skin paths so that different extensions/skins can properly have different paths.
Putting skins inside of skins/ actually has a big advantage I want to take advantage of. Right now it's true that this skin pattern works the same way as an extension. But it's not going to stay that way in the long run. Skins are different than extensions. For extensions you need a lot of flexibility and control. Almost no extension is similar to another so you want complete control over all the configuration. But for skins you use the same patterns over and over. You setup the same things in each skin. The plan is to slowly start auto detecting conventions. Replace require_once with a method to abstractly install skins. Shorten the code needed to register modules. Start auto registering skin classes and i18n when we see certain patterns. Start moving stuff from php into an extension definition file.
Maybe as proper extensions in mediawiki/extensions/SkinName.git (and drop mediawiki/skins/*.git). That would be the easier, though it is also nice to keep extensions and skins separate enough in that anything that adds preferences, special pages etc. is in a separate optional repository.
Or perhaps agree that skins should be installed from mediawiki/skins/*.git repositories, but clones inside mediawiki/extensions/skins/*. That would mean in module definitions and require's, we just add an extra /skins/.
In that case we should get rid of mediawiki/extensions/skins.git to avoid clashes.
mediawiki/extensions/skins/ are outdated skins too. I'd like to update them, put them into mediawiki/skins/ and then kill off mediawiki/extensions/skins/.
Side topic. I've actually been wanting to eliminate the use of web paths in resource loader for awhile. It's perfectly reasonable for this stuff to be in locations that are not webserver accessible. And it's nothing but trouble to have to deal with these paths. We already use load.php for 90% of stuff. I would like to make it so we can use load.php for the rest of it. Built-in mimetype handling, no issues with having to separately set the path of stuff, extensions and skins will just work no matter where they are, and we can get the same caching benefits that load.php provides to other resources.
-- Krinkle
On Sep 26, 2012, at 1:44 AM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Skin pages on MW.org (and repos in Gerrit) are now ready.
MediaWiki.org is now ready for modern skins (ones NOT using old QuickTemplate and skins/Foo.php patterns) to have pages about them just like extensions do.
Relevant links: https://www.mediawiki.org/wiki/Category:All_skins https://www.mediawiki.org/wiki/Template:Skin
Some examples that currently exist: https://www.mediawiki.org/wiki/Skin:Erudite https://www.mediawiki.org/wiki/Skin:Vector
Gerrit can also handle your skin repos. Ask for a mediawiki/skins/{skinname} repo. So your skins can now have proper review and be updated with the various improvements that get made to MediaWiki's skinning system.
When you do introduce a skin here please do follow the file layout patterns I used in my tutorials: http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/ http://blog.redwerks.org/2012/02/28/mediawiki-subskin-tutorial/ I don't want to see any non-core skins using the outdated skins/TheSkin.php pattern in the new skins area.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l