User:DanielRenfro/ExtensionRepo

This page was a draft for updating Requests_for_comment/Extension_manager. Please leave your comments there.

These are notes about implementing an extension management system — spawned by a discussion at the Ask the Developers session at Wikimania 2012.

Problem(s)

1. There is no explicit dependency and/or compatibility information in the current implementation of extensions.

   This means there is no way to tell if version X of an extension works Mediawiki version Y or not.

2. There is no way to track extension usage, gather feedback, or rate extensions.
3. There is no way for a sysop to administer extensions (or Mediawiki itself) from within the wiki.

Solution

A secure, integrated, intelligent, automatic, (and slightly distributed) extension manager.

Rationale

Mediawiki has a robust system for implementing extensions, but currently lacks an integrated mechanism for managing them. As of the most recent version of Mediawiki (v1.41.1) installation, management, and dependency-resolution of extensions is done manually. These tasks are usually done by a sysadmin or a staff member. While knowledgable users (with command-line access) can keep the extensions managed, it seems like there should be an integrated solution that does not require ssh.

Past attempts

This issue has come up again and again in various forms and forums (online and offline) over the years. Jeroen De Dauw's Google Summer of Code 2010 proposal, in many extension (see below), and recently as a request for comments-page. These attempts met with varying levels of success, and the lessons learned there should not be ignored.

Current state of extension management

Mediawiki ships with a number of "pre-installed", (or pre-installable) extensions:

• ConfirmEdit
• Gadgets
• Nuke
• ParserFunctions
• Renameuser
• Vector
• WikiEditor

While the argument of whether or not these extensions should be folded into core is outside the scope of this document, this illustrates a need for a way to package common extensions with the software. A better alternative is to give the configuring user the ability to search and install any and all extensions they feel they need when they are running the install script. Currently this is impossible as the infrastructure doesn't exist – providing a copy with the software is a temporary fix that works well.

Extensions

There have been a number of attempts at solving the problem of extension management. Listed below are extensions directly and indirectly related to this project.

Extension:Distribution, Extension:Deployment

Most closely related to this project is Jeroen De Dauw's Google Summer of Code 2010 proposal. Its aim was this exact issue and resulted in the extensions Extension:Distribution and Extension:Deployment. It has influenced this page a lot.

Extension:ExtensionManager

This extension is misnamed. Jean-Lou Dupont created Extension:ExtensionManager in order to facilitate installation of other extensions he authored. It seems to be currently unmaintained based on the lack of updates and article history. The idea behind this extension was good -- an installer for other extensions, downloaded from a common repository. However, it's scope is too small for the Mediawiki software in general.

Extension:ExtensionClass

Extension:ExtensionClass simply adds a PHP class named ExtensionClass, which is used by a number of other extensions used by Jean-Lou Dupont. While possibly useful, it seems hopelessly out of date - similar to the above extension.

Extension:ExtensionInstaller

Redundant with the current installer, this extension allows extensions to be bundled and installed with the Mediawiki software. Once setup is complete, this extension doesn't do anything.

Extension:Configure

The Configure Extension is quite exciting and powerful extension that allows in-wiki changing of many, many settings. Some of the features include:

• a history of past configurations so that an admin can easily rollback site-wide configuration to an earlier date
• api modules allow for programmatic access
• diffs between past versions of settings
• multiple special pages for managing core and extensions
• a PHP extension to make parsing some setting-files faster

This is a large step towards a fully integrated configuration environment that does not require command-line access. I think that this extension's goals somewhat overlap with an extension/package manager and it would be a good idea to collaborate with the authors for a common goal.

Thoughts on client-server model

At first this project was imagined as in a client-server context, with two separate extensions providing the functionality for each. It was assumed that there would be a centralized repository for extensions, and clients (Mediawik installations) would consume extensions being served from the server. But the question arises: "Who manages the extensions on the server and where to they come from?" The repository would most definitely be an instance of Mediawiki itself, with some functionality added to turn it into an extension-repository. Each repository would need another repository of it's own to install extensions — this is a recursive problem with no solution. It would defeat the purpose of this project to not allow the repository to manage its own extensions. Therefore, it was decided that the code for this project must cover both client and server functionality, allowing repositories to manage their own extensions.

Question

If all repositories are remote (not local,) where does a repository get its extensions?

Answer

Repositories can be local. Allowing Mediawiki installations to both server and consume extensions. (By default the repository functionality is turned off, but can easily be turned on with a single configuration setting.)

The solution was a simple segregation of the idea of installation with the idea of activation. If all installed extensions are immediately active, repositories cannot host extensions without activating all of them. If, however, installation is separated from activation, any Mediawiki instance can act as both a repository -- activating only those extensions that are needed.

Features / deliverables

This is a long list, but it can be done!

• dependency & compatability resolution
• configure the extension upon installation, and then again whenever you feel like it
• both GUI and command-line interface
• (requirement) rigorous security and error-checking
• integrated tests for compatibility
• logging
• (requirement) don't break the current extensions
• permissions (possibly a new role, group, etc.)
• flashy Web2.0 interface that makes people go "Ooooo"
• API modules
• distributed nature — any package can be installed from any repository
• automatic and manual checking for extension updates (and updates to MW itself)
• extension browsing
  • recommendation of similar extensions
  • show a list of most used and most recommended/highest rated extensions
  • keyword search with an option to limit by extension-version/compatability-with-current-MW-version
• enable and disable extensions without uninstalling them
• tracking and analytics infrastructure (possibly by means of the api or just querying the database)

"It'd be cool if..." features

• an Extension: namespace (NS_EXT) that's filled with auto-generated pages about each extension, somewhat like MediaWiki's Extension namespace
  • provides a place to view information, urls, versions, rate the extension, leave feedback (?), etc.
• one-click installation
• a better Special:Version section
• feedback on extensions in the form of
  1. ratings (1-5 stars?!)
  2. comments
  3. ability to fork w/link to source code (github or tarball or other)
• downloading class that supports:
  • resuming, timestamp checking, parallel downloads, cached file validation
  • FTP user limit autodetection
  • file://, ftp://, http://, https://, scp://, ftps://, ldap://, etc.
• easy way to upload a new version of your extension to a repository (api?)
• special page for configuring mediawiki itself
• parser-functions like {{#latestreleasenumber:extension}}, {{#supportedreleasenumber:extension}}, etc.

Benefits

• one-stop-shop for managing extensions
• wiki admins/sysops can also administer extensions without command-line access/knowledge
• faster than doing it manually
• should cause people to run more updates (especially if a notification system is built in)
• recommended extensions for new sysops
• more visibility for extensions and extension developers
• easier to configure existing extensions

Related problems

• updating the core code from within the wiki

  (Hey, if Wordpress can do it, we can do it better!)

Subpages

• /Technical

See also

• Extension:ExtensionDistributor, and Special:ExtensionDistributor
• Extension:Update
• User:Jeroen De Dauw/GSoC2010/Proposal
• Extension:Deployment
• Extension:Distribution
• Deployment

Further reading

• Dependency management for grown ups - Richard Crowley’s blog