On 8/3/06, Daniel Kinzler daniel@brightbyte.de wrote:
Brion Vibber wrote Daniel Kinzler wrote:
Basically, it fetches the files, places them in the extension dir, and optionally patches LocalSettings.php (if the user chooses that option and the extension provides an install.settings patch file). The CategoryTree extension has such a file, if you want to try the patching feature.
I really, really don't like that. An improved extension system should
simply
have autodiscovery of dropped-in directories and a simpler way to enable
things.
I agree in principle, but don't see a way to do this without changing all existing extensions and/or causing some inconvenience when upgrading an existing install to the new system. Here some points that should be considered:
- we'd need a way to know which file in the extension's dir should be
included on every page request. This could be done by a naming convention, as with skins - but that would mean changing many extensions.
- there would have to be a separate directory for "auto-load"
extensions, or a file listing the extensions to load. The ability to add something there would be just as dangerous as patching LocalSettings.
- Extensions may use configuration variables. Would they go into
LocalSettings, or into separate files? The former would require patching again (or worse, manually inserting them), the latter seems hard to maintain.
- Some extensions may need to "patch" the database on install. That
would be hard to do with a "drop in" scheme. While this issue isn't addressed by my installer either, it could easily be added there.
An installer should not be necessary, IMHO, as it would be useless for
the
primary target audience of simplified extension installation -- people
with
limited hosting accounts.
Right now, it's pretty hard for people to even *get* an extension, since they are only available from SVN (correct me if I'm wrong there). Even if we had bundles somewhere, I think it's much easer to say "php installExtension.php Foo" than to manually download, extract, and hook up an extension.
Internally, the installer provides a set of classes for dealing with repositories and resources, and for hooking up the extension. This could easily be used by a web based installation process (maybe as part of the original installation) - which would be what people without shell access would probably want. This would of course require a lot of precautions to avoid opening a huge attack vector. This is the case for any web based installation process, no matter if it patches LocalSettings or not.
So:
- if we don't want an installer, how can the installation of more
complex extension (e.g. requiring db patches) be made simple for the user?
- how would we migrate existing installations and extensions to a "drop
in" scheme?
- if there's going to be a web based installer, how can it be made secure?
My current implementation is meant as a proof of concept, especially of a system to list available extensions and fetch them from a repository. I hope this can be reused regardless of how extensions are hooked up in the future. As it is, it makes life easier for people with shell access, and work with the extensions we have now.
-- Daniel
Look at how Drupal manages modules. You simply drop modules into the modules directory, go to the admin interface to activate, and you are done. The latest version of Drupal even supports modules automatically creating database tables. One of the many benefits to having an abstract extension class.
abstract class MediaWikiExtension { public function installTables(&$dbConnection) { } public function installHooks(&$wgHooks) { } public function providesParserHook() { return false; } ... }
I also made an extension auto-loader as part of Farmer ( http://www.mediawiki.org/wiki/User:IndyGreg/Farmer). It is more-or-less just a hack. However, that is the best we can do until the extensions system is more formalized.
Greg