Each year, thousands of people around Ireland join Concern Worldwide in the Concern Fast. During the Fast, people give up food for 24 hours and raise as much money as they can for some of the world’s poorest people. One aspect of this years campaign is an online element, where registered fasters can get their own online profile page. Through this, they are able to take sponsorships and return any money that they have raised offline directly through the site.

Kirkdesigns built the Concern Fast website with Drupal 6, CiviCRM, a rather large handful of community contributed modules and of course, a selection of custom modules to facilitate the specific needs of the campaign.

The main site

The homepage is built using a custom Panels 3 layout with a couple of dedicated content types that are used to build nodes to drop into the various panel areas. The menu on the right is built from a standard Drupal menu, with customised templates that allow each menu item to be styled with an icon as well as allowing the description for each menu item to be displayed under the name.

Landing pages

Most of the other landing pages are built from standard Panels layouts. The Menu Node Views module was used to enable Drupal Menu items to be selected and used within Views. This made it possible build a view out of a Drupal menu that could be output as a grid and dropped it into a panel. This makes maintenance of the landing pages fairly simple, as the content is primarily driven from the Drupal menu system.

The blog

The blog is a public Organic Group of which several of the Concern content team are members. This allows them to log in and post new blog articles as they please. Having the blog built as an Organic Group meant that user permissions could be fine grained within the context of the blog.

Support site

Organic groups was also used for the campaign's support team. This gives them a central place where they can access documentation (built using a Drupal Book) as well as providing a user search interface (built with an exposed views widget), and a CiviCRM contact search widget. It also contains a number of quick links to administration items that they frequently use (again, another standard Drupal menu). The group is a closed, private group, meaning that membership is handed out by the group administrator only, and that the content of the group is inaccessible to the general public.

Other pages

Other general 'content' pages are simple static nodes with a CCK ImageField and an ImageCache preset to give the images rounded corners and a consistent look. The user search facility was built with Views and an exposed filter widget and of course, some custom theming.

User profiles

User profiles are a major part of the Concern Fast website and they have been customised quite considerably. Again, Panels was used to replace the standard user profile pages and provide an advanced means of laying them out as desired. Several custom Panels plugins were developed to hook into various parts of CiviCRM and make its information available on user profile pages. For example, the donation barometer uses the CiviCRM public API to get details of sponsorships for each user. Likewise, the Sponsor Comments section is another custom Panels plugin that gets its data from CiviCRM.

The registration process

The user registration process has also been customised somewhat to provide a smooth end user experience and better integration with CiviCRM than you get out of the box.Logintoboggan allows users to log in using their email address as well as user name, as well as allowing users to select their password upon registration, whilst still requiring them to validate their email address before gaining full access to the site. Since users were to be able to login with their email address, it was decided that usernames would be automatically generated upon registration based on the user's name. This was done in a custom module using hook_nodeapi.

The activation process

A 'returning user activation' element was also built for this campaign, allowing Concern to send out personalised emails and letters providing previous year's fasters at the start of the campaign, containing a unique activation URL from which they could reactivate their account from previous years. Essentially, this meant importing several thousand existing contact records into CiviCRM, generating and reserving a username for each one, and building a multistep account activation form where users could confirm (and alter if necessary) their personal details and set up a password for their new account.

Profile setup wizard

The Profile Setup module is used to provide a 'profile setup wizard' to newly registered users. On confirming their email address they are taken directly to a multi-step form, guiding them through the process of customising their user profile. This includes setting their own personal greeting, their donation target and profile picture. Most of this information is stored in a Content Profile node, including the user profile picture which is a CCK ImageField with a CCK ImageField Crop widget to allow users to crop their profile picture whilst uploading. A custom snippet adapted from here copies the image from the CCK field to Drupal's native user profile picture, allowing it to be used where and when a standard profile picture can be. Unique Avatar ensure that profile pictures are not still cached once they have been changed by the user and ImageCache Profiles allows the profile pictures to be displayed using ImageCache profiles - rounding the corners and presenting them in a consistent fashion across user profiles.

Data synchronisation

All of the above was actually small fry in comparison to the work that went into the backend. Concern are a very well established company, with a complicated infrastructure and well defined internal processes and needs. The website would be little use to them as an entity by itself and integration was needed with other internal systems.

Since CiviCRM was being used to capture user data as well as handling donations and sponsorships, this data needed to be moved from there to other internal systems. CiviCRM provides a fairly decent hook specification, making it possible to hook in at appropriate points, grab the data and send it via a SOAP web service to the required internal systems. This is done during the registration process, whenever a user updates their contact details, and whenever a donation or sponsorship is made through the site.

Not only is the CiviCRM data synchronised to another system, but the synchronisation process is actually a two way process, allowing the data to be modified on the external system (which their telemarketing team use as their interface to the data) and have any changes used to update the data directly in CiviCRM. This means that user data can be edited at either end and still be kept consistent. Services were also built allowing the external system to trigger certain events on the website such as the sending of a password reset email, or resending a welcome email.

