Module Update

Drupal 9 Upgrade: Start to Finish

Good news: after all the sweat and blood of getting our site ready, the upgrade took all of 30 minutes. This really may be the easiest Drupal upgrade in a decade. It's still not for the faint of heart. Here's a quick recap on the steps necessary to do this upgrade. I'll be sure to link back to my previous articles so you can see the work and challenges involved with each step in detail.

Drupal 9 Up Front

Compared to all the work that went into prepping the site, the actual upgrade is a walk in the park. I'll be sure to cover the actual upgrade process in Step 5 of this article; I'd like to do a quick recap on the entire process, though--so, if you've already read my earlier Drupal 9 Upgrade posts, feel free to skip to Step 5. Otherwise, let's reconnect with what the basic steps are for a D8 to D9 upgrade.

Tags

Drupal 9 Upgrade: Patching Modules 101

Not all contributed D8 modules have D9 compatibility built into their latest releases. More than a few, however, will have a patch available in their open issues that will get you there. I've had several occasions to patch a module, but it's not something I do with enough frequency to immediately recall how it's done. On the command line I often forget which is the right way to do it: git apply or patch?

Prepping for a Patch

As with all things Drupal--attention to detail is paramount. It's easy to get ahead of yourself when looking for and applying a module patch, but one of the first things you'll want to do when you find one is to ensure that the patch was built for the module version you're using. A patch is a file that applies very specific changes to an already existing file. If the existing file you have on your site (say, the info.yml file associated with a module) differs from the one the patch was created for, the patch will likely fail.

Tags

Drupal 9 Upgrade: Composer and Drupal's Module Directory

It seems like a no-brainer to me, but I must have missed something. Why Drush, Drupal's admin UI and Composer would install modules into different directories by default is beyond me.

Default Module Directory

Where are modules really supposed to go, anyways? Here's what Drupal.org has to say:

Tags

How to Kill your Drupal Site: Database Cache

Juggling Git branches between a Production, Staging, Development and Localhost environment can make for exciting errors every now and then. Drupal often labels these errors as 'unexpected'--an obvious but often unhelfpul label. The culprit is often the database cache--here's a real life walk through of how it might be fixed.

Quick note here: I'm working with Drupal 8--although, the process documented here is more or less the same for Drupal 7 or even Drupal 9...

I recently ran some Drupal module updates on our Development site; one of those updates required a database update--namely, the Google Tag Manager module. I brought down the branch with module updates onto my localhost and then imported a copy of my Production database to continue the work on my computer. Upon loading the site, I encountered an unexpected error:

Tags

How to Kill your Drupal Site: Updates

It seems counter intuitive, but sometimes the easiest way to bring your site down is to catch up with your updates.

Let me qualify that, slightly: the risk of bringing your site down grows considerably when you're not constantly keeping up with updates. If you've neglected your updates for more than a few months or so, you may be inviting the WSOD (White Screen of Death--a digital grim reaper, of sorts) the next time you run your updates. Even without months of neglect, unless you're paying attention, updates can still be deadly to your site. Here's why:

Tags

Subscribe to Module Update