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