drupal

I install a lot of Drupal sites day to day, especially when I'm doing dev work.

In the course of doing that, sometimes I'll be working on infrastructure—whether that's an Ansible playbook to configure a Docker container, or testing something on a fresh server or VM.

In any case, I run into the following error every so often in my Nginx error.log:

"php-fpm" nginx Error: Undefined constant PDO::MYSQL_ATTR_USE_BUFFERED_QUERY

The funny thing is, I don't have that error when I'm running CLI commands, like vendor/bin/drush, and can even install and manage the Drupal site and database on the CLI.

The problem, in my case, was that I had applied php-fpm configs using Ansible, but in my playbook I hadn't restarted php-fpm (in my case, on Ubuntu 22.04, php8.3-fpm) after doing so. So FPM was running with outdated config and didn't know that the MySQL/MariaDB drivers were even present on the system.

Since being DDoS continuously earlier this year, I've set up extra caching in front of my site. Originally I just had Nginx's proxy cache, but that topped out around 100 Mbps of continuous bandwidth and maybe 5-10,000 requests per second on my little DigitalOcean VPS.

So then I added Cloudflare's proxy caching service on top, and now I've been able to handle months with 5-10 TB of traffic (with multiple spikes of hundreds of mbps per second).

That's great, but caching comes with a tradeoff—any time I post a new article, update an old one, or a post receives a comment, it can take anywhere between 10-30 minutes before that change is reflected for end users.

I used to use Varnish, and with Varnish, you could configure cache purges directly from Drupal, so if any operation occurred that would invalidate cached content, Drupal could easily purge just that content from Varnish's cache.

This is the text version; I have a video version of this post on YouTube: Freenode is dead. Long live IRC? [video].

I've been on IRC since I started participating in the Drupal community in the mid 2000s. For over three decades, countless programming and open source communities have centralized their real-time discussions on IRC servers. While overall IRC usage has declined in the past twenty years, Freenode became the most influential hub for IRC users, with the majority of users and channels, especially for open source discussion.

But all things must come to an end, and it seems like Freenode's new leadership—who took over the network over the past few years—are doing everything they can to drive it into the ground, fast.

When I first heard about a bunch of Freenode staff and volunteers forming a bit of a suicide pact, I knew something was up, and immediately many open source communities started discussing what they'd do if their main discussion platform went belly-up.

First of all, Drupal is not dead. But I would argue it's not in healthy place relative to competing projects as it was in its heyday, in the early 2010s.

In this blog post, I will explore the problem the Drupal community finds itself in five years after a major release that broke backwards compatibility in almost every subsystem, forcing a laborious upgrade process and process shift that left many users in the dust.

I've written about this in the past, most famously in my post Drupal 8 successes and failures. I'm not going to rehash the details from that post, but I did want to focus on what I think is the primary reason for this graph's downward trajectory since 2016:

I just released Drupal VM 6.0.0 today, and it is the best version of Drupal VM yet!

The main goals for this new version are stability and compatibility.

Originally I was going to drop some features that are helpful for people running older Drupal 7 sites, but since Drupal 7's End of Life was just extended into 2022, I decided to extend the support for some features like Drush make files, as many users of Drupal VM still maintain Drupal 7 sites, or use Drupal VM to test the upgrade from Drupal 7 to Drupal 8 or 9.

The default PHP version was upgraded from PHP 7.2 to 7.4 in Drupal VM 6, and this new version should work great with almost any Drupal 7, 8, or 9 website (in fact, PHP 7.3 is Drupal 9's minimum requirement!).

At this point, I've showed you how you can use the Turing Pi as a Kubernetes cluster to run different things. I barely scratched the surface of what's possible with Kubernetes, but I'm planning on doing another series exploring Kubernetes itself later this year. Subscribe to my YouTube channel if you want to see it!

In this post, I'm going to talk about the Turing Pi's performance. I'll compare it to a more traditional Raspberry Pi cluster, my Pi Dramble, and talk about important considerations for your cluster, like what kind of storage you should use, or whether you should run a 32-bit or 64-bit Pi operating system.

As with all the other work I've done on this cluster, I've been documenting it all in my open source Turing Pi Cluster project on GitHub.

Video version of this post

This blog post has a companion video embedded below:

Update: The upgrade was a success! The site is now on Drupal 9.0.0, yay!

I'm planning on upgrading my www.pidramble.com website from Drupal 8 to Drupal 9 LIVE on my YouTube channel today, in honor of the #D9Launch today!

The site is currently running on a single Raspberry Pi on my desk in my basement... so this would not only be the world's first live Drupal 9 upgrade, it may possibly be the first-ever Drupal 9 site running on a Raspberry Pi!

Fingers crossed, I hope Drupal 9.0.0 will be ready to go by 5:00 p.m. US Eastern time (today, June 3rd)—if so, the stream will begin at that time, and I've embedded it below:

Recently, while working on the codebase for this very site, I tried running composer update to upgrade from Drupal 8.8.4 to 8.8.5. Apparently I did this at just the wrong time, as there was an issue with Drupal's dependencies in 8.9.x-dev which caused it to be selected as the upgrade candidate, and the default drupal/core-recommended Composer setting was to allow dev stability, so my site got updated to 8.9.x-dev, which was a bit of a surprise.

"No worries," I thought, "I use git, so I'm protected!" A git reset later, then change my composer.json to use "minimum-stability": "stable", and all is well with the world, right?

Well, no. You see, the problem is Drupal 8.9.x changed from an abandoned package, zendframework/zend-diactoros, to a new package, laminas/laminas-diactoros, that replaces the abandoned package.

May 19 Update: It was a total success, yay! This site is now running Drupal 8.

Over 100 days in, the big day has finally arrived—it's time to upgrade this website from Drupal 7 to Drupal 8! The entire process has been documented, one hour at a time, in my 'Drupal 7 to 8' live streams. Visit that link to view all the previous episodes, from setting up a new Drupal codebase, to running the first test drush migrate-upgrade command, to upgrading this site's theme from PHPtemplate in Drupal 7 to Twig in Drupal 8.

Some of the highlights:

tl;dr: Video from CMS Philly presentation, Slides from the presentation, and scroll down to see graphs of particular interest to Drupal developers.

On May 1st, Chris Urban and I presented 2020 Developer Tool Survey Results at CMS Philly. For the past few years, we've run an annual Drupal Dev Tool Survey (2019, 2018) and presented the results at DrupalCon and some local Drupal Camps.

Since DrupalCon went virtual this year, and Chris was helping make CMS Philly virtual, he suggested I join him at that conference and reveal the results at this session.