> 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