SoC plugin repository

This is one of the projects to be implemented during the Google Summer of Code 2009.

Student: Tim Patrick, Mentor: Matt West

Project info and advancement during Summer of Code

• Structure and Information
• Developing Plugins
• Patches and Upgrades
• Forum discussion
• Repositories:
  • Geeklog version with support for the Repository built in
  • Plugin Repository plugin
  • Repository Manager plugin

Pre-Summer of Code idea discussion & preparation

Incentive

Geeklog's functionality can be extended by plugins, i.e. add-ons that use the dedicated plugin API which allows them to be seamlessly integrated into Geeklog. The standard Geeklog distribution ships with some plugins pre-installed (Calendar, Spam filter, etc.). Other popular plugins include a forum and image galleries.

Traditionally, installation of a plugin was a somewhat awkward process: After unpacking the tarball or Zip archive, you have to rename and move three directories into specific places, then run the plugin installation script.

Thanks to the Google Summer of Code, this is about to change in Geeklog 1.6.0. Now you can upload plugins directly from Geeklog's plugin admin panel. Geeklog will take care of moving the directories into their proper place and also run the install automatically.

With this project, we want to take things one step further and allow plugin installation over the internet.

The idea is to provide a plugin repository from which the admin of a site can easily pick a plugin for installation.

Details

To allow installation of a plugin from a plugin repository, both sides have to be implemented. So the goals of this project are

• Implement a "Plugin Repository" plugin
• Extend the plugin admin panel in Geeklog to allow download from a plugin repository

Plugin Repository

The plugin repository should be implemented as a Geeklog plugin itself. It will be installed on sites that want to provide plugins for download. Geeklog's homepage would be an obvious use case, but plugin authors may also want to provide their own repositories on their own sites.

The general features are similar to those of the existing File Management plugin, namely

• allow users to upload plugins
• require approval from a moderator
• allow users to download the approved plugin

The repository should allow more flexibility here, though, depending on the use case, e.g.:

1. an "Open" setup (e.g. geeklog.net):
   • any user can upload
   • users can update their submission (requires re-approval)
2. a "Closed" setup (e.g. plugin author's private site):
   • only dedicated users can upload
   • no approval required
   • dedicated users can update their submissions without approval

These options should be configurable.

Notes

• For large repositories, a category system would help to keep things maintainable and usable.
• Uploaded files should be checked automatically. For example, a minimal Geeklog plugin will always contain a file called functions.inc and should also include a file autoinstall.php to allow automatic installation.
• The repository should allow "traditional" downloads from a browser, too, in case users need to do manual plugin installs.
• Geeklog provides PHP classes for upload and download of files. The download from within Geeklog can be done using the PEAR HTTP::Request package.

Feeds

Information about the plugins in a plugin repository should be provided as feeds (e.g. Atom or RSS). A Geeklog site admin should be able to subscribe to these feeds easily in order to stay informed about new plugins and updates to existing plugins - especially updates of plugins they have already installed.

Geeklog provides a framework for reading and writing feeds in various formats (Atom, RSS, RDF).

Plugin admin panel

Geeklog's plugin admin panel should get a new pane that handles

• feeds and update information
• selecting a plugin for installation

Questions

Some questions and considerations to get the student started:

• Use case: User finds a new site that offers a plugin repository. How can they easily subscribe to that site's feed?
• A plugin that is installed from a repository could provide an update feed for itself. How should these be handled? This may require additional plugin API functions.
• Security considerations: Ensure integrity of plugin archives (checksums). What can we do about malicious plugin repositories?

Considerations for the Future

In the future (post-GSoC), we may want to extend the functionality to allow download and installation of other components, e.g. themes and language files. The code for this project should therefore be written in a way that it allows future extensions and avoids things like hard-coded paths or making assumptions that would only apply to Geeklog plugins.

Level of Difficulty

medium

Geeklog already provides solutions for the basic tasks: Uploads, downloads, plugin installation, feeds. Putting them all together in a way that's easy and secure to use is what this project is about.