- Use APIv3 and hooks. Package code in Civi extensions or CMS extensions (w/trade-offs).
- Create a CiviCRM extension developer's guide to best practices (Nicolas?)
CiviCRM Extensions are packaged pieces of functionality that extend CiviCRM's out-of-the-box functionality, independent of CMS platform.
As of CiviCRM version 5.24.0 extensions are also used internally within CiviCRM to organise chunks of functionality that implement a specific feature. These extensions are part of the main CiviCRM repo and sit inside the ext folder. It is anticipated that over time more chunks of functionality will be moved into these core extensions, as part of our goal to make the code more readable and maintainable. Core extensions cannot be seen in the extensions UI and the structure is invisible to the end user.
There is not currently a clear guideline as to when a feature should be re-organised into a core extension but one useful guideline is whether it can be fully implemented using the extension framework. In some cases we expect to move code over to an extension over a period of time, as we disentangle the functionality from deeper in the main codebase. While it IS possible to disable a core extension through the API it is not currently a supported configuration and site builders should understand this is at their own risk.
This section covers how to write extensions.
Pick a unique single word for your extension's name. Note that this name is used throughout the extension's code, e.g. function names, so it should only include characters that can be safely used in that way.
Historically, extension names used to follow the same convention as Java package names – they look like reversed domain names. (e.g. `com.example.myextension`), but this is no longer the recommendation.
- Have basic knowledge of PHP, Unix, and object-oriented programming.
- Install civix v14.01 or newer. For instructions, see Civix Documentation. This page assumes that "civix" is installed and registered in the PATH.
- Configure an extensions directory. For instructions, see Extensions. This page assumes the directory is
/var/www/extensionsand if you are using buildkit then the directory is
/buildkit/build/dmaster/web/sites/default/files/civicrm/ext, but you should adapt as appropriate. Your extensions directory must be under the CMS root directory so that civix can find and bootstrap the CMS. Otherwise, it will fail with an error like "Sorry, could not locate bootstrap.inc" on most operations.
- The user account you use to develop the module must have permission to read all CMS files, including configuration files, and write to the extensions directory. For example, Debian's drupal7 package saves database configuration to
/etc/drupal/7/sites/default/dbconfig.php, which is only readable by the www-data user. You will need to make this file readable by your development user account for civix to work.
Writing an extension is a great way to implement a new feature – but it may be unnecessary if someone else has already implemented that feature. If you're not sure, you can do a couple of things: - Search the Extensions Directory for an existing extension. - Post about your planned extension in the Extensions Channel.
Extensions provide a native, portable way to extend CiviCRM, but there are other ways to extend CiviCRM – such as implementing Drupal modules or Joomla plugins. If you're considering another way, look at the Add-on Formats to help decide.
1. Install civix¶
Some tasks in the process of writing an extension require boilerplate code. To reduce the amount of work required to find, understand, and adapt the boilerplate code, one should install the CiviCRM extension builder, civix. Civix is a command-line tool which generates code for some common development tasks.
For more information on the boilerplate civix generates for you, in particular the extension manifest file (info.xml), read on.
To get started with development, one should usually follow the steps in "Create a Module Extension.". A module extension is the most flexible type of extension – it can define any mix of new reports, custom search screens, payment processors, and web pages; it can listen for hooks, override page-templates, and more. The coding conventions closely resemble those of CiviCRM Core and of CiviCRM-Drupal modules. Module extensions are fully supported in CiviCRM 4.2+.
The CiviCRM ecosystem is built on the belief that non-profit organizations can serve themselves best by collaborating in development of their data-management applications. As staff, volunteers, and consultants for non-profit organizations, we can share our new enhancements and extensions -- and build a richer whole for the entire ecosystem.
Extension authors may make their extensions available to the larger CiviCRM community by publishing them in the Extensions Directory.
Interacting with core¶
There are a number of ways in which extensions can interact with core. These are supported to greater or lesser degrees.
Fully supported methods are:
- Internal Symfony listeners (e.g.
See also this blog post describing the
Civi:: facade in more detail.
Some methods within the CiviCRM Code base that extension developers have been relying on have now been deprecated:
CRM_Core_Error::fatalExtension authors should replace fucntion calls with either
throw new CRM_Core_Exceptionor
throw new <insert CiviCRM Generated Exception>or
CRM_Core_Error::statusBounceif the error is being generaged from a form.