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”.
Comments
Tim, you know I always appreciate your prodigious efforts, and I'll admit, there is a lot of this that is over my head. And I'll say, from an admin perspective, not a developer perspective, that the Joomla Civi install in many ways is easier than any other. But that's not my main reason for commenting.
You made the statement "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." My questions are:
I'm not trying to be argumentative, nor unappreciative of your efforts, but I think these are fair questions, not only for the potential market of new Civi users, but also for our existing base as well. As far as I know, the jury is still out on what those 7000+ Civi-D7 installations are going to do come next November (when D7 is officially sunsetted). Have we surveyed them? Are they planning to upgrade to D8? Are they seeing this as an opportunity to move to WordPress or a different CMS? If we are not careful, we (as a community) could really put ourselves out on a ledge here.
Again, sincere thanks for all you do for our community.
Ye trouble maker! ;) Let me try to say this better: Civi-D8 should meet/exceed the standards/expectations of its forebear, Civi-D7.
I think your questions are digging for more substance under the phrase "reference platform" than is really there. It's not a formal construct.
LOL...not trying to cause trouble. But in all fairness "meet/exceed the standards/expectations of its forebear, Cive-D7 " implies something quite different than "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" (emphasis added). Because the latter just begs the question "reference platorm in relation to what?" (From Wikipedia: "Reference is a relation between objects in which one object designates, or acts as a means by which to connect to or link to, another object. ") So thank you for clarifying.
However, I think the question about how much we know about the plans of the 7000+ Civi-D7 organizations is still legitimate, and could help guide the CT and us all as a community about how much effort goes towards each CMS platform. In a non-limited world, they would all get as much as they need, but in our resource-constrained environment, making sure we are working on what matters most, well, matters. So far, Greenleaf has some D7 clients who plan on mirgrating to D8, some who are looking at it as an opportunity to move to WordPress, and some who have not decided or have not given it a lot of thought. But I wonder if there is a way to do some sort of survey to see where the greater community of Civi-D7 users is at.
Again, thank you for clarifying Tim!
This is great news! I adopted Drupal 8 when it landed in November 2015 and I've been tinkering with the CiviCRM D8 versions for a few years now, anticipating the release of a stable version.
I'm excited for this next chapter now that Drupal 8 has adopted true OOP methods; I'm sure that integration bettween Drupal/CiviCRM will be evermore seamless. As a developer, integrating CiviCRM and Drupal 7 (and Drupal 6) for custom features has felt a little like a jigsaw puzzle. Build a CiviCRM extension using OOP and MVC patterns, then build a Drupal 7 hook based module to connect CiviCRM and the extension to Drupal. In the very least, the coding conventions will have the same feel.
Thanks for the info and hard work.
Cheers,
Andrew