We've recently completed a development sprint and released a new version to CiviCRM Entity, 2.0-beta3. In this article we will share with the community what is in the new release, what's on the horizon, and the overal vision of the project.
What is CiviCRM Entity?
CiviCRM Entity is a Drupal module which provides much more comprehensive integration of CiviCRM with Drupal. This module and its suite of sub-modules allows end users, site administrators, site builders, and developers to interact with CiviCRM in a completely Drupal manner.
CiviCRM Entity does this by exposing CiviCRM data as proper Drupal Entity types. By integrating directly with the Drupal Entity and Field APIs, Drupal Core and any Drupal module can be leveraged to augment or customize your CRM experience.
Contacts, Events, Memberships, Contributions, Activities, Addresses and other CiviCRM data can be leveraged with Drupal's existing cotnrib module toolset including Rules, Views, Entity Reference, Display Suite, Panels, Inline Entity Form, and many others in a profound and inclusive way.
What's New in 2.0-beta3
The core module CiviCRM Entity has gotten several updates under the hood with bugfixes and improvements. Many more entities have been exposed to Drupal, 40 now in total. New entity types include many aspects of the financial system:
- Line Items
- Participant Payments
- Payment Processors
- Price Sets
- Price Fields
- Price Field Values
This is a pre-requisite for the new and upcoming features including Drupal based event registration forms, available as well as of beta3.
There has been significant updates to the Drupal forms, coming from improved entity metadata, more support for custom fields, autocomplete widgets for many FK reference fields, and better integration with Inline Entity Form. CiviCRM Entity Inline, is a submodule that provides integration with Inline Entity Form, and it is now bundled with CiviCRM Entity when you download it from Drupal.org.
The menu for accessing the different entity type Manage Fields and Manage Display has moved to Structure->CiviCRM Entity (admin/structure/civicrm-entity), and taken out of the content types section. This path change won't affect your current functionality when you upgrade, just remember the new location.
For developers, you can now expose your own custom entities to Drupal, via a hook in a custom module or CiviCRM extension. See civicrm_entity.api.php for details. You can also alter settings for existing entity forms, by specifing an array of permissions or naming your own custom access callback function.
The core module itself should be considered stable, new functionality is being developed in sub modules. Several of the sub modules have previously been available separately on github and they have matured to the point where we want to bring them into the project so people can have immediate access to them. In addition newly sponsored features have been developed and are being shared back with the community.
CiviCRM Entity Reference Field
CiviCRM Entity Reference field is an exciting new feature added to the CiviCRM Entity toolbox. You may be aware of and use the the Drupal standard Entity Reference field. The standard Entity Reference module allows referencing Contacts from nodes or any other Drupal entity by storing the target entity id in the Drupal field table structure.
There are many use cases for this, but what if you want to edit the existing existing CiviCRM Addresses for a contact from the Drupal contact edit form? You don't want to re-reference the addresses, instead you want to work directly with what is already existing and standard in CiviCRM.
What was needed for this case is a "remote reference field", which gathers and modifies its targets from the existing, external-to-Drupal CiviCRM data structure.
The CiviCRM Entity Reference field type loads the child entities directly from the CiviCRM database and stores no values in the Drupal field tables. We've used this to create or edit a contact's CiviCRM addresses,emails, phone numbers, websites, from Drupal contact edit page, and Locations Block addresses from CiviCRM Events, with the consistent and familiar Inline Entity Form interface. Everything you do with a CiviCRM Entity Reference field in Drupal will be immediately reflected in the standard CiviCRM adminstration pages.
CiviCRM Entity Inline
Provides integration with the Drupal module, Inline Entity Form. Used by Entity Reference, and CiviCRM Entity Reference fields to provide a widget for editing referenced entities inline from the parent form.
CiviCRM Entity Actions
Integrates CiviCRM Entity with Views Buk Operations. Use to perform operations on custom generated lists of CiviCRM entities. Ever needed to modify 100K records at a time? Views Buk Operations batching allows massive operations without php memory or timeout errors.
CiviCRM Entity Views Extras
Provides additional Views relationships or other handlers for newly exposed entities such as Price Sets, Price Fields, Price Field Values and more. More coming as we continue to develop Views integration and will put here in future releases.
CiviCRM Entity Price Set Field
We are pleased to release this new sub module of the CiviCRM Entity project. The goal of this module is to bring two of the most important public facing functionalities into Drupal, event registration forms and contribution page membership and contribution forms.
Many of us have been using the great module, Webform CiviCRM, for bring functionality like this into Drupal. The problem here is two-fold. One, you must enter pricing options separately from the event or contribution page. Webform CiviCRM does not look for the price set for these entities so you have a duplication of configuration. It is preferable to have our Drupal interfaces and functionality directly manipulate and use the CiviCRM data. Secondly, it is unlikely there will be a D8 version of Webform and Webform CiviCRM any time soon, if ever. Looking into the future for CiviCRM and D8, this is a big problem. To get prepared for D8, we are investing time in improving the ability to have functional registration/donation/membership signup forms in a way that will be conceptually portable to D8. The concepts of entities and fields migrate directly to D8, in D8 there are still entity types and fields, but no Webform.
The goal of the CiviCRM Entity project is superior Drupal integration. We want to provide similar functionality, in Drupal, that CiviCRM native forms provide. This module is a big step in this direction.
CiviCRM Entity Price Set field provides a new field type to your Drupal installation. This field type has a widget for editing of simple price sets on the CiviCRM Event entity type edit form. On Event display, the field provides an Ajax multi-page event registration form. Currently only event registrations are supported, but plans for extending this module to contribution pages are underway and will come in stages. For example we've developed a new feature that will be part of beta4, the Event's registration form provided by this module will render the configured CiviCRM profiles are rendered and submitted on registration.
CiviCRM Entity Group Assign
Provides CiviCRM Entity Contact Group Assign Field Type. This field type has an edit widget for adding/removing a contact to a selected list of groups. Site builders can add multiple fields of this type on the Contact entity, configuring each field to toggle a different set of groups, and use either checkboxes or radios. In this way admins can create easy to understand, custom sets of groups for content editors to toggle for contacts. A wide variety of custom use cases can be set up without any code.
Drupal Fields are a Design Pattern
Traditionally, we think of a field as a way to store additional information. This is true, but the Drupal Field API was forward thinking and robust. It is capable of much more than just data storage. There can be fields that store no data in the Drupal database, but still provide an interface on the entity edit form and post processing on entity save. Complex field data can be rendered on display pages, engaging the Drupal theme system. The field types described above only some examples of what is possible. As an example to developers we've included two additional submodules that provide very specific functionality.
Once you understand the pattern, the sky is the limit for the amount of functional pieces that can be integrated, in a consistent, configurable manner.
We continue to chip away at superior Drupal integration for CiviCRM. The end goal of a completely configurable, functional Drupal interface to many major CiviCRM systems is in sight. The foundation is poured and set, the framing and roof are up, and we're filling in the utilities and fixtures. In the near term the focus will be continuing development of the CiviCRM Entity Price Set Field to support Drupal native contribution pages with donation and membership forms and functionality, including profiles.
Documentation is one the way, we've added tons of features, but people need to know how to use them. Its coming.
Perhaps most importantly, a Drupal 8 version of CiviCRM Entity will be developed next year, depending on the release date of the Drupal 8 version of CiviCRM. Hopefully we will have a release of CiviCRM Entity shortly after a version of CiviCRM for D8 is released.
Why CiviCRM Entity?
Drupal is an increasingly powerful and prolific CMS, which has made serious inroads to the enterprise markets. CiviCRM is the best open source CRM, and the project has the opportunity to join Drupal in creating enterprise level solutions. The more integrated CiviCRM is with Drupal, the more attractive it will be to non-profits, corporations, and the development and design shops that service them. Tight and native integration with Drupal is attractive to Drupal developers and theme designers, giving the opportunity to add these people to the CiviCRM development community.
Secondly, read the stated roadmap for CiviCRM. Each of the listed goals can be achieved by CiviCRM Entity.
With the ability to manage fields and displays in the Drupal fashion, you have a powerful form builder.
By having native Drupal display and forms, you have a robust and well established way to make CiviCRM beautiful. The Drupal theme system is already pluggable, and powerful. It makes CiviCRM consistent with your existing themes. With Drupal 8 modern templating technologies such as Twig will be available, a goal that native CiviCRM will struggle to acheive in the same amount of time.
By integrating with CiviCRM Entity, the Drupal Core APIs are made available to developers to create custom CiviCRM solutions. This is both an improvement, and just a "plus" in general. You still have the CiviCRM API if you like, but you get this entire additional library of capabilities.