Requests for comment/Distribution and deployment

This page is for organizational purposes of a 2010 Google Summer of Code project with as goal the creation of an extension management platform for MediaWiki. Jeroen De Dauw will is mentored by Brion Vibber on this project.

Project goal
The goal of this awesome project is to create a set user friendly administration interfaces via which administrators can manage their wiki and extensions. The user experience should be as awesome as the Wordpress one, or even better.

The technical part
A rough draft of how I see the structure of the end product, and where the code is coming from:



Stuff we already have
Some of these things still require some work, but if they are here, it means the bulkload of effort is already done.


 * Web interface for the core installer (new installer chad has been working on).
 * CLI interface for the core installer? (not really checked this out yet, but appears to be there)
 * Core installer class with database install and upgrade capabilities.
 * Filesystem abstraction (I ported this from WP (see code here), mostly done, no testing done yet though).

Stuff that's still needed

 * Everything related to detecting updates, fetching packages and instructions, ect. The DF has some nice stuff that can be used here, so does WP. It's be nice to also have an abstraction layer here, so multiple mechanisms can be used here. An extension repository also needs to be set up, preferably on mediawiki.org.
 * Filesystem support for the installer, so it can be used to upgrade MW by clicking a button and then just fetching the new release and doing all the work. This can be achieved by creating the generic installer class and making the core installer inherit from it.
 * Extension installer class and the special pages that provide an interface to it.
 * Extension support for the core installer: installation and upgrade. This can be done by re-using the code of the special pages.
 * CLI support for extension management

Core installer
The core installer should have all current capabilities plus


 * Upgrading of the filesystem from a fetched package
 * Install/update extensions that are detected

Special:Update
A page similar to the WP wp-admin/update-core.php

Checks for updates for both core and extensions, and shows update options for individual components, or the whole deal.

Special:Dashboard
A page similar to the WP wp-admin/index.php

A dashboard for administrators containing update information and fancy stuff like statistics.

Special:Install
A page similar to the WP wp-admin/plugin-install.php

On this page administrators can browse and search through extensions that are in the connected repository. This can be very basic to start with, but should eventually include filtering on categories and keywords, popularity, rating, ect.

Special:Extensions
A page similar to the WP wp-admin/plugins.php

A page listing all installed extensions, with options to uninstall, disable and upgrade them, as well as links to documentation, ect. Once MediaWiki has a configuration database, links to configure the extensions can also be included here.

CLI interface
It'd be nice to be able to do most stuff also via CLI, although I think the primary focus should be the web interface, as the vast majority of users will prefer that. The smwadmin.php tool from the DF can probably be adapted for this task pretty easily.

Roadmap
This is the very loose planning I have right now:


 * Finish porting SSH2 filesystem abstraction class.
 * Get confirmation of Brion to go ahead with Plans 3.0 and get core access. (required for following steps)
 * Create installer class, adapt to core installer to work with this, and also create the extension installer class.
 * Take care of the fetching stuff.
 * Create the interfaces.

Work done
Oldest first:


 * Researched all involved components and created the above draft
 * Ported WP filesystem abstraction classes (base class, FTP and direct one)

Configuration
I have done some investigating into the deployment part of the project, but have come to realize I won't have time for this if I want to do a good job on the deployment part. I will probably publish a summary of my findings, and how I think things should progress here at the end of my project.