From: Dantman dan_the_man@telus.net
Adding and removing things from LocalSettings.php might be troublesome.
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Part of the manual installation would be to include this one line, as well as remove any existing extension inclusions.
:::: The word "genius" isn't applicable in football. A genius is a guy like Norman Einstein. -- Joe Theisman, NFL football quarterback & sports analyst :::: :::: Jan Steinman, http://www.EcoReality.org ::::
On Sat, 9 Jun 2007 10:11:31 -0700 Jan Steinman Jan@Bytesmiths.com wrote:
From: Dantman dan_the_man@telus.net
Adding and removing things from LocalSettings.php might be troublesome.
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Part of the manual installation would be to include this one line, as well as remove any existing extension inclusions.
I haven't read this whole thread so pardon if I'm restating something that's been discussed already but being someone who has extensions for several LAMP apps that allow you to administer extensions, there's one fundamental problem that always get's in the way:
To be able to upload a package file, the web server needs write access to the extensions directory. This is fatally flawed because anyone who can run a web script can now overwrite your auth plugin with their own hacked version of it.
So whatever you do, just make sure you can always do it the old-fashioned way - putting the file to the extensions dir and adding two lines to LocalSettings.php.
Mike
Someone earlier mentioned introducing $wgDisableExtensionManager for people who want or need to disable it.
On 09/06/07, Michael B Allen mba2000@ioplex.com wrote:
On Sat, 9 Jun 2007 10:11:31 -0700 Jan Steinman Jan@Bytesmiths.com wrote:
From: Dantman dan_the_man@telus.net
Adding and removing things from LocalSettings.php might be troublesome.
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Part of the manual installation would be to include this one line, as well as remove any existing extension inclusions.
I haven't read this whole thread so pardon if I'm restating something that's been discussed already but being someone who has extensions for several LAMP apps that allow you to administer extensions, there's one fundamental problem that always get's in the way:
To be able to upload a package file, the web server needs write access to the extensions directory. This is fatally flawed because anyone who can run a web script can now overwrite your auth plugin with their own hacked version of it.
So whatever you do, just make sure you can always do it the old-fashioned way - putting the file to the extensions dir and adding two lines to LocalSettings.php.
Mike
-- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Ya, that was my idea. Actually it was more of a $wgUseExtensionManager cause the only global variable I remember in the manual which used disable in the name, was a depreciated variable. The actual though of, do I want to use this in the first place, can also be added as a check box in the config/index.php script.
The reason I thought of the use of things like the .ext/.enabled as the determining factors in if the extension manager was so that old extensions which don't use the system can still be used in the old way. And we don't need to tell anyone to mess with what they already have.
Also, another fact of the idea is that using the .ext folder idea even though some people may restrict the ability to write to the extensions folder. The scripts can still read those folders even when we say they can't write. And in the case of things where we want to write the .ext/.enabled file with the content "enabled" but it's restricted so that we can't write we can display a set of instructions telling the administrator how to do it. Such as:
Please save the following content to the /extensions/*extensionid*/.ext/.enabled/ file: enabled
Actually, if I weren't already working on a number of other things. Including my Database Dependency configuration script (Allows for the controlling and creation of new wiki using only the database; Only a baseline of configuration is done in LocalSettings.php and settings/ folder files; The actual base information is grabbed from the shared database).
On a side note, I've had a few improvements for the shared database stuff for some time. I commonly run a simple shared interwiki table hack, and even a shared ipblocks table hack possibly. But really, all I'd do is add an array of tables you could use a shared one instead of the local one. If no one was opposed to it, the setup is something that would probably fit right into the MediaWiki base code. Now that I think of it, I could probably fix it so that the shared database will work with table prefixes.
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
Gary Kirk wrote:
Someone earlier mentioned introducing $wgDisableExtensionManager for people who want or need to disable it.
On 09/06/07, Michael B Allen mba2000@ioplex.com wrote:
On Sat, 9 Jun 2007 10:11:31 -0700 Jan Steinman Jan@Bytesmiths.com wrote:
From: Dantman dan_the_man@telus.net
Adding and removing things from LocalSettings.php might be troublesome.
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Part of the manual installation would be to include this one line, as well as remove any existing extension inclusions.
I haven't read this whole thread so pardon if I'm restating something that's been discussed already but being someone who has extensions for several LAMP apps that allow you to administer extensions, there's one fundamental problem that always get's in the way:
To be able to upload a package file, the web server needs write access to the extensions directory. This is fatally flawed because anyone who can run a web script can now overwrite your auth plugin with their own hacked version of it.
So whatever you do, just make sure you can always do it the old-fashioned way - putting the file to the extensions dir and adding two lines to LocalSettings.php.
Mike
-- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Michael B Allen wrote:
To be able to upload a package file, the web server needs write access to the extensions directory. This is fatally flawed because anyone who can run a web script can now overwrite your auth plugin with their own hacked version of it.
So whatever you do, just make sure you can always do it the old-fashioned way - putting the file to the extensions dir and adding two lines to LocalSettings.php.
Mike
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.
I think one of the main advantages of such an extension manager is for people on shared hosts/non-techies etc who haven't got a clue what 'the shell' is. IMO, this needs to be web-based.
On 10/06/07, Platonides Platonides@gmail.com wrote:
Michael B Allen wrote:
To be able to upload a package file, the web server needs write access to the extensions directory. This is fatally flawed because anyone who can run a web script can now overwrite your auth plugin with their own hacked version of it.
So whatever you do, just make sure you can always do it the old-fashioned way - putting the file to the extensions dir and adding two lines to LocalSettings.php.
Mike
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.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Gary Kirk wrote:
I think one of the main advantages of such an extension manager is for people on shared hosts/non-techies etc who haven't got a clue what 'the shell' is. IMO, this needs to be web-based.
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".
My host disables urlfopen by default but they advised me to just make a php.ini and allow it, which works. Do many hosts not allow that?
On 10/06/07, Platonides Platonides@gmail.com wrote:
Gary Kirk wrote:
I think one of the main advantages of such an extension manager is for people on shared hosts/non-techies etc who haven't got a clue what 'the shell' is. IMO, this needs to be web-based.
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".
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
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@gmail.com wrote:
My host disables urlfopen by default but they advised me to just make a php.ini and allow it, which works. Do many hosts not allow that?
On 10/06/07, Platonides Platonides@gmail.com wrote:
Gary Kirk wrote:
I think one of the main advantages of such an extension manager is for people on shared hosts/non-techies etc who haven't got a clue what 'the shell' is. IMO, this needs to be web-based.
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".
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-- Gary Kirk
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I do not understand the disadvantage of having it be web based.
The whole goal of this is to make MediaWiki easy to configure, so that all updates are taken care of, and the user will never have to run anything outside of MediaWiki itself. Of course this area would be protected so sysops, or some other special user group, would only have access to it.
This would also allow users to have control over a wiki when they do not have close to enough control over the backends to the site, such as SSH or SFTP.
It would not be a bloated extension, or take up to much memory, or anything similar. It would just make configuring the wiki and staying up to date (security vulnerabilities to extensions could be easily seen) much, much easier and user friendly.
Kasimir
On 6/10/07, Emufarmers Sangly emufarmers@gmail.com wrote:
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@gmail.com wrote:
My host disables urlfopen by default but they advised me to just make a php.ini and allow it, which works. Do many hosts not allow that?
On 10/06/07, Platonides Platonides@gmail.com wrote:
Gary Kirk wrote:
I think one of the main advantages of such an extension manager is for people on shared hosts/non-techies etc who haven't got a clue what 'the shell' is. IMO, this needs to be web-based.
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".
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-- Gary Kirk
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-- Emufarmers Sangly Pirate, Cowboy, Hellraiser _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Kasimir Gabert wrote:
The whole goal of this is to make MediaWiki easy to configure, so that all updates are taken care of, and the user will never have to run anything outside of MediaWiki itself. Of course this area would be protected so sysops, or some other special user group, would only have access to it.
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
Jan Steinman wrote:
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Rather than mucking about excessively with LocalSettings.php and global variables, consider using a more object-oriented approach and taking advantage of Wiki.php. It's there to help eliminate globals but isn't used much yet. If ExtensionManager is a proper class, you could have Wiki.php instantiate a singleton and have it handle _all_ extension stuff (including burying things like $wgAutoloadClasses, $wgSpecialPages and $wgHooks handling for extensions) as well.
Mike
The problem that I see with this is that the extension manager then becomes the extension class. I think that they should remain separate so that all of the extensions right now can exist and work with the extension manager, and all future extensions which are based on an extension class would still work with the extension manager. I don't really see the advantage to combining them.
Kasimir
On 6/9/07, Michael Daly michaeldaly@kayakwiki.org wrote:
Jan Steinman wrote:
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Rather than mucking about excessively with LocalSettings.php and global variables, consider using a more object-oriented approach and taking advantage of Wiki.php. It's there to help eliminate globals but isn't used much yet. If ExtensionManager is a proper class, you could have Wiki.php instantiate a singleton and have it handle _all_ extension stuff (including burying things like $wgAutoloadClasses, $wgSpecialPages and $wgHooks handling for extensions) as well.
Mike
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Kasimir Gabert wrote:
I don't really see the advantage to combining them.
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
I don't get how settings would be done using OOP instead of global settings in variables. If that's the case has anyone ever considered some type of Settings class which instead of using PHP variables parses a Settings file?
But the extension manager itself would be a class. And the functions in there would defiantly be what handles updates, installations, and possibly configuration stuff to. I'd call it more of a method of applying the glue which connects the extensions to the wiki. Because even though this can be used to setup and install things, it's still possible for someone to manually edit the .ext/.enable and other configuration stuff to configure it without the manager.
What do you think the ExtensionManager should delegate to the class? I was thinking more of the ExtensionManager class being an alternative method to how we tell people to use require_once( "extensions/Something.php" ); and also use variables to configure that extension. I don't think ExtensionManager should delegate settings to the extension though. Because then it would be hard for someone making an extension to make it compatible with older MediaWiki versions which don't use the ExtensionManager class.
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
Michael Daly wrote:
Kasimir Gabert wrote:
I don't really see the advantage to combining them.
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
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Dantman wrote:
I don't get how settings would be done using OOP instead of global settings in variables. If that's the case has anyone ever considered some type of Settings class which instead of using PHP variables parses a Settings file?
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...
Because even though this can be used to setup and install things, it's still possible for someone to manually edit the .ext/.enable and other configuration stuff to configure it without the manager.
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.
What do you think the ExtensionManager should delegate to the class?
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.
require_once( "extensions/Something.php" )
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 don't think ExtensionManager should delegate settings to the extension though.
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
On 10/06/07, Michael Daly michaeldaly@kayakwiki.org wrote:
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...
This would be slow and inefficient, however; it's not what a database is for.
Rob Church
Rob Church wrote:
This would be slow and inefficient, however;
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.
it's not what a database is for.
That depends on one's point of view. A flat file is just another kind of database.
Mike
On 10/06/07, Michael Daly michaeldaly@kayakwiki.org wrote:
That depends on one's point of view. A flat file is just another kind of database.
You could also argue it depends on the DBMS in use.
Rob Church
Michael Daly wrote:
Jan Steinman wrote:
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Rather than mucking about excessively with LocalSettings.php and global variables, consider using a more object-oriented approach and taking advantage of Wiki.php. It's there to help eliminate globals but isn't used much yet. If ExtensionManager is a proper class, you could have Wiki.php instantiate a singleton and have it handle _all_ extension stuff (including burying things like $wgAutoloadClasses, $wgSpecialPages and $wgHooks handling for extensions) as well.
Mike
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
There is a need to treat extensions slightly different from other configuration options in a wiki---and that is that extensions are from third parties, and update with irregular periods and not normally at the same time that MW updates. For these reasons a new interface would need to be created for them, one which can determine when an update has come out (only acting, of course, when commanded by the user), and then one which would automatically install them and uninstall them, and provide an interface for the configuration options for each extension. It can't be a MediaWiki: item, if that is what you meant.
On 6/10/07, Tim Starling tstarling@wikimedia.org wrote:
Michael Daly wrote:
Jan Steinman wrote:
How about a single line in LocalSettings.php that includes a "don't touch me" file that is maintained only via the ExtensionManager?
Rather than mucking about excessively with LocalSettings.php and global variables, consider using a more object-oriented approach and taking advantage of Wiki.php. It's there to help eliminate globals but isn't used much yet. If ExtensionManager is a proper class, you could have Wiki.php instantiate a singleton and have it handle _all_ extension stuff (including burying things like $wgAutoloadClasses, $wgSpecialPages and $wgHooks handling for extensions) as well.
Mike
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
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org