[Mediawiki-l] MediaWiki Extension Manager... XML function, lib, or mw code?

DanTMan dan_the_man at telus.net
Sun Aug 12 12:27:44 UTC 2007


^_^ 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/extension.xml
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
>   


More information about the MediaWiki-l mailing list