Notes on using RedHen for a membership site

I’ve been doing membership sites for some years in Drupal 6, using a rather messy combination of CCK fields, User Role plus Ubercart Expiry Date to track membership. With the upgrade to Drupal 7 I hunted for a better solution and eventually decided upon the RedHen suite of modules. They provide lightweight CRM functionality, integration with membership and registration systems, and good compatibility with Commerce.

The biggest drawback for me was lack of available documentation. There is some out there, at ThinkShout and elsewhere, but I was struggling to find out all I wanted to know. Having now spent weeks in the depths of RedHen, I thought I would do a write up. Experienced RedHen users will not learn anything new, but my hope is that it will be of value to those approaching RedHen for the first time.

This is a long way short of a complete tutorial, and assumes a certain amount of common sense about which RedHen modules to enable etc.

My requirements

For this first roll out of RedHen, the requirements were simple:

• Two types of CRM contact: member and non-member
• No user registration: contacts added by membership administrators only
• Automatic lapsing of memberships
• Events registration system

Contact types

The first point to get really clear in my head was that RedHen entities are a different type from nodes. Once this is understood it is reasonably straightforward.

First one has to configure things at admin/config/redhen/crm. I needed to connect RedHen contacts to Drupal users. I also wanted to enable creation of a contact during user registration, not for use by users but to give membership admins one form when creating a new member.

I created the two types at admin/structure/redhen/contact_types. Adding required fields is no problem. For the membership number I used a Computed Field which assigns the next highest membership number.

Memberships

Each RedHen contact can have one or more membership records, i.e. set of data about type, start date, expiry date of membership. I created the type at admin/structure/redhen/membership_types/manage, defining the user role to be granted when a membership of this type is created.

I then wanted, when creating a new RedHen contact of type member, to automatically create a membership record with start date of today and expiry date of next annual end-of-membership cycle. I created a Rule which fires on contact creation creates a new instance of the RedHenMembership class, grabs the expiry date from the body of a node which is editable by membership admins (so they have control) and saves the new membership using the redhen_membership_save() function.

Renewals

I wanted it to be easy for a membership administrator to renew membership by clicking a button. I created a flag which shows by each membership on a searchable memberships view page. When clicked, the flag triggers a rule which renews membership. If the membership being renewed is active, just the expiry date is updated. If the membership is expired, a new membership record is created with start date of today.

Misc RedHen issues

One problem I had was that the US date format is hardcoded into the RedHen modules. To show European format in Views etc, I had to hack the modules in two or three places. Not ideal.

Although RedHen natively allows you to call different contact types via the url on the user registration form, I had to add some code to my custom module to achieve the same thing via the admin/people/create route.

Switching contact type

I needed to be able to switch a non-member contact into a member contact. I discovered this was possible through the Bundleswitcher module. It is basic, but it works.

Registration for events

Integration with the Entity Registration module is enabled via the RedHen Registration sub-module. It works out pretty well, but since I wanted to use my own View of registrations, rather than the one built in, I had to hack the module’s menu callback a little.

Since anon registration is offered as well as registration by logged in users, I discovered that email addresses of registrants are stored in different fields in each case. But broadcasting uses all emails. I was able to provide just one column of email addresses in the View via a custom text field which draws on one or other of the available email fields.

Migration of data

I had nearly 2,000 records to import. This was achieved using the Feeds & RedHen Feeds modules, with some customisation in a custom_migrate module to map certain old ids to the new data structure. The Feeds Tamper module was particularly useful.

Conclusion

There is much more that could be written, and the above is just some jottings which may be helpful to others doing something similar. Feel free to be in touch with me if you want more details. All in all, I am pretty satisfied that I made a good choice in using RedHen for this particular purpose.