Show your Concern

Project goals

The primary goal of the project was to redevelop an existing website built in a bespoke PHP application, to run on Drupal and integrate with Concern's other Drupal sites. The larger project, which is still under development, is to build a new online fundraising platform, developed from the ground up, making the most of all that Drupal 7 and Drupal Commerce have to offer.

Obviously, Concern’s project objective was to increase public revenue through the new site.

Requirements

The main requirements for the site were as follows:

Event registration

The primary purpose of the site is to allow users to create and register for events. On the one hand there are 'official' events that Concern organizes. These events typically have a registration fee associated with them which users are required to pay at time of registration. On the other hand, users are able to create their own events. These could be literally anything from a sponsored swim, to a sponsored code sprint. These are free to create, and can be created by anyone.

Techie note: Event registration is primarily handled by Registration Entity, Drupal Commerce, and Commerce Registration. The registration forms are strung together using a combination Formflow and custom Commerce checkout pages and panes.

Personal fundraising pages and profile pages

For each event that a user registers for or creates, they get given a personal fundraising page. This page shows details of the event, along with a personalized message, a summary of any funds raised, and supporter comments. These pages can easily be promoted through Facebook and Twitter in order to tell friends and family about them.

User's individual fundraising pages, and a profile page, essentially pull together and summarize all of their fundraising activities across all events that they are taking part in.. Users are able to customize their profile page with a personal message, specify which events they want to feature on the page. The profile pages can also be easily shared on Facebook and Twitter.

Techie note: Personal fundraising pages are created by Rules, as a result of a user creating or registering an event. Many of the components on the fundraising pages are created as Views content panes, and custom Views field handlers. The components are pulled together using Panels.

Donations/sponsorships

Once a user has registered for an event, has their own fundraising pages up and running, and have told all their Facebook and Twitter contacts about them, they are ready to start raising money for Concern! Donations and sponsorships can be collected directly through the site or offline and returned to Concern by other means. If a user collects funds offline, they are able to add these to their fundraising total to ensure that the totals shown are an accurate representation of all funds raised both online and offline. When people donate online, they can leave a comment for the fundraiser, which can optionally be displayed on the user's fundraising page.

Techie note: Drupal Commerce handles the donation process. This checkout flow is somewhat customized from the stock Commerce checkout process - It uses a one page checkout, and users are able to modify the price of the donation product right there on the checkout page. Drupal Commence as a framework is flexible enough to make this possible. For this, there is a custom 'donation' product type and a custom line item type. The comment facility is provided by the Commerce Fieldgroup Panes module. The comments themselves are Field Collections, and Entity Reference fields tie the whole lot together.

Newsletter subscriptions

Users are able to sign up for newsletters through the site which enables Concern to keep their supporters up to date with exciting new events that are being planned! The newsletter subscription process is very specific to Concern's requirements, which is simply to collect the registration data, and export it to another external system where newsletters are managed.

Techie note: Entity Construction Kit was used to create a custom Entity Type, giving the ability to easily create new newsletters, each with their own fieldable sign-up form, and each automatically integrated into the system-wide data export system (see below)

Data exports

All data collected through the site is consolidated in a simple batched download system. Whether the data is for user registrations, event registrations, donations, newsletter or newsletter subscriptions it all feeds through to a central data export control panel. Data is batched up into regional daily downloads and these are exported by staff at Concern and imported into other external systems.

Techie note: Data export requirements are very specific to Concern's requirements. To facilitate this, CTools-based data export plug-in framework was developed to provide a central data export system that other site components can plug into. The actual data exports are generated by Views, and exported using Views Data Export. Several custom Views field handlers allow for the exact data requirements to be easily met by Views.

Hosting

Concern has its own Aegir and Git servers which we set up some time ago and manage, as well as dedicated development and production servers. We also integrated our Jenkins Continuous Integration system into Concern's Aegir servers to automate deployment and testing. All servers are Rackspace Cloud Servers set up with everything required to power high performance Drupal sites – Nginx, FastCGI Cache, APC, Redis. Much of this is handled by the excellent Barracuda server provisioning system.

General approach

