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.
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.
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)?
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.
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.
-- 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
On 26 September 2012 10:08, Krinkle krinklemail@gmail.com wrote:
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)
In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas
It would be nice if we could convert some additional themes... On Wed, Sep 26, 2012 at 11:01 AM, Niklas Laxström <niklas.laxstrom@gmail.com
wrote:
On 26 September 2012 10:08, Krinkle krinklemail@gmail.com wrote:
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)
In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas
-- Niklas Laxström
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sep 26, 2012, at 8:01 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 26 September 2012 10:08, Krinkle krinklemail@gmail.com wrote:
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)
In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas
No, not at all. They never were and never will.
In svn we have:
[mediawiki] - trunk/ - - phase3/ - - extensions/
Extensions has always been besides never inside core.
Of course in unversioned installations (e.g. tarballs) we put extensions in the extensions subdirectory. And even in versioned installations, one can
* git clone individual extensions in the extensions directory * git clone extensions next to core and place symlinks for invidual extensions in the extensions directory
But if someone simply clones the mediawiki/extensions.git tracking repository, then it is kind of annoying to have to put symlinks in place. I have my local dev environment set up like this:
$wgScriptPath = '/mediawiki/core'; $wgExtensionAssetsPath = '/mediawiki/extensions'; $extDir = dirname( $IP ) . '/extensions';
require_once( "$extDir/Vector/Vector.php" );
Anyway, </offtopic>
-- Krinkle
On 27.09.2012, 3:26 Krinkle wrote:
On Sep 26, 2012, at 8:01 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 26 September 2012 10:08, Krinkle krinklemail@gmail.com wrote:
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)
In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas
No, not at all. They never were and never will.
In svn we have:
[mediawiki]
- trunk/
- phase3/
- extensions/
Extensions has always been besides never inside core.
Of course in unversioned installations (e.g. tarballs) we put extensions in the extensions subdirectory. And even in versioned installations, one can
- git clone individual extensions in the extensions directory
- git clone extensions next to core and place symlinks for invidual
extensions in the extensions directory
But if someone simply clones the mediawiki/extensions.git tracking repository, then it is kind of annoying to have to put symlinks in place. I have my local dev environment set up like this:
$wgScriptPath = '/mediawiki/core'; $wgExtensionAssetsPath = '/mediawiki/extensions'; $extDir = dirname( $IP ) . '/extensions';
require_once( "$extDir/Vector/Vector.php" );
This approach has a problem:
Let's take a look at random extension's (AbuseFilter was in the beginning of directory listing) maintenance script:
require_once ( getenv( 'MW_INSTALL_PATH' ) !== false ? getenv( 'MW_INSTALL_PATH' ) . "/maintenance/commandLine.inc" : dirname( __FILE__ ) . '/../../maintenance/commandLine.inc' );
If MW_INSTALL_PATH is not set (and nobody sets it), this layout will break all the maintenance scripts. And there are more way extensions rely on themselves being present in $IP/extensions
On Sep 27, 2012, at 1:36 AM, Max Semenik maxsem.wiki@gmail.com wrote:
On 27.09.2012, 3:26 Krinkle wrote:
On Sep 26, 2012, at 8:01 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 26 September 2012 10:08, Krinkle krinklemail@gmail.com wrote:
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)
In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas
No, not at all. They never were and never will.
In svn we have:
[mediawiki]
- trunk/
- phase3/
- extensions/
Extensions has always been besides never inside core.
Of course in unversioned installations (e.g. tarballs) we put extensions in the extensions subdirectory. And even in versioned installations, one can
- git clone individual extensions in the extensions directory
- git clone extensions next to core and place symlinks for invidual
extensions in the extensions directory
But if someone simply clones the mediawiki/extensions.git tracking repository, then it is kind of annoying to have to put symlinks in place. I have my local dev environment set up like this:
$wgScriptPath = '/mediawiki/core'; $wgExtensionAssetsPath = '/mediawiki/extensions'; $extDir = dirname( $IP ) . '/extensions';
require_once( "$extDir/Vector/Vector.php" );
This approach has a problem:
Let's take a look at random extension's (AbuseFilter was in the beginning of directory listing) maintenance script:
require_once ( getenv( 'MW_INSTALL_PATH' ) !== false ? getenv( 'MW_INSTALL_PATH' ) . "/maintenance/commandLine.inc" : dirname( __FILE__ ) . '/../../maintenance/commandLine.inc' );
If MW_INSTALL_PATH is not set (and nobody sets it), this layout will break all the maintenance scripts. And there are more way extensions rely on themselves being present in $IP/extensions
That's a known problem, nothing new. And that goes for both extensions and skins alike.
-- Krinkle
On Wed, Sep 26, 2012 at 7:26 PM, Krinkle krinklemail@gmail.com wrote:
On Sep 26, 2012, at 8:01 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 26 September 2012 10:08, Krinkle krinklemail@gmail.com wrote:
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)
In SVN time extensions were a subdir of mediawiki core and I doubt that everyone has suddenly decided to change it. At least I haven't. -Niklas
No, not at all. They never were and never will.
In svn we have:
[mediawiki]
- trunk/
- phase3/
- extensions/
Extensions has always been besides never inside core.
Actually, they were back in the day, but were quickly moved out. Early wmf repo history is fun ;-)
Fun fact for the day: we rewrote history to remove wikihiero and a couple of other things (should've just deleted them all, grr :) that were making the core git repo way larger than it needed to be (wikihiero used to have huge uncompressed images).
Compare [0] and [1]
-Chad
[0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/extensions/?view=log&... [1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=history;f=exten...
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
wikitech-l@lists.wikimedia.org