Subscribe to CiviCRM Blog feed
Posts related to Drupal
Updated: 58 min 49 sec ago

Drupal 8 is just around the next (53) corners*

February 16, 2014 at 8:19pm
This weekend has seen 2014 Drupal South conference in Wellington with an influx of a couple of hundred of mostly Kiwis and Aussies - but a few others - to talk Drupal. Coming away from the conference I'm excited about Drupal 8 developments and even more excited about convergence between CiviCRM and Drupal. With both Drupal and CiviCRM moving towards Symfony and Drupal having selected a bunch of other 'best of breed frameworks' that we in CiviCRM are also looking at (including Backbone), one of the big wins is transferability of developer skills. This is a win in both directions - it will be easier to get people to develop for CiviCRM and Drupal as we adapt to frameworks that are becoming industry standards. Conversely developers will be better able to apply their skills elsewhere.   One 'best of breed' framework Drupal adopted some time ago was jQuery and jQuery has pretty much become the industry standard since then. One of the speakers pointed out that at the time Drupal adopted jQuery there were several competing frameworks (CiviCRM was then using Dojo) and by a combination of good selection and community leadership, Drupal selected the 'winning horse' in that race. Thinking about that gave the Civi-developers at the conference reason to feel pretty good about taking strong leadership in frameworks from Drupal.   At the Twig presentation (a templating engine) many of the advantages Morten was excited about in Twig seemed to also to apply to our much maligned Smarty - being able to wrap chunks of text in 'translate', being able to pipe output from a variable into a 'replace' or 'formatter' function and not having to put in php around text outputs.  However, I came away with a couple of thoughts there too. Twig would be a fairly easy replacement for Smarty as it didn't feel that different and we can expect it to be maintained well into the future. However, simply replacing Smarty with Twig won't remove people's annoyances with Smarty, because most of the annoyances are about the implementation - the amount of logic in the form & templates layer and the difficulty in over-riding them in a maintainable way. So, when one of the speakers pushed the importance of 'loose coupling' I realised that was the jargon for our calls to 'get the logic out of the form layer'.   Loose coupling provides opportunities. We were shown a phone app that rendered a Drupal 'form' - without passing html back and forth to the website. Drupal now sees HTML as merely one of many possible outputs for a form. I think that would be a great challenge for CiviCRM  -  to reach the point where we could render and submit Contribution / Membership forms with all their clever logic in another application, without the expectation of HTML being part of the exchange. But, that required a rethink of how we use Smarty and whether we can move the 'doing' part of the form into its own function which can be accessed in multiple ways.   The real lightbulb moment, for me, however was in the talk about Drupal's Migrate in Core by (chx) (slides are here). As you may be aware I have written a CiviCRM extension to make CiviCRM a destination for migrations. The speaker advised we shouldn't need to do that in Drupal 8 "if you need to write a destination plugin you are doing something wrong". If your destination is an entity then Drupal provides Migrate destinations as part of the entity interface. In fact over the last year Fuzion has been investigating declare CiviCRM entities as Drupal entities as a solution to multiple problems - in particular we have looked at Rules and Views Bulk Operations. It has long been my feeling that eventually declaring CiviCRM entities should replace most of our views code (as you get Views 'for free' when you declare entities) but I now think we should do that INSTEAD of migrating our drupal 7 views code to Drupal 8.   Looking at the list of drupal 7 modules we have  
  • CiviCRM Contact Reference - we already use Drupal EntityReference fields instead of that, and I think we can avoid migrating it to drupal 8
  • CiviCRM engage - we should turn that into an extension and not migrate it to drupal 8
  • CiviCRM group roles - this can ship as a set of Rules
  • CiviCRM Member Sync - this can ship as Rules
  • CiviCRM OG Sync - this can ship as Rules
  • CiviCRM Rules - this is Rules - but would need to be reviewed against the entity approach to Rules
  • CiviCRM Theme - this would probably get migrated
  • CiviCRM Views - hopefully we can replace this with entity code.
One question would be whether we need any form of upgrade path for any of the above modules. I would note that in Drupal 8 there is no upgrade path - you create a new database and use Migrate module to put your data in there.   Another message from Lullabot keynote speaker Emma Jane was 'Start on Odd, Stay on Odd'. In other words, if you are currently on Drupal 7 you should wait for Drupal 9. The implications of this are of course that they are not expecting people to move off Drupal 7 'anytime soon'. When Drupal 7 was first integrated with CiviCRM it was expected that CiviCRM 6 would be removed more or less straight away. However, a few people, including myself, were concerned about Drupal 6 users and 2 years later we still have an important but decreasing set of sites using Drupal 6. The good news and bad news about the D6 experience - good: after the initial restructure keeping Drupal 6 integration has not required much work, bad: people have been confused about whether Drupal 6 was still supported. We've had several Drupal 6 organisations tell us that they would like to use CiviCRM but they are on D6 and we have had to explain to them that there is a Drupal 6 release. Having been the 'lead supporter of Drupal 6' for the past 2 years I have probably spent more time explaining that D6 is supported than supporting it. I think going into D8 we should be anticipating that Drupal 7 will need to be supported for some time and be consistent on that message.   I know other people are far more 'up' on D8 than I am but I think we should plan to migrate to it without copying and pasting our d7 code & trying to make it work. I've started a bit of tinkering and will push it somewhere to Github soon. Who wants to get involved in Drupal 8?   *53 is the number of critical bugs left
Categories: Planet Drupal

Best Practice for Deleting CiviCRM Contacts and Associated Drupal User Account

February 6, 2014 at 5:07pm

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 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.


Step 1

  • 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.

Step 2

  • From the Drupal People screen, locate the User record to be removed.  Note that the Drupal ID number should match the User ID from the CiviCRM Contact record.

  • At the bottom of the Edit/Account tab, choose Cancel account.

Step 3

  • Merge/Remove the CiviCRM Contact record(s) as normal in CivCRM.

  Restoring a CiviCRM record from Trash

If you have accidently deleted a Contact record from CiviCRM, you should follow the process in the order outlined below to restore the contact and reestablish a Drupal User account.

Process to Follow

  • Step 1 - Restore the CiviCRM Contact record from the trash.
  • Step 2 - Establish the connection to a Drupal User account.

If you have not yet deleted the Drupal User account that was associated with the deleted CiviCRM record and you edit the Drupal User account (from Drupal) that was associated previously, Drupal will reestablish the link to the CiviCRM record.
If there is not an existing Drupal User account, you can create a new Drupal user account for the record through the normal CiviCRM process.

Categories: Planet Drupal