SoC plugin repository

(This is an idea page for the Google Summer of Code)

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 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 now 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 the existing File Management plugin:

• 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. "Open" setup (e.g. geeklog.net):
   • any user can upload
   • users can update their submission (requires re-approval)
2. "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.
• Geeklog provides PHP classes for upload and download of files.

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?

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.