Plugin API

This page is for keeping track of various aspects of the plugin API.

Feel free to add anything to this page you think would be useful.

Requirements

• Automatically handle database changes
• Need to be able to show plugin specific preferences
• Some plugins will need to have access to the templates in some way
  • Think a plugin that adds buttons to mark a message as spam
  • Configuration interface for message filters
  • A plugin that handles imap ACLs
  • The oft mentioned RSS reader

Current sate

We created a branch branches/devel-api for the implementation of the Plugin API.

This only implements a basic backend plugin architecture with a few hooks. The way plugins may add UI elements and how they can register their steps and templates is not yet defined. A draft about what we propose for the client part is to be found here. This requires some basic changes in the client-server communication before plugins can be developed.

The plugin architecture outline

On the server we would have a folder called plugins. We could follow the way that WordPress plugins work. They just have you drop folders into the plugins folder and the folder name is used to define the plugin. So for an RSS reader plugin one would have the following structure.

plugins\
  RssReader\
    RssReader.js
    RssReader.php
    RssReaderConfig.php
    media\
      RssReader.css
      RssReaderIcon.png

The RoundCube app instantiates the class rcube_plugin_api which then loads all plugins from the plugin folder. A plugin folder is required to contain a PHP file named the same as the folder itself which contains a class with again the same name. This class extends rcube_plugin which provides a common interface for the plugin API. The plugin object then registers callback functions to certain hooks. The callback function receives an hash array as single argument containing all the hook-specific information. If the callback function wants to change some of the received data it has to return the complete argument array containing the altered properties.

See branches/devel-api/plugins/sample for a sample implementation or read the ​latest discussion about it.

Proposed Plugins

• Automatic/external user authentication
• Password change
• Mail filtering
  • internal to roundcube for people who don't have access to server side filtering
  • sieve recipe editor
  • other server side editing
• Extended (site specific) preferences
  • spam folder
  • how to handle mail tagged as spam
    • add/change a header
    • move to a folder
    • forward to another address (inline or as an attachment with headers intact)
• Import attached VCS files
• Alert on new Email (Messagebox / Sound?)
• Send emails via other SMTP servers
  (usecase: gmx-email forwarded to my server - sending gmx-emails only possible via gmx-SMTP)
• Per-user configurable spam levels with amavisd-new and sql (like squirrelmail plugin amavisnewsql). This would as well add server-side per user black and whitelisting.

Other things to look at for planning/implementation

• TYPO3
• Squirrelmail
• Horde
• Wordpress