Modules Used

Almost 150 modules were used in the construction of the site. The most important of these are listed below:

• CCK - for building the custom content types.
• ImageField, FileField, Image API and ImageCache - for adding images, documents and other resources to the site.
• Views - used to build numerous content listings and layouts throughout the site.
• Panels 3 - used to build a number of non-standard layouts, including the front page and other landing pages.
• Organic Groups - to build a blog which multiple people could contribute to, as well as a private area for members of the campaign's support team.
• CiviCRM - to store customer data and process donations and sponsorships.
• SOAP Client - to synchronise data with other internal systems.
• Webform - for building custom order and contact forms.

Other modules include Pathauto, WYSIWYG, AddThis, Better Formats, Google Analytics, XML sitemap, Secure Pages, URL Alter, Menu Node Views, Unique Avatar, Taxonomy Image, Page Route, Nodewords, Custom Breadcrumbs, Tagadelic, reCAPTCHA, Rules, Remember Me...

Bugs and patches

As with any Drupal project, building the actual site was only half the story. Most of the time was spent researching, bug fixing, and developing custom code. For reference, here is a list of Drupal bugs specific to this project (My full bug tracker on drupal.org is now at around 30 pages – that is about 750 individual bugs!) that I either reported, patched or helped get patched:

• New access setting 'administer node override options'
• Return-Path overwritten by the PHP mail() function
• "Parsed JavaScript file" message clogs up watchdog
• Regression: Site e-mail address can't state the sender's name
• Account category printed on screen
• Button broken due to fix various problems when using form storage
• Exclude from display on some nodes
• Provide a mechanism for other modules to indicate an account is already validated
• Menu item access restriction

And, the same goes for CiviCRM – which also has a very active and responsive developer community. Big thanks to Donalad Lobo (dlobo on #civicrm) who always seemed to have the time to answer my questions:

• Add 'message' field to personal contribution page (pcp) contributions
• Drupal path prefix for multilingual sites should be retained throughout CiviCRM
• Patch HTML_Quickform to add optgroup support for select dropdowns
• Add payment processor for Realex
• Ability to use Drupal's watchdog for for CiviCRM error messages
• Recent items block (drupal) should not show if empty
• Better credit card type matching (switch/maestro)
• UK 'State/province' list contains mixture of counties and large towns
• Profile embedded in Drupal user registration page should use strict matching
• Full text Search block does not work outside of CiviCRM
• Add Do Not SMS communication preference option
• Unnecessary restrictions for custom data field values
• Ensure that financial details related to a contribution details are available in hook_civicrm_post
• multiselect views filters do not make default filter type selection

Performance

The website runs on a dedicated server with 8GB ram and is powered by NginX and fastcgi – much better than Apache/mod_php. The database also runs on a dedicated server and both machines are connected with a fast Ethernet connection.

The standard Drupal database cache was replace with memcached using the Memcache API and Integration module. This provides a substantial performance boost to the site for anonymous users and greatly reduces the load on the Database. APC was also used as a PHP op-code cache.

Whilst working on the performance of the site, I used ab on yet another machine, connected directly to the web server via fast Ethernet to perform benchmarks for each step of the process. A summary of the results, which can be seen below, clearly show the improvements gained for each step of the process.

no caching
Concurrency: 2
Throughput: 1.4 req/sec
95% response time: 1845ms

Drupal Page caching (database)
Concurrency: 5
Throughput: 22 req/sec
95% response time: 308ms

Drupal Page caching + memcache
Concurrency: 10
Throughput: 29 req/sec
95% response time: 475ms

Drupal Page caching + memcache + APC
Concurrency: 50
Throughput: 95 req/sec
95% response time: 418ms

By using a combination of Memcache and APC, the overall responsiveness of the site was dramatically improved, as was its capacity to perform under a heavy load.

Drupal's database logging was also replaced with logging via the Syslog which also helped to greatly reduce the number of database queries per page, whist still providing much needed logging. PhpLogCon is used to parse, display, search and filter the syslog logs, which is far superior to Drupal's internal watchdog anyway. And, a single CSS sprite was used for most of the icons on the site, greatly reducing the number of http requests per page. CSS aggregation, JavaScript aggregation and JavaScript minification (using Javascript Aggregator) were also employed to help improve load times.

Tip: If you want to improve the performance of your sites, join the High Performance group on drupal.org. There is wealth of useful information, and plenty of experts ready to answer your questions.

Summary

Another client site added to the Kirkdesigns portfolio, a happy client, and a pat on the back for Drupal, which continues to prove itself as a world leading CMS solution. It's extensibility, flexibility, huge user base and active community make it suitable for almost every imaginable web based application . As always, I learned a huge amount on the way, most of which can of course be applied to future projects.

About Kirkdesigns

Kirkdesigns is the company name for Tom Kirkpatrick, a freelance web developer from Oxford, UK – currently living in Dublin, Ireland. I hope you enjoyed reading this case study.

Drupal version: Drupal 6.x