In the coming weeks, you can expect a series of changes going into the development pipeline to support the CiviCRM-Drupal 8 integration. Individually, these will seem unrelated and disjoint – they may not explicitly reference “D8”. I wanted to spend a moment to discuss the concept which ties them together: the clean install process, which will make Civi-D8 an equal member of the Civi CMS club and a good base for continued development and maintenance.
This work on D8 stabilization has been made possible by the generous funders of the Civi-D8 Official Release MIH. If you’d like to see more topics addressed, please consider contributing to the MIH.
What do you mean by “clean” install process?
A “clean” install process is a set of steps for building a site in which CiviCRM comes in a direct fashion from source-code with a bare minimum of intermediate steps.
To see this concept in action, we can compare CiviCRM’s integrations with Drupal 7 and Joomla:
CiviCRM-D7 is amenable to a (comparatively) clean install process. There are three Github projects (“civicrm-core”, “civicrm-packages”, and “civicrm-drupal”) which correspond directly to folders in the web-site. If you copy these projects to the right locations, then you have an (almost) valid source-tree.
CiviCRM-Joomla is not amenable to a clean install process. You might think it’s similar — it uses a comparable list of three projects (“civicrm-core”, “civicrm-packages”, “civicrm-joomla”). The problem is that “civicrm-joomla” does not correspond to a singular folder — the install process requires a diasporadic distribution of files. The install script which handles this is tuned to work from the “civicrm-X.Y.Z-joomla.zip” file, and producing that file requires a tool called ”distmaker”. “distmaker” is fairly heavy – it requires more upfront configuration, is brittle about your git status, runs slower, and produces 200+mb worth of zipfiles. In short, building a CiviCRM-Joomla site from clean source is more difficult.
Why does a “clean” process matter?
It’s easier to develop and maintain software when the build is clean and intuitive. Specifically:
It’s easier to climb the ladder of engagement from user/administrator to contributor/developer.
It’s easier to lend a hand – when someone submits a proposed patch, it’s easier to try it out and leave a friendly review.
It’s easier to setup automated QA processes for evaluating proposals and upcoming releases.
It’s easier to setup sites for RC testing, issue triage, pre-release demos, and so on.
It’s easier to pre-deploy a bugfix that hasn’t been officially released yet.
Anecdotally, more experts with stronger collaborations have grown-up and stayed around in the Civi-D7 and Civi-WP realms than the Civi-Joomla realm. And that does not feel like a coincidence: as a developer who watches the queue, I’m generally intimidated by a Civi-Joomla patch — even if it looks simple — purely on account of the difficult workflow. I believe that a reasonably clean/intuitive build process is prerequisite to a healthy application and ecosystem.
Moreover, a clean build of Civi-D8 is important for Civi’s future. Civi-D7 cannot be the reference platform forever – if we expect Civi-D8 to take that mantle, then it needs to be on good footing.
What kind of changes should we expect?
From a civicrm.org infrastructure perspective: Expect automatic setup of D8 test/demo sites – in the same fashion as D7, WordPress, and Backdrop. This means PR testing for “civicrm-drupal-8”. For bug triage, it means normalized and current test builds. For release-planning and QA, the test matrices will provide test-coverage for D8 (similar to the other CMS integration tests). These services are blocked on the need for a clean process.
From a site-builder perspective: Expect the recommended template for `composer.json` to be revised. This should improve support for backports and extended security releases. Early adopters may eventually want to update their `composer.json` after this settles down; however, the details are not set in stone yet.
From a developer perspective: Expect the process for setting up `git` repos to become simpler. Instead of using the bespoke `gitify`, you’ll be able to use the more common `composer install –prefer-source`.
From a code perspective: Expect changes to code/use-cases which (directly or indirectly) require auto-generated files. For example, when initializing Civi’s database, the current Civi-D8 installer relies on “.mysql” files (which have been pre-generated via ”distmaker”); we can replace this with newer function calls which don’t require pre-generated files — and therefore don’t depend on ”distmaker” or “setup.sh”.