On 26 September 2012 10:08, Krinkle <krinklemail(a)gmail.com> wrote: 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

On Sep 26, 2012, at 8:01 PM, Niklas Laxström &lt;niklas.laxstrom(a)gmail.com&gt; wrote: 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 Sep 27, 2012, at 1:36 AM, Max Semenik &lt;maxsem.wiki(a)gmail.com&gt; wrote: That's a known problem, nothing new. And that goes for both extensions and skins alike. -- Krinkle

On Wed, 26 Sep 2012 00:08:14 -0700, Krinkle &lt;krinklemail(a)gmail.com&gt; wrote: 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. 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. 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. 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. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]