User:Jeroen De Dauw/GSoC2010/Status

Plans 3.0
The goal now is to take on deployment for MediaWiki and extensions as a whole, as it makes little sense to have 2 separate systems with duplicate functionality, and integration issues. A lot of the work needed to have functionality similar to WordPress is already there, and simply needs to be adapted slightly to work in a more general system.

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, 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

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.

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.