Search

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.

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?

As Drupal 8 entered its last months of life, I found myself reflecting. What did version 8 mean for the project? What was lost? What was gained? What were the roads not taken? To try to puzzle out at least some preliminary answers, I read up on what others had shared and spent some time with various sources--Drupal core and contrib code bases, usage statistics, old conference presentations, release announcements and more. I started the exercise motivated by personal interest but now that I've wrapped it up I figure I may as well share my observations in case they're of interest to others.

Change can often be a hard thing for groups—even progressive groups.  Getting a staff team to willingly adopt new software or a new website can be challenging.  Especially for staff who always feel a shortage of time in getting the important work done.

Any way you do it, upgrading an organizational website to a new major version of Drupal - for example, from Drupal 5 or 6 to Drupal 7 - is a significant task.

Get as much as you can out of existing solutions. Often, this means adjusting expectations or adopting different solutions for the same problems.

As the developers and maintainers of the Open Outreach distribution for nonprofits, we’re curious to see who is using the distribution to further their website building efforts.

What if Drupal 8 had taken a different path? What if profitability and expanding market share and wooing enterprise clients weren't the driving aims? What if, instead, we'd focused on stability, usability, and accessibility for small and medium sized organizations.

Browsing joomla.org, I recently noticed the following in the Joomla roadmap: "The Joomla! CMS (content management system) seeks to create a variety of distributions of the CMS to address a variety of common niche markets." Good idea!