Someone earlier mentioned introducing $wgDisableExtensionManager for people who want or need to disable it. On 09/06/07, Michael B Allen <mba2000(a)ioplex.com> wrote: -- Gary Kirk

Michael B Allen wrote: Trying to make an Extension to add the extensions is a bit like pushing the line. I'd make it a separate app. Either a php script *to run from the shell* or a complete GUI app intended to be run on the user local system. The user would only need to have a local copy of the web files, point the script to that folder to update, and then synchronise this folder with the server directory. It can also check for some common errors, like the BOM on LocalSettings.

Gary Kirk wrote: They should do it on local, then upload. A GUI would be beneficial for them. Their host probably won't allow their script to remotely fetch the checking page, getting errors: "It doesn't work", when it really means: "my host is using safe-mode / disabling url-fopen".

DreamHost disables urlfopen by default. (Of course, they also give shell access: It's a weird world.) Compiling PHP is something that's probably beyond the ken of the people for whom a GUI would be most beneficial. On 6/10/07, Gary Kirk <gary.kirk(a)gmail.com> wrote: -- Emufarmers Sangly Pirate, Cowboy, Hellraiser

Kasimir Gabert wrote: I would agree with this fully - a special page that can manage extensions - add, update and remove. If you follow the mediawiki forum, folks seem to have a lot of problems with using the command-line utilities, some problems with editing a file and little problem with opening a page and clicking a few buttons. No matter how much *nix nerds may love the command line, that's not the way most computer users work. Mike

Kasimir Gabert wrote: I don't see the extension manager being the extension class, it just handles things like extensions registering with the wiki. It makes sense to me that if the manager handles updates and such, it should handle initial registration. The manager is the glue that connects all the extensions to the wiki. In fact, something like $wghooks probably should be part of some other class (without looking through the code base, I'm not sure where exactly) but the manager should at least delegate to that class. But the gory details of what currently happens in an extension's main php file should be centered in the manager. My main point, though, is to encourage folks to think of this thing in OO terms and try to steer away from more global variables and more dependencies in LocalSettings.php. Mike

Dantman wrote: I think that's what Mediawiki class (Wiki.php), in part, should be for. It should create the wiki environment when it runs. (as an aside, the internal documentation in Wiki.php describes it as the "base" class. I think this is an inadvertent misuse of the term - it should be the core of the wiki, but not necessarily a base class for anything else). One of the bits missing from using Wiki.php in a very general way is persistance. A settings file (or a database table(s)) can provide this. If wiki settings were handled with a special page too, then moving settings into a db table(s) would be a good thing. LocalSettings.php could be eliminated entirely. A setting file to save DB access info will always be required, I guess. But I digress... The more manual intervention, the more possibility for things to get mucked up. I think it would be best to get rid of this sort of thing rather than make it the centre of all things. At the start, manual intervention is required, but a future version (MW 2.0?) should eliminate it wherever possible. A class delegates whatever it doesn't directly control. An extension should only know about itself and how to handle its responsibilities in the wiki. That doesn't mean that the extension should know how to install itself. Installation should be in the extension manager and the extension only knows how to ask the manager to install it and supply the data to the manager. This can be taken out of LocalSettings and put into Wiki.php with some clever coding. The most basic info required from the user is information on where the wiki is locally installed - $IP, $wgScriptPath, that sort of thing. Once these things are known, all the other stuff can be generated for a "normal" installation. I agree - the specific example of delegation I mentioned - $wghooks - would be to another class. A quick look at the code shows that Hooks.php is a candidate (though that is a function, not a class - this is easy to change). One thing about converting from a lot of globals to members of a class - if the first step puts the globals into various class files and keeps them public (not as true memebers of the class), the existing code should work without change. As a specific global is removed from all existing code and replaced with accesses to the relevent class, it can be moved from a globally accessible variable in a class's php file to a private data member. Mike

Rob Church wrote: I've never benchmarked MySQL access vs parsing flat files. If that's the case, a settings file can be useful. A non-readable format (to humans, that is) may be faster to parse than a humanly readable one. That depends on one's point of view. A flat file is just another kind of database. Mike

Michael Daly wrote: Wiki.php is only loaded on index.php calls. It's not universal to the MediaWiki framework, and it does nothing to eliminate globals. Extension loading should be done in Setup.php. A list of extensions should be taken from the configuration (be that LocalSettings.php or some other system). Capability lists can then be loaded, merged and cached. See this post and the thread which follows it: http://lists.wikimedia.org/pipermail/wikitech-l/2006-July/024697.html I don't see any need to treat extension selection differently to any other type of configuration -- it all has to be optionally web-based sooner or later. -- Tim Starling