The current Drupal update framework (roughly: hook_update_N) is quite old. It is still firmly rooted in the procedural origins of Drupal. Also, it has several shortcomings.

Recently, I ran into a strange issue with a Drupal site. Phrases that were based on a count, using the formatPlural() method to determine the correct phrase to report a count, were all translated with the phrase meant for a count of 1.

I've had some trouble finding the correct settings to to get a Laravel app running on Lando to send its mails to the Lando Mailhog service. Of course, hindsight is 20/20; if I had started out at the official Mailhog documentation, it would probably have been clear in seconds. I didn't, and went from the Learning Laravel site to the Lando documentation site to Google, passing by numerous Stackoverflow articles along the way. 

Just to prime that search query for Lando, Laravel and Mailhog, here's what worked:

Once, the Drupal community had Mollom, and everything was good. It was a web service that would let you use an API to scan comments and other user-submitted content and it would let your site know whether it thought it was spam, or not, so it could safely publish the content. Or not. It was created by our very own Dries Buytaert and obviously had a Drupal module. It was the service of choice for Drupal sites struggling with comment spam. Unfortunately, Mollom no longer exists.

When deploying changes to a Drupal environment, you should be running database updates (e.g. drush updb, or through update.php) first, and only then import new configuration (which itself is supposedly the result of running the same update hooks on a development environment).

At last month's DrupalJam XL in Utrecht, the Netherlands, I gave Gabor Hojtsy's presentation on the state of Drupal 9. It was recorded - thanks DrupalJam organization! - so here is the video. You might also want to view Gabor's own presentation from DrupalCamp Belarus.

You'll need to turn up the audio, because it seems that it was recorded using the camera, not the fancy microphone I'm wearing.

Drupal 8 will actively complain when your site does not have a hash_salt configured, which usually gets generated when installing the site. (The complaint, mind you, might be fairly obscure; your site might just say "The website encountered an unexpected error. Please try again later." Depending on your error reporting settings, the message might be a bit more helpful). If, for example, you "install" a site by copying over a database and files, you will not have this.

Update 26/21/2021: since writing this blog post, I found that basically, for Drupal's functioning, it does not matter what your hash salt is. You can put in any old string, which would be fine especially for a development system. The procedure below gets you something that is similar to what the official Drupal install procedure would produce.

Last weekend, the DrupalCamp Ruhr was held in Essen, Germany. I was fortunate enough to have been selected as a speaker. I've now made the slides available online.

The slides are at Drupal 8 Configuration Management, Workflows for site development. It is an evolution of the talk I did last year at the Dutch DrupalJam.

If you have the Media module for Drupal 8 installed (not a requirement to use media with Drupal 8, so this post may not apply to you), you need to remove it before you can upgrade to the latest core version (8.4). Unfortunately, there are a few gotchas involved with the process. This blog post is about getting rid of the old contrib Media module, so the site can be updated to Drupal 8.4 in a subsequent step. This is based on my personal experience. YMMV, as they say.