It's becoming a common request from our clients to find user-friendly ways to integrate CiviCRM data with the rest of their Drupal website functionality. Oftentimes content creators without direct user access to CiviCRM need to do simple things, such as create, update, and delete contacts in simple, specific ways.
Example Use Case
A hypothetical organization advertises various community service projects that they organize and coordinate. Each service project can have it's own page, created by adding a Project content type to display a description, images, videos, slideshows or other information for each project. You'll probably use a View to show multiple Project listings on a page. All that is standard Drupal site building content and functionality. No problem.
But what if the organization wants to display to the user the Project Coordinator(s), which they also want to store in CiviCRM as contact(s)? Their Drupal website content creators need to be able to select, create, and update CiviCRM contacts for the coordinator on the Project node edit form in a simple, user friendly way. The website content creators are not given access to the CiviCRM back end. The organization wants the form to be styled like the rest of the Drupal site and be fully responsive.
Challenge
You have CiviCRM data that you need to use with Drupal's standard field and node display and theme structure. What to do?
The Solution
CiviCRM Entity to the rescue!
CiviCRM Entity is a Drupal module which exposes many CiviCRM entities as true Drupal entities. That means that almost any module that can use Drupal entities can also access and manipulate CiviCRM data, Drupal style. This includes many commonly used modules such as Views, Rules, Search API, Entityqueue, and many more.
You can use a standard Drupal Entity Reference field and integrate nearly 30 different CiviCRM entities in the standard Drupal way, into any of your node or entity infrastructures. Contacts, Addresses, Emails, Phone numbers, Events, Contributions, Memberships, Activities, and many more CiviCRM entities can be referenced in a consistent manner.
System Requirements
Drupal 7 and CiviCRM 4.4 or higher
Install the following Drupal modules and their dependencies:
- CiviCRM Entity
- Entity Reference
- Inline Entity Form
- CiviCRM Entity Inline
- Display Suite
- Display Suite sub-module Display Suite Forms
How To Guide
Read the full set of instructions and screenshots on how to create such an interface for this very real use case on Skvare's blog.
After following the instructions content creators will be able to select, create, update, or delete CiviCRM contacts with ease and assign them as Project Coordinator(s) for the Project nodes! These content creators need not ever see the CiviCRM backend. You can follow the same procedure for CiviCRM Events, and nearly 30 other entities. Cool, yeah?
Have fun with your own specific implementations!
Who are We?
Skvare is a leader in Drupal and CiviCRM integration and project lead for CiviCRM Entity. Contact us to get questions answered and for consultations to make the most of your Drupal and CiviCRM installation.
Comments
Great Post Mark! Glad to see you continue to share the power of transforming CiviCRM entities to Drupal entities!
Hey there,
Thanks for this write up. Noob question. How does this affect your use of webform_civicrm? I am presuming that civicrm_entity_inline allows you to do a lot of stuff that you can do with webform, but that webform offers some extra functionality (payments, etc.) that isn't available here. In your experience, is there an obvious times to use one or the other, or is it on a case by case basis?
Michael
Excellent question.
We use webform_civicrm extensively. CiviCRM Entity does not replace this functionality.
When you want a custom form similar to a profile, the easiest way right now is webform_civicrm. If you integrate CiviCRM data with Drupal pages or functionality in any other way, then its time for CiviCRM Entity.
What CiviCRM entity does do is provide deeper integration with Drupal, making CiviCRM data available as Drupal entities, meaning the data is integrated in Drupal as any other content type/ entity.
CiviCRM Entity is infrastructure, Webform CiviCRM is a piece of specific functionality, building custom forms, similar to Profiles.
This means:
Drupal developers can use the Drupal Entity API make use of CiviCRM in Drupal modules, Drupal FAPI custom forms being only one use case. What it does is attract Drupal developers to CiviCRM, by letting them use the API they already know.
Site builders can use existing Drupal modules that leverage the Entity API such as Rules. Reacting to new/updated CiviCRM data with Rules, creating and updating entities with Rules. Also building Entityqueues, using Search and Facet APIs, among others. 100s of existing Drupal modules can make use of CiviCRM data in this way. Webform_civicrm does not do this.
The blog post describes a way to reference and manipulate CiviCRM data from Drupal content types, and other entities, either using stock Entity Reference functionality, or by making use of Inline Entity Form. Webform civicrm does nothing for you there.
CiviCRM Entity does expose standard add/edit forms for all exposed CiviCRM entities, allowing a separate Drupal native administration interface for add/edit/delete. This allows users without 'access CiviCRM' permissions to manipulate data without accessing the CiviCRM backend.You can also use all the standard Drupal tools for creating custom interfaces to the CiviCRM data. As of the soon to be released 2.0-beta2, developers can use a simple hook to choose which permissions are necessary to view/edit/delete CiviCRM data.
You can use standard Drupal tools such as the "Manage Display" form, create multiple view modes, and Display Suite, to make multiple variations on 'view' pages for all exposed CiviCRM entities. You can use the built in formatters, create your own, organize the order of fields, choose to show labels or not, use Fieldgroup to organize the fields into fieldsets, tabs, vertical tabs etc...
So if you want to display a subset of Contact information, either on the default view page, for example ('/civicrm-contact/1') OR you can render the entity as any of the view display modes in Views, or programmatically.
CiviCRM Entity also integrates the CivICRM data with the Drupal theme system. This allows Drupal front end developers to utilize standard practices in Drupal such as preprocess functions and Drupal theme templates.
You can add Drupal fields to your CiviCRM data for display on these view modes. This gives designers and content creators way more options as to types of data, and the formatting of data to manage and display along with the stock CiviCRm data fields. For example, its a site building task to add a image slideshow, a youtube video, to a contact view page. And we have ways of making these Drupal fields display on the stock CiviCRM contact pages....see Views in CiviCRM Contact Pages
In time, we plan on developing fully native drupal contribution and event registration pages, that are done in the Drupal standard ways, with CiviCRM payment processing OR Drupal commerce integration. We're thinking a "CiviCRM Payment Processor" for Commerce, that allows a standard Commerce workflow, but storing the transaction data in CivICRM and using the CiviCRM business logic. Many thousands of sites use Commerce, many hundreds of dev shops implement and customize against it. Again making CiviCRM much more attractive to Drupal developers and implementers. We want to have a Drupal only interface option, with the standard CiviCRM backend as a fall back.
The basic idea of CiviCRM entity is to provide DEEP integration with Drupal, at an API level, to allow Drupal developers, themers, and site builders to use all the standard Drupal practices and tools, to create their implementations and customizations. We want to take it as far as this: We want it to make it so that the standard CiviCRM backend is almost completely redundant, that CivICRM is a proper Drupal module, and not an oddball. People that know Drupal, need only know Drupal, and not learn a new, foreign interface.
Drupal Commerce is a flexible, powerful, e-commerce infrastructure for Drupal.
CiviCRM Entity is and is heading towards being a flexible, powerful CRM infrastructure for Drupal. We are working to make CiviCRM competitive against the likes of Salesforce Suite, Redhen, etc.....The competition is intense. We're fighting for CiviCRM in the Drupal sphere. It's war. We're passionate about this, warriors for CiviCRM in Drupal. To do so requires that Drupal developers can use the Drupal API and Drupal theme and site building interfaces.
We want CiviCRM to be the defacto standard for CRM in Drupal, as Commerce is right now for Drupal.
Expect continued blog posts with examples, we understand that a lot of the CiviCRM community does not understand.
We have upcoming case studies that also exemplify CiviCRM Entity.
Thanks for asking the question, ask more! I sometimes tend to rant, if I didn't answer you question completely, let me know. We really want people to see the potential, as we see it at Skvare.