Today, something clicked for me. At some level, I guess I knew this, but apparently I didn't know this. Config translation and interface translation in Drupal are connected. This is the part I basically knew; when you do translation imports, config will often get updated translations. I didn't really know how they were connected, though.
CGP Grey has created a cool... video? about the infamous game rock-paper-scissors. How do you create a video about such a mundane topic, you ask? Well, just have a look. Do continue, and if you fall off the side, go ahead and cheat, you have my permission. The end is cool.
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.
