WordPress 6.9.1 Breaks Block Styles in Sage — Here’s the One-Line Fix

If you updated to WordPress 6.9.1 and your Sage-based site suddenly shows a white screen or a fatal error on pages that use block style variations, you are not alone. This is a known incompatibility between WordPress core’s new block asset loading behavior and how Sage/Acorn handles errors — and the fix is a single line of PHP.

What You See

After updating to WordPress 6.9.1, pages with block style variations crash with something like:

Function WP_Styles::add was called incorrectly.
block-style-variation-styles was registered with global-styles as a dependency
before global-styles was registered.

Acorn’s error handler treats _doing_it_wrong() calls as fatal errors — the right behaviour in development — which means any page that loads block style variations dies with a white screen. On our own site, the /resources/ page went down immediately after the 6.9.1 update.

Why It Happens

WordPress 6.9 introduced on-demand block asset loading — instead of loading all block styles up front, it loads them only when a block is actually used on a page. WordPress 6.9.1 tightened this further by adding strict dependency validation: if a style is registered with global-styles as a dependency before global-styles itself has been registered, WordPress fires _doing_it_wrong().

In FSE (Full Site Editing) block themes, the load order works correctly. But in classic themes — which is what Sage uses under the hood, even when you are using Gutenberg extensively — the registration order is different. The block-style-variation-styles handle gets registered before global-styles is available, triggering the error.

Acorn converts any _doing_it_wrong() into a proper exception or fatal error screen, so what WordPress intends as a soft warning becomes a page-killing error for Sage sites. This affects any Sage theme that uses block style variations — custom blocks, core block style variants, or anything registered via register_block_style().

The Fix

Add this to app/setup.php in your Sage theme:

/**
 * Disable on-demand block asset loading.
 *
 * @link https://core.trac.wordpress.org/ticket/61965
 */
add_filter('should_load_separate_core_block_assets', '__return_false');

That is the entire fix. One filter, no arguments, no configuration needed. This is the approach adopted in roots/sage PR #3279.

This tells WordPress to load all block assets the old way — up front, in one go — which avoids the problematic registration order entirely. The performance trade-off is minimal for most sites and is the same behaviour WordPress used before 6.9.

Where to Put It

In a standard Sage theme, open:

app/setup.php

Add the filter anywhere in that file alongside the other setup hooks. Here is the full context of how it looks in our setup.php:

/**
 * Disable on-demand block asset loading.
 *
 * @link https://core.trac.wordpress.org/ticket/61965
 */
add_filter('should_load_separate_core_block_assets', '__return_false');

/**
 * Use the generated theme.json file.
 *
 * @return string
 */
add_filter('theme_file_path', function ($path, $file) {
    return $file === 'theme.json'
        ? public_path('build/assets/theme.json')
        : $path;
}, 10, 2);

Deploy, flush your cache, and the error is gone.

Is This a Permanent Fix?

For now, yes. The upstream issue is tracked at core.trac.wordpress.org/ticket/61965 and the official Sage resolution is documented in roots/sage PR #3279. Once the WordPress core team resolves the load-order issue for classic themes, this filter can be removed — but until a core patch ships, this is the safe and supported approach.

Affected Versions

Component	Version
WordPress	6.9.1
Sage	11.x (Acorn 4.x)
PHP	8.2+

Summary

WordPress 6.9.1 added strict block style dependency validation that breaks on classic themes (including Sage) when block style variation styles are registered before global-styles. Acorn converts the resulting _doing_it_wrong() call into a fatal error. The fix is to disable on-demand block asset loading with one filter in app/setup.php. The issue is tracked upstream and will be resolved in a future WordPress release.

If you run into other issues after the 6.9.1 update, or if you are managing a Sage/Trellis stack and need help with WordPress infrastructure, get in touch.