Drupal's role-based access control is one of its strengths. Permissions and roles are well-understood, and the system is mature. But the moment you step outside the standard cookie-based session — say, into OAuth with the authorization code flow — you hit a wall that the core permission model never anticipated.
By default, drush updb clears the cache after applying database updates. For deployments where you want to avoid an unnecessary performance hit, you can prevent this default behavior using a Drush pre-command hook. The updb command has a --cache-clear flag that you can set up in your CI workflow, but what about local testing?
If you've been a user of Simplytest, I've just completed a round of maintenance, and everything should be up and running again. The service must have been spamming the Drupal.org APIs and caused itself to get blocked. I've worked with the DA team, and now Simplytest can make API requests again to get project and release data.
I had been considering a self-nomination for the Drupal Association At-Large Board Seat a few times. This year, I decided to throw my hat into the ring. I've been a bit busy with baseball season kicking off (three kids, three teams 🫠) that I haven't written a blog yet, but I will, explaining why I've considered now the right time.
If you caught the State of Drupal presentation (aka Driesnote) from DrupalCon Atlanta, maybe you noticed something missing. There was no news about Drupal 11 or what lies ahead with Drupal 12. Instead, we talked about Drupal CMS, Experience Builder, and the upcoming concept of site templates.
PHPStan 2.0 was released a month ago, a massive milestone for the project. To learn about all the changes, I recommend reading the release announcement.
This blog expands on my DrupalCon Barcelona talk,
I was doing website maintenance and checked for outdated dependencies with composer outdated. I usually filter with -D for checking direct dependencies and -p for packages with patch releases. These are typically easy pickings.