^_^ 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/e…
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