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
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
Daniel Kinzler wrote:
Brion Vibber wrote 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:
I don't understand what you mean by this. Existing extensions if not changed will continue to work the same way. Extensions which add the metadata file for automatic detection will be automatically detected.
- 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.
Well, so what? You'd need to change every extension to support your installer, too! If you have to do it anyway, what's different?
- there would have to be a separate directory for "auto-load"
extensions,
No there wouldn't.
or a file listing the extensions to load.
Naturally. Oddly enough, your installer requires the same.
The ability to add something there would be just as dangerous as patching LocalSettings.
Why is that so? The site operator still would have to enable any extension. How is automatically pulling a list dangerous in this way?
- 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.
What patching? When you *choose to set* configuration values, then you edit. That hasn't changed.
- 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.
Why so? The updater scripts should have a simple hook for this. If it's not already there, add it. (I've recommended that Evan add this for his OpenID extension.)
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).
They're available from whereever they're available from. Some are available in our SVN. Some are available from the web sites of the authors. Some are custom-written and kept locally.
An extension can come from *anywhere*.
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.
I disagree completely. That is literally *IMPOSSIBLE* for those with no command-line access, whereas dropping in a directory by FTP is insanely easy.
Literally zero setup. What's easier? Nothing.
-- brion vibber (brion @ pobox.com)
On 8/3/06, Brion Vibber brion@pobox.com wrote:
I disagree completely. That is literally *IMPOSSIBLE* for those with no command-line access, whereas dropping in a directory by FTP is insanely easy.
Literally zero setup. What's easier? Nothing.
Clicking "Extensions" from inside MediaWiki, being presented with a list, and clicking one to install and enable it. And having no idea how idea it actually works.
(pretty much the firefox extension model)
Steve
Steve Bennett wrote:
On 8/3/06, Brion Vibber brion@pobox.com wrote:
I disagree completely. That is literally *IMPOSSIBLE* for those with no command-line access, whereas dropping in a directory by FTP is insanely easy.
Literally zero setup. What's easier? Nothing.
Clicking "Extensions" from inside MediaWiki, being presented with a list, and clicking one to install and enable it. And having no idea how idea it actually works.
That's not easier, that's exactly what I'm talking about, therefore precisely as easy.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Steve Bennett wrote:
On 8/3/06, Brion Vibber brion@pobox.com wrote:
I disagree completely. That is literally *IMPOSSIBLE* for those with no command-line access, whereas dropping in a directory by FTP is insanely easy.
Literally zero setup. What's easier? Nothing.
Clicking "Extensions" from inside MediaWiki, being presented with a list, and clicking one to install and enable it. And having no idea how idea it actually works.
That's not easier, that's exactly what I'm talking about, therefore precisely as easy.
You said "dropping in a directory by FTP". He said "Clicking [something] from inside MediaWiki". I don't know about other people, but I see a huge difference between those. The latter is easier. The former doesn't even have a UI.
Timwi
On 8/3/06, Timwi timwi@gmx.net wrote:
You said "dropping in a directory by FTP". He said "Clicking [something] from inside MediaWiki". I don't know about other people, but I see a huge difference between those. The latter is easier. The former doesn't even have a UI.
Yeah, uploading onto FTP on Windows is tricky without a specialised client. Oh wait...no, there are "network places" which actually work fairly well, but still, any solution which involves taking action *outside* the client GUI is necessarily "more complicated" than any solution which is wholly contained *within* the client GUI.
Steve
Timwi wrote:
You said "dropping in a directory by FTP". He said "Clicking [something] from inside MediaWiki". I don't know about other people, but I see a huge difference between those. The latter is easier. The former doesn't even have a UI.
The list is there because the extensions are present. They're present because someone uploaded them. You can't of course write files to the disk from the UI because it's locked off, typically, and the idea of fetching code from the web server UI is enough to get you shot for treason.
-- brion vibber (brion @ pobox.com)
On Thu, Aug 03, 2006 at 05:04:18PM -0400, Brion Vibber wrote:
because it's locked off, typically, and the idea of fetching code from the web server UI is enough to get you shot for treason.
You're probably not a big Zope fan, then, right? :-)
Cheers, -- jra
wikitech-l@lists.wikimedia.org