How to Create A Simple Conference Site with Drupal 7, Signup, Regular Expressions, and Rules to Filter Attendees by Email Domain

The Drupal Conference Organizing Distribution is a great out-of-the-box solution for quickly setting up a conference site. If your conference site needs sessions, to sell tickets to the event, you want built-in management, and you are comfortable with Ubercart, you can save yourself a lot of time and work by using C.O.D.

For a recent client though, they didn't need sessions, but wanted to limit attendee registration to only attendees from certain email domains. The conference organizers wanted to allow attendees to also register from other email domains, but maintain approval over these accounts before they were allowed to register.

C.O.D is the Conference Organizing Distribution's short-name, and it uses the signup module to manage and create events and allow attendees to register for these events. It also harnesses Ubercart for attendee registration and checkout and can allow you to charge and process fees for your conference. I didn't need this functionality and C.O.D. doesn't include the ability to limit attendees by email. Since I also didn't need sessions, or the scheduling functionality included with C.O.D. either, I decided to design the site from scratch using Drupal 7, the Signup Module, and the Rules Module. Sometimes it's simpler and faster to create a new site, rather than pull an existing distribution apart for only the functionality you need. This was one example where it would have taken much longer to modify C.O.D., which is a Drupal 6 distribution, than it did to create a new site using Drupal 7 and two contributed modules.

Signup

Installing and configuring the signup module allowed me to create events, and then allow users to sign up for these events. Signup also allow you to track attendance, and cap the number of attendees for your event. I also created a new role called Conference Organizer, so that an administrator with my client's organization can create their own events and manage them. You might also recognize the Signup module if you have ever used groups.drupal.org to sign up for events.

Rules

If you haven't used Rules, or aren't familiar with it all, it allows you to basically set up arbitrary conditions based upon certain criteria, and then trigger events if these criteria are met. It essentially replaces the Trigger Module that is found in Drupal Core, and extends it with even more functionality.

The next requirement was to limit attendee registration by an email domain. This is where rules became indispensable, since it also allows the use of Regular Expressions. This is what I needed to filter registration by email.

Essentially, I needed to allow anyone to register on the site, but only users using a certain organizations email domain or those that were approved and verified to be able to signup for the conference itself.

I used Drupal's powerful permissions system and created another role for approved attendees, and granted them the ability to sign up for events. This would allow only approved users to register. Since registrants using the allowed domain could be easily and automatically verified, rules could be used to promote their status to this new role automatically.

Adding a New Rule

  1. After installing and enabling rules, visit /admin/config/workflow/rules and click Add New Rule.
  2. Give it a name, and an optional tag to help you organize it later if you are going to be using multiple rules on your site.
  3. Now, select the event to react on. For this example, I am using After saving a new user account.

Create A New Rule Image

You'll now be presented with your reaction to edit and you should see your event listed under the Events heading for your new rule.

Editing a Rules Reaction Image

Adding a Condition

You now need to add a condition. To limit email registration, we need to add a condition. Select Text Comparison and you'll be guided to the data selector section. Data selectors will be familiar if you've ever used Tokens and allows you to select individual fields to compare. For email comparison, well use account:mail as our data selector. You can type this directly in the form, or use the drop-down selector next to Data Selector

Regular Expressions

For the matching text value we are going to use a regular expression.

A handy tool to use when writing regular expressions is RegExr. If you aren't familiar with Regular Expressions, they are essentially text evaluators that allow you to compare text against a set of matching criteria and evaluate it. This isn't a tutorial on the use of regular expressions though, so I will just provide the expression I used to filter email domains and you can modify as you need to.

To filter by a .org or .com email domain, I used this regular expression:

([\w-_\.]+)@([\w-_\.]+)(org|com)

Next, skip down to the comparison operator and for the value, select regular expression.

Save your condition and you will be redirected back to edit the reaction.

Add an Action

The last step is to add an action to this rule reaction. We'll promote the registered user to a role that allows them to actually sign up for events, since their email meets our criteria. Using Drupal's core user functionality, I chose to require email validation before activating their account. This way, users have to enter a valid email address, and they receive a confirmation at this email address that they need to click to validate their account.

From the rules reaction page, click Add action for your rule reaction. The action we'll be adding here is Add user role so that we can automatically promote our registered user.

Add a user role image

More Power for Rules

If you find you need even more power on top of Rule's already powerful workflow, you might want to take a look at the Conditional Rules Module. This module extends rules to include conditional branching and if, while, and case statements.

I also wanted to automate the process as much as possible so I added some additional actions to send email notifications. When a user registers without using one of the approved email domain names, rules sends an email to the Conference Organizer and notifies them that there is an account pending approval.

User Profile Information

I added some additional fields to the user's profile where they can add a sponsor's email, who can be also be verified and used rules again with my previous regular expression to validate whether or not the user had entered an email address for the sponsor that met the required email domain. I used the Field Validation module to automatically validate the sponsor field even before the user was allowed to submit the form. This helped ensure they wouldn't need to return again just to enter information needed to validate their account in the first place.

To not limit the user's ability to register, I also used rules to send them a reminder email immediately if they didn't enter the proper information. This way, they can then return and edit their account with the proper information.

I also added an additional rule that will automatically notify users who didn't originally register with the required email domain that their account had been approved after a an organizer promoted them.

With the user profile fields growing, the registration form became quite lengthy, and some fields didn't apply to all users. For instance, if a user registered with an approved email domain, it wasn't necessary to require sponsor contact information from them and these fields were irrelevant.

I used the Conditional Fields module to hide these irrelevant fields, unless it was required. If the user registered with a non-approved email, then the additional sponsor email and contact information was revealed. This hid some of the fields on the user registration form unless they were needed.

The basic user workflow ended up looking like this:

  1. A user creates an account using an approved email domain.

1.1. We are basically done. Their account is approved and they can register for the event.

  1. A user registered using a non-approved email domain.

2.1. The Field Validation module checks that the sponsor field they entered conformed to our regular expression criteria. If it didn't they were shown a message and told to enter the information.

2.2. If they did enter sponsor information properly, but left things like sponsor name and organization blank, they were sent an email reminding them to return and complete this information.

2.3. After registering, a conference organizer is notified that a new user needs to be verified.

Ideally, this multi-step user registration could have been eliminated with a custom module, but this would have required some custom code. The client needed this site up and running in a matter of days and I didn't have the luxury of spending the time on it to write the code to do this. I couldn't make the sponsor information a required field, since some of it didn't apply to users who registered originally using an approved email domain.

While the user experience could be better, functionally I was able to complete the requirements for the site registration and validation using Drupal Core and some very useful contributed modules.

Conclusion

This post isn't meant to point out any deficiencies with C.O.D. at all. In fact, if your needs are pretty typical of most conferences, you can save yourself a good deal of work and configuration by using C.O.D. instead of reinventing the wheel on your own. You could have a conference site set up and working literally in a few minutes along with roles and permissions already in place.

My particular needs this time didn't use a lot of C.O.D's. functionality and with two contributed modules, Rules and Signup, I was able to rapidly launch a Drupal 7 conference site.

Regular expressions can make your head hurt as well sometimes, and I'll be posting a review of O'Reilly Media's new book, Introducing Regular Expressions. I recommend it as a guide to get you started using regular expressions.