Monday, October 13, 2014 - 15:42
Written by

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 configured by adding configuration settings to Drupal's settings.php. For example, if Drupal is configured with a second database named 'civicrm', it will install civicrm there instead. The next big milestone was Views integration. This went ahead quite smoothly, and I managed to reduce the code count from approximately 15,000 lines of code to under 2,000 by automating a lot of the discovery of the CiviCRM database. In general, when new fields appear in CiviCRM it should only be necessary to explicitly declare how the field is related to other data types (eg. as joins or relationships). One quick nice-to-have was integrating Drupal's entity reference field with CiviCRM Contacts — mostly by creating a bare-bones Drupal entity. A similar technique may prove to work with Drupal's Rules module, but unfortunately time did not allow this yet. Finally, for the first time, the module comes with a few simple integration tests (using Drupal's SimpleTest module) which will hopefully become more fully fleshed out with time. With a judicious set of tests, this should allow a more stable experience as future versions of CiviCRM are released. Drupal 8 has finally released its first beta just over a week ago. Now that it has stabilised somewhat, we need to update the CiviCRM module to resolve breaking changes and we can then release an alpha version that the community can test, experiment with and help get into a stable state. Drupal 8 repo:

Filed under


I just missed some questions on IRC but WRT which CiviCRM version D8 will work with - most of the code for the integration is outside of core & the code that goes in core is only additional code. The PR is currently against 4.5, Torrance developed against 4.4. It's tagged in JIRA against 5.0. Which will it work with? It largely depends on enhusiasm. Now that it has gone BETA it probably needs another round of tweaks. Tim was hoping to find time to add it into build kit but that seems to have been elusive.

Hey Eileen, it was me that you missed, but thanks for framing the question in these comments much more clearly than I did on IRC. It will be 'ready when it's ready' of course, but planning for a project that has specified Drupal 8 it would be great to know what rough plan you folks were working to. Thanks.

The PR for the core part is now against 4.6 - since that was the path of least resistance. In your case 4.6 should be out in time. I think Pete is hoping to see a bit of sponsorship towards a final push since Torrance will be available to do that in November / December & drupal 8 is stable enough now for that

Torrance should have some time in Dec-Jan. The key issue at that point is how much Fuzion can subsidise this work, versus passing the hat around so other Drupal-users of CiviCRM - who have an eye to the future - might chip in. I will give some thoughts to this with torrance and eileen and see what we can suggest.

Torrance, I'm interested in trying this out, and hopefully getting a start on upgrading the webform integration code as well. What are the steps to take a stock CiviCRM git checkout, pull in your code, and install on D8?

It looks like your git repo is not forked from the core repo, which seems like it will make it hard to merge in changes and rebase your own work to keep it up-to-date. It might be time to do a real D8 branch in core and merge this stuff in before it gets too out-of-sync.

Coleman - basically you need this PR


& then just stick Torrance's folder in your drupal folder.


Actually - I don't think his install class is in that PR as I questioned with Tim about whether it was all good to go in that location.

I don't think it necessarily makes sense to set up the d8 branch as a branch of d6 / d7 because I think it was written from scratch so much that patches wouldn't be transferrable between them anyway.