Geeklog Plugin Repository

My name is Tim Patrick, and I am the GSoC student that has been working on the Plugin Repository.

Introduction

The Repository attempts to provide a central place where site administrators are able to install plugins with a single click. It is modeled after the software management systems in Linux. Any site is able to set up a repository, which another site can connect to and search for plugins available. As well, patches and upgrades to your plugins can be installed by the user with one click, allowing for quick and easy updates, patches, and plugin installation. This will provide ease of use to the consumer, while more initiative to develop plugins for Geeklog.

How it works

Once a repository has been installed on the server, users for that site are able to upload plugins to the plugin repository. To be available for one-click installation, the plugins must adhere to the standards for plugin development as issued here:
http://wiki.geeklog.net/index.php/Developing_Plugins
If, however, it does not follow the standards, then it is still available in the repository, only for manual download and install instead of one-click install (with the option of manual download and install). Plugins once uploaded, may be edited, and reuploaded to the repository.
Once a plugin has been uploaded, depending on the configuration, the plugin may have to be approved by an administrator before use. If the uploading author is an administrator, the approval need is no longer there and it is skipped, to allow less work for the administrators.
The uploading author (and any maintainers the administrators may add to the project) can upload patches to the plugin, and upgrades. However, only the uploading author and administrators may remove the plugin from the database.
On the client (end user site) end, the user has the choice of adding more repository URLS to his database of them. (Think APT-GET for those who have Linux)(The main Geeklog one is there by default). Existing repositories in the database can be deleted or disabled. As well, to prevent against malicious content, repositories are blacklisted, whitelisted, or neutral by the Geeklog admins. Attempting to install from a neutral repository results in a cautionary warning. Blacklisted repositories, however, may not be added to the repository database, to in an attempt prevent malicious people to use social engineering to install malicious programs in the guise of valid plugins.
The client can update the local list of all plugins available by clicking on the Update Repository List, where the list of all available plugins for each repository is loaded to the client site for searching. (Think APT-GET UPDATE).
The client can then search for a plugin using a search box, using the exact plugin name, or using the AND and OR operators to try to find matches. A list of matched plugins is returned, and the client can then simply click 'Install Plugin' for the plugin to be automatically installed. Alternatively, the are able to download the plugin and manually install it (Or if the plugin cannot be offered for automatic installation, that is their only option).

Patches and Upgrades

As well as offering the plugin for one-click install and / or manual download in the repository, the uploading author or maintainers can also upload patches and upgrades.
To allow the patches or upgrades to be offered for one-click install, the following standard must be followed:
http://wiki.geeklog.net/index.php/Patches_and_Upgrades
On the client side, once the client clicks the 'Check for updates' link, a few things happen.
First, the list of repositories is updated, for example, a neutral repository may have become whitelisted.
Next, a list of all updates and upgrades available for each plugin is obtained from each repository whose plugins are installed, and if any are found, they are returned to the client. The updates / upgrades are listed, and allow the user to uncheck any they do not want to install.
Once the user clicks in 'Install' button, for each available update / upgrade, the relevant database tables and plugin files are backed up, and the update commences. In case of serious error, the old files and SQL is rolled back, and the installer makes a note that there was a failed plugin install, and starts with the next update / upgrade. At the end, the client is notified of the result, as well as any which fail.

Making development easier

The other goal of this project, besides making it easier for clients to install plugins, is to make development of the plugins easier.
This is accomplished by implementing a very easy API to follow to plugin installation, uninstall, patching, and upgrading, allowing the developer to spend more time working on the actual plugin, instead of trying to get the installation et all working.
As well, distribution is not a problem, as well as the plugins being scattered about, as they will all exist in a standard place. Even though technically any site can add their own repository server, the reason this is in case it is a test plugin that only a few developers want access to and not to add to the main Geeklog one.

I will be posting a guide on converting your existing plugin to work with the new repository.
As well, I am working on a tool to automate this process.