XML isn't for the settings. It was either INI or XML for the file describing information about the extension. It's for the file that holds the information about the extension. Such as the id, name, authors data, version, and a number of other details about the extension. Database isn't viable for grabbing settings from, it would require to many sql queries on every page. Not to mention that I don't think the GlobalFunctions.php was included and ready for DB actions inside of LocalSettings.php I was working on a thing in the past which would allow configuration of MediaWiki using domain checking and database tables, which would also probably cache things with Memcached, but that's more of one of my own projects, cause not everyone has Memcached. I'm not going to make Memcached a near requirement for the Extension Manager extension. Grabbing the data would half to be through something like one of these: PHP's XML Parser: http://ca.php.net/manual/en/ref.xml.php PHP's SimpleXML: http://ca.php.net/manual/en/ref.simplexml.php PHP's DOM functions: http://ca.php.net/manual/en/ref.dom.php Or if MediaWiki had some functions built in, or if there was a PHP library that I could include in with the extension to make it non-dependent on things that may not be there.

This is a bit of an example, It's the one I'm working on in parallel with the schema for the documents: http://temp-dev.wiki-tools.com/extensions/wiki-tools/CWikiIncludes/.mwext/ex... And the current (alpha) schema: http://spec.wiki-tools.com/extensions/1.0/extension.xsd I've been working on the Schema mostly, but I did write out a list of features and specs of the Extension Manager, mostly I theorized on the many possibilities and sorted out the ones that theoretically should be possible: http://central.wiki-tools.com/wiki/Extension:Extension_Manager

~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com

Minute Electron wrote:

On 8/12/07, DanTMan dan_the_man@telus.net wrote:

...