We have been working closely with Concern over the past few years, and during that time we have helped them migrate sites from Drupal 5 to Drupal 6, migrate non-Drupal sites to Drupal, and launch a great number of fundraising campaigns through concern.net. This project was slightly different though, because we were not just building a new Drupal website for them. Concern already has a bunch of sites that run on separate Drupal installs. These are all very well defined in their own right through installation profiles, with deployment process tightly controlled through Aegir. But, at the end of the day they are separate sites that have evolved over the years.

Anyone involved with Drupal knows that over the past few years the landscape has changed dramatically. There has been an abstraction from Nodes to Entities, the introduction of Features and code-driven development workflows, a migration to Git, a full test suite for Drupal Core, and a general maturing and standardization of development practices through the use of tools such as Aegir and Drush. Drupal has worked itself up to the enterprise level, and is well positioned for continued future success.

Our approach for this site-build was to combine its own development into a larger Drupal 7 redevelopment project, and build from the ground-up a fundraising platform - as opposed to just another fundraising site. We looked to develop a set of reusable features that can be deployed to multiple sites and customized on a site-by-site basis. The means that we can ensure a consistent experience for content editors from one site to the next, a standard set of functionality and site structure for users of the site, and a consistent set of data reporting/export tools for other users within Concern's organization.

Development approach

This platform-based approach presents a number of challenges because while all sites need to share a common set of features, and to some degree a consistent user experience (more so from a site admin point of view, but also to some extent from a site user's perspective), not all sites are the same.

This means that when developing features for the site, we need to be careful about which components are generic, and which are site specific, and we need to ensure that this is properly captured in the platform's codebase.

With a number of developers working on the project at any one time, a purely code-driven development approach becomes a necessity. As the platform currently stands, there are some 30 unique 'feature modules' using the Exportables/Features system as a base, and enhanced or extended with custom code where needed. As the platform continues to be developed to support concern.net, and other Concern sites, this number will grow somewhat. Examples of some feature modules related to the blog part of the site are:

cw_blog:
The blog feature allows users to create and manage multiple blogs.

cw_blog_comment:
Enables comments for blog posts using the standard Drupal comments system.

cw_blog_featured:
Provides the ability to 'feature' individual blogs and blog posts so that they can be highlighted on the site.

cw_blog_yourconcern:
Customizations specific to the Show your Concern site.

As you can see, while the blog functionality is generally thought of as a single feature from a user perspective, in code this is broken down into several distinct components that can be individually enabled, disabled, extended and customized according to a site's specific needs. Other features, such as events, fundraising pages, the commerce framework and the newsletter subscription system are also defined in code and broken down in a similar way.

Continuous integration and testing

We use Jenkins, Aegir and Drush Make to provide a continuous integration-style build-system. This is set up to trigger a new platform build from the project's Drush Make file whenever a change is detected in the Git code repositories, import the new platform into Aegir, then triggers an Aegir platform migration job and runs a Selenium-based test suite against the updated site. There are separate code branches for dev, stage, and production and separate automated platform builds running for each environment.

This is a process that we learned about from some of Mig5's work, and this was the first time that we had used these processes. It was so successful that we have since updated many other sites that we manage to use similar processes.

Timeline and project management approach

When the project was originally discussed, the idea was to try to integrate it with the Drupal 6 version of concern.net, which uses CiviCRM for donations. Some initial groundwork was started in that direction, but the difficulties that we faced trying to bend CiviCRM to make it meet the demands of this site quickly made us realize that was the wrong approach.

Our vision of a unified Drupal 7 based fundraising platform and the need to standardize things and move to a fully code driven workflow convinced us to push for a fresh start, and a tighter integration of this project into the wider Drupal 6 to Drupal 7 development project which was being worked on alongside this project. Better to start off in Drupal 7, the right way, than to try and make things work in Drupal 6 only to have to upgrade them at a later date.

Pivotal Tracker was used as the primary project management tool throughout the build. We had weekly meetings with the client and other project stakeholders to hash out any issues and keep everyone up to speed on the development progress. We always tried to recommend best practices and ensure that we got things done in the 'right' way. This meant that the timeline needed to be slightly longer than originally requested from the client, but the end result is much better for it. We can now look forward knowing that we have a solid foundation in place to build upon as more of Concern's sites are upgraded and migrated to Drupal.