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 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 primarily by subclassing CRM_Utils_System_Base. And phase 3 involves finishing the full range of functionality of the core Drupal module that we had in Drupal 7.
Currently, these 3 phases are in a rough stage of completion.
The final 3 phases have changed somewhat since my first proposal. Initially, I had planned on implementing the core CiviCRM objects (eg. contacts, events, groups, relationships…) as native Drupal entities. I was under the impression that entities integration would get me a lot of ‘free’ functionality, in particular in the form of Views and Rules working out of the box. Unfortunately, this ‘free’ functionality won’t be available when Drupal 8 is first released. Views and Rules will have to implemented manually, which may take up the majority of the remaining time available for GSoC.
I had also not factored in the installation process in my initial planning. As it turns out, the current installer is strongly hardcoded for the various CRMs that CiviCRM supports and in a bit of a bad state, so with the guidance of my mentors we’ve chosen an alternative route: create some reusable installer components and run the install process from within Drupal itself. This has the nice side effect that for the majority use cases, CiviCRM will be installable on Drupal by simply enabling the module. This work is rather finicky and at the moment still in progress.
In the course of this work I’ve taken up some strong opinions with how CiviCRM should orient itself in the future with regards to the CMSs it supports. Some of these probably deserve full blog posts, but bear with me a moment:
- CiviCRM needs to be strictly CMS agnostic (too much CMS-conditional code in core!).
- CiviCRM needs to position itself as a client of the CMS - I think a lot of the code is still written from the days when CiviCRM was standalone.
- Related to the above: trust in the CMS to make calls for CSS, JS, page contents, breadcrumbs, page title, permissions, etc. at the time when the CMS deems it appropriate. At the moment, CiviCRM tries to set all of these as a side-effect of asking for the page contents and at least for Drupal 8, this process doesn’t work anymore.
- Don’t ever attempt to bootstrap the CMS — if the CMS needs to be bootstrapped, then go in via the front door first.
For the second half of the GSoC term, my top priority is finishing the installer so that I can put out a alpha release for people to play with, and then turn to the Views and Rules integration work.
More https://civicrm.org/blogs/torrance/drupal-8-integration
- Log in to post comments