

Building a feature using CRM Core profile is easy. In this demo we will demonstrate the step-by-step instruction on how to do it. Please note this is a follow up and more in-depth guide to http://www.trellon.com/content/blog/building-crm-core-feature.
In this demo we will be building an “online petition” feature that allows a website to:
Webform is a popular and powerful data collection tool in Drupal. It can be used to achieve the items that are laid-out above, so why not use it?
To get started, your will need to have CRM Core modules running on your Drupal installation and have the CRM Core Profile module enabled. The easiest way to get started is to grab a quick CRM Core Demo installation profile from github.
You should also be familiar with the Features module and exportable objects. Knowledge of using CRM Core and views is recommended as well.
We will first start by creating a content type called “Online petition”, this content type will hold information about any particular petition.
It will contain the following fields:
We mentioned that we would like to collect the name, email, city and state of the petition signer; that means those fields should exist in the contact type. If they do not exist let’s add them:
In the example above, the “individual” contact type already has both a name field and an email field. It also has a billing address field, but we will create another field for the petition signing address.
The next step is to create a petition signature activity type which we will store the information about the petition signature. We will create the additional fields:
Now we have created all of the components that will store online petition data. We have a content type, a contact type “individual” and an activity type “petition signature”.
The last step in configuration will be to create a CRM Core profile form, which will essentially be “the petition signing form”.
There are a couple of things we would like to customize on the form:
We will visit these 2 issues in the “Additional Customization” section below.
Now it’s time to export everything we have done into a “feature” module.
Now that we have our “feature” exported, we can now implement additional customizations. We will do the following:
1. Permission
We want to introduce a permission so that only certain user roles can view the petition signing form. In this particular use case we don't have a great need for a permission, since we would like to allow everyone including anonymous users to be able to sign our petitions. Since many other use cases will require it, though, we include it for completeness.
<?php
// crm_core_petition.module
/**
* Implements hook_permission
*/
function crm_core_petition_permission() {
return array(
'crm_core sign online petition' => array(
'title' => t('Allow online petition signing'),
'description' => t('Ability to use petition signing form on online peition pages'),
),
);
}
?>2. Customize UI
The aforementioned customization on the form needs to be performed. We would also like to show the petition form on the petition content itself.
<?php
/**
* Implements hook_node_view
*/
function crm_core_petition_node_view(&$node, $view_mode) {
if (!user_access('crm_core sign online petition')) {
return;
}
// let's embed the petition signing form on the online petition content itself
if ($node->type == 'online_petition') {
$crm_core_profile = crm_core_profile_load('petition_signing_form');
if (!empty($crm_core_profile)) {
module_load_include('inc', 'crm_core_profile', 'crm_core_profile.forms');
$node->content['crm_core_petition_form'] = drupal_get_form('crm_core_profile_entry_form', $crm_core_profile);
$node->content['crm_core_petition_form']['#weight'] = 999;
}
}
}
?>The above code simply embeds the petition signing form we have created earlier into the petition content.
<?php
/**
* Implements hook_form_FORM_ID_alter().
*/
function crm_core_petition_form_crm_core_profile_entry_form_alter(&$form, &$form_state, $form_id) {
$profile = $form_state['profile'];
// making sure we are on the correct crm_core_profile
if ($profile['name'] != 'petition_signing_form') {
return;
}
// adding css class to the form for additional style customization
if (empty($form['#attributes']['class'])) {
$form['#attributes']['class'] = array('crm_core_petition_signing_form');
}
else {
$form['#attributes']['class'] += array('crm_core_petition_signing_form');
}
// Change the form button value and hide some of the address components
$form['submit']['#value'] = t('Sign the petition');
$form['field_contact_address'][LANGUAGE_NONE][0]['street_block']['#access'] = FALSE;
$form['field_contact_address'][LANGUAGE_NONE][0]['locality_block']['postal_code']['#access'] = FALSE;
$form['field_contact_address'][LANGUAGE_NONE][0]['country']['#access'] = FALSE;
}
?>We also do some UI customization such as adding CSS class to the form and hiding parts of the address field we don't need (street, locality, and country blocks).
3. Misc.
There are other things we would like to do such as setting a default value on the petition signature activity.
<?php
/**
* Implements hook_crm_core_profile_activity_alter().
*
* We are just setting some default value to the crm_core_profile form in the activity data container
* the $form here refers to the $form['activity'] data container from the original crm_core_profile form
*/
function crm_core_petition_crm_core_profile_activity_alter(&$form, $profile_name) {
if ($profile_name != 'petition_signing_form') {
return;
}
// since we are embedding the online petition form in the content itself, we can get the content information
// as well
$node = menu_get_object();
// we are just setting the reference (association) of the activity back to the petition content
$default_value = sprintf('%s (%s)', $node->title, $node->nid);
$form['field_crm_petition_reference'][LANGUAGE_NONE][0]['target_id']['#default_value'] = $default_value;
}
?>All done in less than 100 line of code. We can now test our feature.
Now let’s create a simple report to show how many people have signed a particular petition as well as all the petition signers for a petition. We will also create a block counter to show the number of people who have signed the petition.
We will be using views and views data export module to achieve our goal.
Now that we have a general report showing a list of petitions created online, let’s create the petition signer report for an individual petition.
We now have a pretty good report showing all the signers of a petition as well. We can also create a petition signer count block and place it on the petition content:
Lastly, let’s update our feature with the report and other new components created.
That’s it, now you have a fully working online petition feature that can be deployed on any Drupal website with CRM Core and CRM Core Profile enabled.
Let’s suppose that the following additional requirements have come in:
How would you go about implementing these additional requirements? Post your ideas in the comments, and we'll be happy to discuss them with you.
| Attachment | Size |
|---|---|
| crm_core_petition-7.x-1.0-dev.tar | 67 KB |
6 Comments
That is really interesting to
That is really interesting to see how the pieces can fit together. However, taking a step back this seems like it shouldnt require this much code (or any really) to complete something of this nature. Are there additional things planned that will make this easier and require less/no code?
Hi, Short answer is yes.
Hi,
Short answer is yes. There are patterns of building simple applications that emerges that eventually will going to the platform that allows creating features with even less or no code at all.
Hello, You explain why web
Hello,
You explain why web forms doesn't make much sense to you use. However, what about entity forms? It seems like entity forms would remove the need for the coding but I am not sure how well it integrates with your system. Can you please provide a little insight on that option? Cheers Kevin
I haven't tried it, but I
I haven't tried it, but I don't think it would take much to integrate. Submissions would be associated via submission uid and the related crm core contact for the user. This is something you can build in a view and display as a tab on each contact (if that's the sort of integration you're looking for). Any other reports, you would also need to build (maybe with views) to support matching users to contacts. I.e. entityform would not know about how a user relates to a contact in the crm, so any data on the contact you want to display or export would need to perform that lookup. Hope this helps.
Anonymous users are another
Anonymous users are another kettle of fish. E.g. you would want to collect an email and name on the form and then create a contact based on those fields on the form - this is not nearly as easy. This is something that crm_core_profile module attempts to handle, but doesn't deal with the case of attaching profile fields to another form (or entity). We're working on it :)
Hi, Am using CRM Core now.
Hi,
Am using CRM Core now. However I need to create a form whereby I have multiple child data (1-to-many relationship), e.g. a main participation form, with multiple participant names and contacts under the same form.
How could I do that?
Regards.
Post new comment