I recently held a live stream where I walked through the continuous integration and deployment (CI/CD) of a Drupal project to DigitalOcean's App Platform and other CI/CD items. App Platform has its quirks, but it's simple to build an application with various components.

I have just tagged drupal-check 1.4.0. This is kind of a big deal. And it's either a great thing or is going to destroy my inbox with support requests. But, in my opinion, it is completely necessary.

Today at DrupalCon we had the infamous Driesnote. The tone of the Driesnote focused on what we, as a project, should strategically focus on while building features on the Drupal 10.x.x branch. Dries wants to bring Drupal back to its roots by focusing on the site builder audience. This includes automatic updates, the project browser, and reimagining distributions as composable starter kits.

Drupal's entity storages have a loadByProperties method to simplify loading entities based on conditions. For configuration entities, these are on their properties. For content entities, these are on their field values.

This past weekend was at Florida Drupal Camp, and I gave a talk about using PHPStan to tighten up your Drupal codebase.

I recently did a deep dive into command authoring with Drush, which is where I discovered two amazing new features: auto-discovery of commands via autoloading and the addition of attributes for defining your commands.

Today I realized that I had no idea when it was appropriate to use hook_update_N or hook_post_update_NAME. I have ideas, but I was not sure about the concrete reasons. My gut instinct is that hook_update_N is for schema and other database-related changes.

In the early days of Drupal 9, most folks were only using PHPStan on their Drupal sites via drupal-check for deprecation checks. I am excited to see more folks using PHPStan directly with phpstan-drupal to perform static analysis and deprecation checks.

In this episode of "Matt does ridiculous things with Drupal," I found out that the inbound processing of a path and the lookup for its route gets cached. That makes sense, it can be an expensive process to say /foo is actually an alias of /node/1 and should go to the entity view controller.