Adding and removing things from LocalSettings.php might be troublesome.
Things like svn and cvs, as well as a number of other programs use hidden or dot files. Why not treat every folder with a ".extension" file inside of it as a extension which can be managed with the extension manager. And use a Special:Extensions to disable and enable them.
That Special:Extensions as you said can also do the HTTP or FTP request to download the extension data and by default a extension will be set to enabled if you use the SpecialPage, and will default to disabled if you manually drop the folder into the extensions folder.
This lets us do it without the potential of breaking the LocalSettings.php.
As for LocalSettings.php we could also use a $wgUseExtensionManager to let people disable it if they don't want it, that could also be added to the normal installation(config/index.php) script.
As for what else we could do with dot files we could use .extension to also allow for configuration of various variables through Special:Extensions. ".extension" could also have data such as the title of the extension that would be displayed in Special:Extensions.
Or perhaps we could use a dot folder. extensions/extensionid/.ext/ And inside we'd have various things like .extension which would have the basic data like links to update urls similar to the update url used in Firefox's extension management. We could use a .vars to list special variables for the extension itself and other things about the variable such as what type (bool, int, string, array) and even something like a regex match or enum list of valid values that could be put into the strings or other types of variables. Special:Extensions would use that .vars file to create a form for picking out the values that a user can select to customize the extension. Then a AutoConfig.php could be created by Special:Extensions when it's used to change the configuration. A simple ".enabled" would define what extensions are turned on or off.
As for how to include these extensions without using LocalSettings.php we'd need a includes/SpecialExtensions.php anyways, create something for managing this in includes/Extensions.php. Using that it will search the extensions folder for folders, and for each one it'll consider each one with a .ext folder inside of it an extension and list it on Special:Extensions. And it checks for .enabled and checks it if it's set to enabled or true. If it's not, or it has not been created then it's considered disabled and Special:Extensions can be used to create it.
Checking a list of folders and files in a directory isn't hard, I've used it plenty of times. And since we already need to let php modify the extensions directory to install extensions from the remote sources there's no issue of debating the fact that php will need to write the .enabled and AutoConfig.php files to be used.
~Daniel Friesen of The Gaiapedia and Wikia Graphical Entertainment Project
Kasimir Gabert wrote:
Hm.... so I am picturing something similar to the following:
HTTP or FTP get requests possible to the server. Structure of files on the server: Top level folders: core trusted universe
In each folder, it is split up into each letter of the alphabet. For example, core/a/anextensionfolder core/a/apples etc.
The extension folder would be downloaded to $IP/extensions/.
And the appropriate UPGRADE or INSTALL file in the directory would be shown.
Then it would search for LocalSettings.php.include file (or something similar), and automatically add its content to LocalSettings.php.
If that file does not exist, then it would add require_once("$IP/extensions/extensionfolder/ExtensionName.php"); to LocalSettings.php.
I could even see it proping for the fields in LocalSettings.php as defined by LocalSettings.php.include, so the user could install it without ever touching the terminal or LocalSettings.php.
Let me know what everyone's opinions are.
Kasimir
On 6/8/07, John Lyon jelyon@jelyon.com wrote:
If I understand what you're aiming at here, gallery2 (gallery.menalto.com) does this very thing. I now wish every other open source app I use (MediaWiki, Drupal, WordPress (and WPMU)) offered this capability. But I'm speaking as a code/CSS/PHP rock. Thus, all I can do is cheer, hope and wait.
-- John Lyon | Austin TX
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l