DevOps

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: 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

Drupal 9 Upgrade: Issues with Composer

The upgrade from Drupal 8 to 9 has been hailed by Drupal.org as the easiest upgrade in a decade. The first steps in the upgrade process look to be getting your testing environment in order... for me, that means working through a couple of nasty headaches with Composer (self inflicted... of course).

It's been a long couple of weeks...

... long...

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

Check the Status of DNS Changes with nslookup

Like a watched pot never boils, sometimes DNS changes seem to take forever to propagate. nslookup is a quick and easy way to check on the proverbial pot once you've made changes.

I recently needed to make some DNS changes on domains I manage. As is always the case, I made my changes, set the TTL as low as I can get away with, and then made myself ready for what always seems like an unbearably long wait. The time it takes for changes to propagate (for DNS Servers to clear out previously cached entries on your domains) is probably one of the most painful elements in Dev-Ops. It's like watching a pot boil--except, there's no pot and all you can do is hit reload on your website every 5 minutes. Did the changes work? Did everything go the way it's supposed to?

Tags

How to Kill your Drupal Site: Billing

Part 1 in an ongoing series of blog posts discussing how you can bring your site down. Part 1 looks at an easily neglected element of development opperations: billing for things like SSL certificates and domain names.

Today I'd like to look at one of the most obvious, but least thought of, reasons for why sites stop working. Plain and simple--it's billing. Drupal may be free* (with an asterisk), but even with an open source CMS, you'll likely be signing up for any number of products and services in order to run your site. Your server, your domain, your SSL Certificate--these are all fundamental in your site's operations. What happens if you don't pay for them? 

Tags

Subscribe to DevOps