Search

In a recent blog post, Drupal 8 co-maintainer Alex Pott highlighted a seismic shift in Drupal that's mostly slipped under the radar. In Drupal 8, he wrote, "sites own their configuration, not modules".

This is part two of a series on configuration management challenges in Durpal 8. Part 1 looked at challenges for small sites and distriubtions.

As part of a long-term collaborative partnership with the University of Victoria's Geography Department, Chocolate Lily has been working on producing a customized version of Open Outreach suitable for community mapping.

Many Drupal insiders recognize that data on Drupal usage that's collected and displayed on Drupal.org have their limitations. Since 2018 there's been a proposed Drupal core telemetry initiative to expand and improve the data collected. Meantime, though, the usage stats are widely referred to and cited. So it's worth spending a bit of time with them. What do they actually capture?

If you're a seasoned Drupal module developer, or even a relatively new one, it's hard not to like the fact that, starting with Drupal 8.7.7, it's possible for a single version of a module to be compatible with multiple versions of Drupal core. Suddenly, maintaining your module became way easier. It's noteworthy enough that the process of making a module work with the Drupal 9 release was incomparably easier than any previous major version upgrade. But beyond that, you could actually maintain a single version for both Drupal 8 and 9, or both Drupal 9 and 10. How great is that?

But - and there always is a but, isn't there? - it's not quite so straightforward. There are some significant tradeoffs to sticking with a single release branch for two major versions of core. I'll look at a couple here - deferred refactoring and missed improvements - and ways to mitigate them.