This morning, September 25, 2026, gablvm.org briefly stopped serving pages four times, for about half a minute each time, between 8:30 and 9:16 AM Central. Nobody outside noticed, and the logs back that up. The cause hit a lot of Drupal sites today though, so if you run one, read on.
What happened
Like most Drupal sites, gablvm.org is built from Drupal core plus a few dozen supporting libraries. One of them is Twig, the template engine that turns Drupal's page templates into the HTML you read. Twig 3.30.0 was released this morning. It contains a performance change that compiles page templates differently, and that change breaks a technique Drupal has used for years to make Twig aware of Drupal's own safe-text rules. With Twig 3.30 installed, every page on a Drupal site throws an error before it can render.
Our site checks for library updates every fifteen minutes and applies the safe ones automatically, after taking a backup. At 8:30 AM it applied Twig 3.30. It then loaded the homepage and the login page as a test, got errors back, and rolled the site back to the previous version within about thirty seconds. Then it did the same thing again at 8:45, 9:00 and 9:15, because nothing had told it to stop.
Who was affected
As far as our logs can show, no one. The web server log records exactly forty error responses today, and all forty went to the updater's own test requests from the server itself. No visitor, no search engine, and no copy of the GABLVM app received an error. Cloudflare also serves most pages of this site from its cache for up to an hour, so even a visitor arriving in one of those windows would most likely have received a normal page.
The alert emails did reach me, and that is how the loop was found and stopped. The fix on our side was two lines: Twig is now held at version 3.29 until the Drupal fix ships, and the updater remembers a version that failed its test and leaves it alone until a newer one appears.
What happened upstream
I reported the regression to the Twig project this morning, and a Drupal core maintainer opened the matching issue in the Drupal queue at almost the same time, with a fix already in review. The Twig maintainers consider the change on their side correct and the fix Drupal's to make, and the Drupal fix does exactly that. It should arrive in the next patch releases of Drupal 11 and 10.
- Drupal core issue: Twig 3.30 TypeError in EscaperRuntime::escape()
- Twig report: 3.30.0 regression with a swapped escape filter
If you run a Drupal site
Until the patch release lands, do not let composer move you to Twig 3.30. Add this to the conflict section of your project's composer.json and run composer update with the lock option so the lock file records it:
"conflict": {
"twig/twig": ">=3.30 <3.31"
}If your site is already broken, restore the previous composer.lock from your backup, run composer install, and clear the cache. The site comes back immediately. Once the Drupal patch release is out and installed, remove the conflict line so Twig can update normally again.
What we learned
The rollback worked, and I am glad it did. What bothers me is the email it sent. It said the updater would not try that version again, and I had never actually written the code for that. The email was making a promise the script did not keep. That code exists now. I ran the updater by hand afterwards and watched it skip the held version and carry on with the rest.
The timeline is on our status page. If anything on this site looked wrong to you this morning, tell me at [email protected].