As part of the Google Summer of Code, I began work on getting CiviCRM and the upcoming Drupal 8 working together nicely. I made an update about midway through and it's time for another update. I had separated the project into a number of milestones. Phases 1, 2 and 3 dealt with varying aspects of the core CiviCRM module functionality. This work has largely been completed and there are pull requests pending into CiviCRM core, though the front end user experience is still a bit rough (for example, the CiviCRM menu bar doesn’t sit well alongside the Drupal menu). The installation process is quite different with Drupal 8: civicrm now installs as if it were any other Drupal module — simply by clicking enable. It's no longer necessary to use the CiviCRM installer before enabling the module. This handles the most common use case where CiviCRM is installed in the same database as Drupal itself. Custom options can be...Read more
A little background.
Established in 1972, we are a non-profit human services organization that serves many diverse populations in the Greater Pittsburgh area.
A large part of our focus is on homeless services, but we also do some mental and physical health programming, early childhood development, community integration and host a large food pantry near the University of Pittsburgh campus.
Because of our disparate clientele and locations, we have been using multiple Access databases to track participant information. For many years we wanted to move it online so staff in people's homes, could enter updates from the field. However, the cost to implement was prohibitive to say the least.
Our Drupal and CiviCRM experience
When we rebuilt our website using Drupal, I stumbled upon CiviCRM as an alternate to Constant Contact. For two years, we have used Civi on the backend of our site to register for events, make online contributions and send out...Read more
I just returned from my first CiviCRM sprint. It was called the DC Sprint, but as Jeremy has already posted, we were actually in Maryland.
As a first time attendee of a CiviCRM conference and sprint, I really did not know what to expect. I was very pleased that both WordPress and Joomla! received some real attention at the sprint and I hope we are heading to a place where CiviCRM can be truly CMS agnostic.
WordPress CiviCRM installs can now benefit from WP-CLI tools. WP-CLI is a Drush equivilant for WordPress. We were able to merge Andy Walker's port into 4.5 and Tim Otten added full API Explorer support for this. At the developer training day in DC on Saturday, we noticed an issue with civix and WordPress. This also fixed and now civix works with all CMSs without having to be directly tied to one as in the past. These two enhancements will help WordPress developers immensely.
Dana Skallman and I also worked through the unresolved tickets for WordPress. A great...Read more
We're approaching the middle of the third day of the 2014 East Coast code sprint, situated in a bucolic farmhouse just outside of Frederick, Maryland. The location has made this sprint a little different, with some people being able to commute back and forth. In total, 14 or so sprinters have been working on webtests, improvements to CiviVolunteer, and improvements to buildkit for all platforms, which some renewed focus on Joomla and Wordpress. It's looking promising that buildkit will be fully supporting all the CMS platforms by the end of the sprint, making it even easier to contribute.
As this was my first sprint, I wasn't completely sure what to expect. In between some intense, heads-down work, we've found time for decompression as well. We've worked in great meals on the various porches at the farmhouse, great conversation around the firepit, and a spirited round of "The Greatest Game Ever." Monday also included a spirited discussion on forms strategy for Civi 5.0...Read more
I was accepted into the Google Summer of Code program this year to write the Drupal 8 integration modules for CiviCRM and work has progressed well so far. Drupal 8 is on track for a release this year and hopefully CiviCRM will be Drupal 8 ready about the time it goes final.
The integration is quite a large project and in the planning/proposal phase I separated the work into 6 phases. The first 3 phases are broadly concerned with allowing CiviCRM to boot and to be able to access the bits of Drupal (ie. users) that it needs to. The final 3 phases were to implement the opposite: they are about enabling Drupal to interact with CiviCRM data, for example via Views or Rules.
To run through them briefly, phase 1 is a bare bootstrap, with only as much functionality implemented so that CiviCRM can run simple pages. For this phase, anything that requires CiviCRM to ask Drupal about users, or permissions, etc. would fail. Phase 2 involves fleshing out this missing functionality...Read more
Because of the way the synchronization process works with the UF_Match table, deleting records can be tricky business. If done in the incorrect order, your CiviCRM database can end up with a bunch of Junk contact records. Below is a best practice process for removing records, first the Drupal user record should be deleted then the CiviCRM record.
Process to Follow
Step 1 - Identify the Identify the Contact record(s) to be merged/removed in CiviCRM and note the Drupal User ID for the record to be removed.
Step 2 - Search for and locate the Drupal record for the CiviCRM Contact you are deleting that you identified in Step 1 and use the Cancel Account button to delete the Drupal User record.
Step 3 - Go back to CiviCRM and merge/delete the CiviCRM Contact record.
- Identify the Contact record(s) to be merged/removed in CiviCRM.
- Determine the record which is to be removed and note the Drupal User ID....