Website redesign and membership management with CiviCRM 1.7 and Drupal 5.2
Civi integration included:
- Profiles for custom user registration and membership information including the law school name.
- CiviContribute,CiviEvent, and CiviMember to handle donations, event registration, and membership renewal
- Import of legacy membership data and creation of Drupal user accounts for all legacy members (around 1400).
- Membership listing (using the API, not profiles)
The technology choices of CiviCRM and Drupal were appropriate for the requirements and organizational structure. I think the implementation will be successful overall. However, we did hit a few roadblocks with the integration pieces:
- In Civi 1.7, payments using Authorize.net are difficult to test. I think this was ironed out in 1.8, but we didn't have enough time to mess with the upgrade. We still have intermittent problems that are nearly impossible to track down--could be something timing out as well as duplicate records being created during the payment process.
- For the custom membership listings, we used the CiviCRM API, The API has undergone a bunch of changes and was not as straight forward (and well documented ) as need be. For example, the location syntax is confusing for contact API searches. I was never able to return the primary location of a contact without specifying an exact location type.
We need to sync membership status with Drupal Roles. We did this using custom code in conjunction with smart groups and the Drupal user import module. This worked well for migrating Civi Contacts to Drupal users. Although, this process is not necessarily easily understood by non-technical staff.
Performance is adequate, but not great. Hosted at A2Hosting.