CiviCRM and Drupal Diary - Week 1
This is our multi-article series on integrating CiviCRM and Drupal. Make sure you've read the prologue, introducing the topics to be covered.
Our Choice to use Drupal along with CiviCRM was a difficult one to make at the onset of our project. In this section I would like to explain:
- Project Conception
- Requirements Gathering
- Software Evaluation
Our client approached us with some very basic requirements. As long as we stayed within the requirements, we were free to choose whatever technology we felt would deliver the proper solution.
Project Conception
Our project was to be a membership website for a not for profit professional association. The site was to have two primary components with multiple sub sections:
- Front end - for members and the public to interact and utilize services as well as promote the association to increase overall membership
- Back end - for administrators and staff to manage membership and functions of the association
Requirements Gathering
The actual requirement were very flexible at the start. Nothing was set in stone. The existing site was a set of static pages that were updated via MS Frontpage (Yes, in 2010 there are still websites using Frontpage to update and edit).
They had to be able to edit their own content (any CMS system could do for this). But they also wanted to add value for their members. Exclusive access on the website could add value as would the ability to register for events online. As we brain stormed with our client for other opportunities we realized that online membership registration as well as online payments were a great convenience that would also add value.
Part of the challenge with adding this functionality to a website is synchronizing the data with the existing offline membership system. In this particular case an MS Access Database was being used to track membership.
The current setup that the organization uses is as follows:
- 3 full-time staff
- MS Access database for managing membership
- Static website for the public. All static content.
- External email system with it's own mailing list (imports taken from Access).
- Payments are all handled manually.
- Quickbooks used for accounting.
The idea of CiviCRM was presented to allow several key benefits:
- Online Membership payments
- Online Event registration & payments
- Decentralized Access to membership data
As we moved forward in the process we realized how beneficial this system would be in that extra features would include:
- Online membership Directory - editable by members
- Integrated emailing system
- Event tracking - Who is registered, mailing label/name tag export
And more...
All of the processes are either currently manual (such as creating a list for name tags) or not done at all (online membership directory).
Software Evaluation
- Wordpress - We are familiar with it, ease of use for the end user and lots of plugins. However, it is not as easy to develop in and we did not find any full conversions that would offer the membership functionality that we needed.
- Dot Net Nuke (DNN) - We looked at DotNetNuke because members of our team have previous extensive experience working with this system. Although it is open source, we really did not want to go the ASP .Net route with this project and again there were not any ready made modules available for what we needed.
- Joomla - Joomla integrates with CiviCRM (like Drupal) but it does not have the robust hook system that Drupal has, which enables data to pass from CiviCRM's database to the CMS database. It also does not have as strong of an ACL system as Drupal, and access control was important. We also find that developing in Joomla is more difficult that using Drupal.
In the end, after several weeks of testing Drupal & CiviCRM we decided that this was the best choice for our current project.
Read more in our next article:
Week 2 - Project Schedule, Drupal and CiviCRM Installation & Comping
Comments
Post new comment