Provide a mechanism for packaging and automated installation for small CiviCRM extensions

=== Rationale

CiviCRM currently contains at least three types of extensions. We're using "extension" term to differentiate this kind of functionality extending code from components and external Drupal based modules. These extension types are:

• custom searches
• custom reports
• payment processors
  We want to introduce consistent system for managing and maintaining these extensions, therefore below specification has been prepared. It attempts to lay out the system for managing (adding, removing) extensions as well as introduce a consistent format for packaging them.

Basic concept is built around packaging CiviCRM extensions in specified way and allowing to plug them into existing installation, as well as turn them off any given time. As first step, we would like to implement a solution, where extensions are installed by putting appropriate files somewhere within CiviCRM installation. As next step, we would like to bring this solution to a stage, where it will serve as a distributed repository of plugins and extensions for CiviCRM, so that users won't be forced to download files by hand, but will be able to download and install them using Manage Extensions screen.

=== Manage Extensions screen

Entering this screen will trigger discovery of extensions process (see). The screen will contain the list of extensions, both registered in the system and those that are newly discovered and unregistered (latter ones highlighted in red). Each extension will have following actions:

• Disable/Enable (based on current state, see "Discovery of extensions")
• Register/Delete (based on current state: register if newly discovered, delete if already registered. Delete causes all the extension's files to be removed, confirmation required upon deletion)
• View info (allows to see all the details from info file - might be implemented as drilldown selector)

In further extension mechanism development, this screen will allow downloading and installing extensions directly.

=== Global Settings >> Directories screen update

This screen will be extended with "Extensions Directory" setting. This will be the name of directory where all the extensions reside. The assumption is that the directory contains three subdirectories (for now): 1) payment/, 2) search, 3) report, where appropriate extension packages are placed. This directory should be outside of CiviCRM codebase to avoid problems when upgrading core.

=== Packaging

All extension's files should be placed under single directory, named after an extension ("extension's root"). Each extension package should contain an INFO file (specific file name to be figured out, most probably XML format), which describes basic properties of an extension. This file should be put directly in the extension's root directory.

Information that will have to be stored in INFO file

• name
• description
• type = one of: search, report, payment
• maintainer = <First Last> email@addr.es
• compat = 3.1, 3.2 (version compatibility, should only refer to major versions?)
• devel_stage = one of: stable, beta, alpha, devel
• callback = the name of extension's callback class

INFO file is the only fixed requirement for now, all the other files can be freely laid out by extension maintainer (this needs discussion).

=== Extension registration

Each extension will be registered in civicrm_extensions table. The structure of the table will be following:

civicrm_extension:

• name
• description
• type_id (foreign key to option_value)
• maintainer
• compat
• devel_stage_id (foreign key to option_value)
• callback

=== Discovery of extensions

In first stage, this will be a simple process, where extensions directory will be searched recursively and info files located. All the newly discovered extensions will be disabled by default and highlighted in red on Manage Extensions screen. Administrator will have ability to register them (see Extension Registration). Discovery should also perform a simple sanity check on existing extensions (both registered and unregistered) and mark them appropriately if they have any problems (malformed INFO file, syntax errors in callback class, etc).

In further stages, we will be able to implement online extension discovery. In such case, extensions directory will be treated only as a "cache" for the code and other files.

In first stage extension can have 2 states:

• enabled - the code of extension is included upon system init
• disabled - the code of extension is skipped upon system init

For extensions that are enabled, we need to implement exception catching upon inclusion, so that - in case the extension is malformed and throws critical errors upon inclusion - administrator is given a meaningful error message and an option to disable the extension immediately.

In further stages, where we will implement online extensions discovery, the list of states can be expanded to contain: "needs_update", "unstable" (if exception is caught upon inclusion), etc.