Packaging¶
When developing an enhancement for CiviCRM, one writes code based on Civi's programming interfaces, such as APIv3, CRM_Core_Page, or CRM_Report_Form. You need to put this code in some kind of file or package that can be installed on a CiviCRM system.
The best-supported approach is to develop the package as a native CiviCRM extension -- this package format works in all CiviCRM environments. However, there are other packaging formats (such as Drupal modules and WordPress plugins). How do they differ? Well, from Civi's perspective, code is code regardless of the packaging -- but the tutorials, glue-code, tools, and culture may differ. For example, you can write a subclass of CRM_Report_Form and put it in either a CiviCRM extension or a Drupal module, but a few lines of glue-code would be different, and the code-generator (civix generate:report) is only tuned to output native CiviCRM extensions.
Comparison Matrix¶
| Capability | CiviCRM Extension | CiviCRM Custom PHP/Tpl Dir | Drupal Content (Smarty) | Drupal Module | Joomla Plugin (Civi v3.3+) | WordPress Plugin (Civi v4.6+) |
|---|---|---|---|---|---|---|
| Pre-Install | Configure path; (For devs: install civix) | Configure path | Configure new format | None | None | None |
| Compatibility | All CMSs | All CMSs | Drupal-only | Drupal-only | Joomla-only | WordPress-only |
| Distributability | Good | Yes (Extra Steps) | Yes (Extra Steps) | Good | Good | Good |
| Packaging | Yes | No | No | Yes | Yes | Yes |
| CiviCRM API | Yes | Yes | Yes | Yes | Yes | Yes |
| CiviCRM Hooks | Yes | No | No | Yes | Yes | Yes |
| CMS Hooks | No | No | No | Yes | Yes | Yes |
| CodeGen | Yes | No | No | No | No | No |
| Reports | Yes | Yes (Extra Steps) | No | Yes (Extra Steps) | Yes (Extra Steps) | Yes (Extra Steps) |
| Payment Processors | Yes | Yes (Extra Steps) | No | Yes (Extra Steps) | Yes (Extra Steps) | Yes (Extra Steps) |
| Searches | Yes | Yes (Extra Steps) | No | Yes (Extra Steps) | Yes (Extra Steps) | Yes (Extra Steps) |
| SQL Tables | Yes (Extra Steps) | No | No | Yes | ? | ? |
| Web Page | Yes | No | Yes | Yes | Yes | Yes |
| Web Form | Yes | No | No | Yes | Yes | Yes |
| Extend API | Yes | Yes | No | Yes (Extra Steps) | Yes (Extra Steps) | Yes (Extra Steps) |
Key:
- Pre-Install - Are there any major steps one should take before using this type of add-on?
- Compatibility - Are there major constraints on which CiviCRM installations can use this?
- Distributability - How easy is it to share, mix, and match add-ons among different sites?
- Packaging - Does this require extra packaging steps (eg write info file, build tarball)?
- CiviCRM API - Can one CRUD entities with the API?
- CiviCRM Hooks - Can one respond to processing events in Civi?
- CMS Hooks - Can one respond to processing events in the CMS?
- CodeGen - Can one use the civix code generator?
- Reports - Can one package a new report?
- Payment Processors - Can one package a new payment processor?
- Searches - Can one package custom search screens?
- SQL Tables - Can one add/drop/migrate custom SQL tables?
- Web Page - Can one define new URLs with basic pages?
- Web Form - Can one define new URLS with forms?
- Extend API - Can one add entities or actions to the CiviCRM API?