Search

This is the eighth and last installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts.

It's a specter ghastly enough to make the most seasoned Drupal developer quiver with fear. Yes, it's the dreaded Haunted Drupal Site!

As always, the best way to test out how things are working is to get busy and start using them. And so far the results of building with Drutopia are feeling pretty positive.

Since starting a farm is a monumental task, we needed to make sure that the website was easy to get set up and easy to maintain going forward.

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?

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.

A current project we're working on at Chocolate Lily involves upgrading a Drupal 6 site to use the Drupal 7 Open Outreach distribution. It's the first time we've used a Drupal distribution for an existing Drupal site instead of a new one.

What is Drupal good for? Drupal is often used for creating complex organizational websites that might take weeks or months to develop from initial plans to launch. But what if you need a site, like, tomorrow?

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.