I was starting a new Wiki-Tools SVN repo to replace the in page code on our wiki you'd copy into files for extensions I've made. And I thought of throwing in some of the extra bits my ideas for a MediaWiki Extension manager extension would need. So I am thinking of putting together a Extension Manager. I thought of using INI files for the settings and throwing those through PHP's core ini parsing functions. But INI doesn't fit the multiple values and other things that would be used in the configuration data files for the Extensions read by the Extension manager. So I decided to use XML. But what code should I use to parse the XML files? Is there a standard PHP function set/class for parsing XML that is widely used on most servers (I don't want to require PHP to be reconfigured with another add on just to run the Extension Manager), some PHP library I could include in the manager, or some MediaWiki code for parsing XML? What would be the best thing to use? I'm not sure what PHP functions or anything are widely used and would be supported by most people. I just share JaeSharp's Virtual Hosting, so because we can recompile PHP with anything we need I don't know much about what php restrictions people may have being on a shared WebHost.

-- ~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com

It is fairly simple to parse XML via PCRE, but I wonder what is wrong with using the database for the settings. The tables could be created on the fly so you wouldn't have to worry about schema changes. Also PHP code is a good way of storing settings, you can then use eval() to get back at them later. Regarding restrictions, generally all extensions except the most popular and those needed (e.g. mysql) aren't available. I made a phpinfo() on my shared host http://idkb.eu/phpinfo.php that should give you some help since it lists all extensions. MinuteElectron. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

^_^ mainly, that's what http://central.wiki-tools.com/wiki/Extension:Extension_Manager is for. I suppose I could sum some of it up, but I already listed much of what I've put together on that page, so my responses besides that would be limited without a question about a specific part of it.

A Special Page would be used to manage the extensions. Most likely the old siteadmin right or something else would be used to restrict who can modify extensions.

The dot folders Subversion and CVS use was what inspired me for most of how I put the extension together. Because of the extra data on an extension, any extension using the manager cannot be put in the root of the extensions folder. In other words, some extensions used to have a single file at say: extensions/ExtensionName.php Instead they need a folder like how many of the SVN extensions have: extensions/ExtensionName/ExtensionName.php The Extension supports a README file inside the folder additionally, so if you had the file: extensions/ExtensionName/README And that extension was one that supports the manager the extension would have a README link where a special page would parse that README file as WikiText. Simply put, the README file would act much like the Extension:ExtensionName page we have on MediaWiki.org, primarily there for information about the extension and it's installation. I plan to throw in a little pre-parsing tricks to make doing README files a bit easier. Such as letting the README use the <source lang="..">....</source> tags but convert those to <pre>...</pre> tags when the GeSHi extension is not installed. The actual .xml files and other extra data for the extensions supporting the manager are located in a dot folder: extensions/ExtensionName/.mwext The main file there is the extension.xml such as http://temp-dev.wiki-tools.com/extensions/wiki-tools/CWikiIncludes/.mwext/ex... extensions/ExtensionName/.mwext/extension.xml That holds the name, id, and various other bits of information about the extension, to sum up some of the important highlights (look over the example to see where they're located): *id:* This is the id of the extension. It's also used as the path to the extension. So the path to the extension should be (note that the location of the extensions/ folder is configurable): extensions//extensionid//... As you see in my example I use "wiki-tools/CWikiIncludes" as the id because the extension's folder is located at: extensions/wiki-tools/CWikiIncludes/ In a way, it's a method of making sure multiple extensions don't go using the same paths, and making sure that someone new to the installation of extensions doesn't break things by installing an extension in the wrong path if it uses some includes that require it's specific location. ((If the location of extension.xml doesn't match "extensions//extensionid//.mwext/extension.xml" the extension is 'discarded' from the list, and the user notified that a location is mis configured)) *name:* Simplest of all, the name of the extension which is displayed in the list and on it's information pages. *authors:* The authors section supports multiple authors. Realnames, e-mail, and a number of nicknames with links to userpages, irc, etc... can be used for identification of the author. (Though to lessen the repetitiveness I was considering some sort of Author ID or something which grabs the author information from a remote location. So authors don't need to go changing data in all their extensions if information changes) *license:* The license data can be specified and it will be displayed on the information page of the extension. The short name is used with the long name as the title. A url can link that to a license document, or some method (Haven't decided on what method yet) may display the small license text. The link can also be changed to use a icon (much like the GFDL icon in MediaWiki) with the short name as the alt. *mediawiki:* The mediawiki section contains requirements of mediawiki for the extension, right now there is only the version section inside which lets a minimum and maximum version of MediaWiki be specified. (Though, users do have the option to override the version limitation and install an extension anyways. For those extensions which aren't meant to be run on older versions, but still have the ability to.) *includes:* The includes section is what lists the files that are included like how you use require_once( "extensions/ExtensionName/ExtensionName.php" ); There is a lang parameter, which right now only has the value of php, I put it there in the case of extending what can be included in the future. The path of the file is currently relative to the extension's own directory. So Using ExtensionName.php in the ExtensionName extension would include: extensions/ExtensionName/ExtensionName.php It may be advantageous for extensions using an include to other _body.php and i18n.php files to move those into the extensions.xml file as when you try to enable an extension the Extension Manager checks each file in the includes for fatal PHP errors before actually enabling it, and makes sure that they don't cause php errors that would completely stop MediaWiki from running and listing in the includes instead of using include(); may provide better details as to where the error is. For those including multiple files, a SimpleInstall.php could be used for those who still wish to manually install the extensions using the require_once techniques in LocalSettings.php ((Yes, extensions supporting the manager can still be installed manually and work alongside old extensions)) *dependencies:* It's not in my example, but it's part of the schema. Extensions can list the id's of extensions which they may depend on. Like how RegexBlock depends on SimpleRegex. allowOverride is true by default, meaning users can override it and install the extension even if the Manager does not detect the extension being depended on. For the case where they may have a version of the extension which does not support the Extension Manager.

Aside from that file there are a few others: extensions/ExtensionName/.mwext/settings.xml - Lists settings such as variables, and extra rights that can be assigned to groups. These can be configured via the Extension Manager. By default the settings are included before the files are included, but they have a parameter that allows them to be included after, for those extensions which require it. extensions/ExtensionName/.mwext/install.xml - Install Script extensions/ExtensionName/.mwext/uninstall.xml - Uninstall Script The install/uninstall scripts list actions such as file copying, file deletion, running .sql files on the database, etc... that should be done on install/uninstall. For those extensions such as Oversight which require a new SQL table, or other extensions which add a SpecialPage and for some reason use one of the methods which adds a file to includes/ ((All actions which could do something dangerous are listed and looked over by the user before anything is run)) extensions/ExtensionName/.mwext/.build/ - This folder isn't part of the actual extension, it's created by the Extension Manager to store things which were done using the Manager. a "SettingsBefore.php" and "SettingsAfter.php" file in this folder is what is included with the PHP generated by the Extension Manager when a user configures various settings that can be configured for the extension. Also a ".enabled" file in this folder which contains the last modified date of extension.xml if the extension is enabled is what is used to determine if an extension should be used. The idea is that by using the last-modified date if an extension has an error which stops MediaWiki from using the Extension Manager, disabling it without the Manager is as simple as re-saving extension.xml, or deleting or modifying .build/.enabled. It also means that on installing a new version of an extension you need to re-enable it, making sure that you don't find fatal PHP errors show up by upgrading to a bad version because the enabling procedure verifies that there are no fatal errors.

For performance reasons by default the recursiveness of directories will be limited to 2 or 3. So project/subproject/package/extension would not work for the id of an extension unless you told a user to change the Extension Manager's configuration settings to allow a depth level of 4 or higher. An option of the manager could probably be used to detect extensions which are past the depth that the configuration allows.

There are some more things like methods of installing an extension, but that's over viewed in that link and I think this is Verbose enough for now. But just to note, the only real extra requirements are: -Placing extensions supporting the manager in their own folder. -Using the extension.xml file to list some information about the extension. Only about half the file is actually required. A number of things there can be completely omitted if you're trying to use as little of the Manager's features as possible. I've tried to come up with various ideas of how to allow the various things the Manager does to work even in odd chmod or limited sql settings.

~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com

Rob Church wrote:

It would be nice to know more about this extension manager than the mere fact it'll require an XML file for each supported extension.

Rob Church