@wildworks your fix works for me, thank you!
@westonruter encountered this on a non-Elementor site (custom theme)
@jorbin here’s an example of used code not working after 6.9
add_action('wp_footer', 'my_footer_scripts');
function my_footer_scripts() {
if (is_front_page()) {
wp_enqueue_style('slick', get_template_directory_uri() . "/assets/css/slick.css");
wp_enqueue_style('slick-theme', get_template_directory_uri() . "/assets/css/slick-theme.css");
wp_enqueue_style('home-page', get_template_directory_uri() . "/assets/css/home.css");
}
}
WordPress 6.9 introduced breaking changes comparable to the WordPress 6.2 update in 2023 when shortcodes stopped working on many sites and some default block styles changed for no good reason.
I don’t know why WordPress 6.9 had to be released in December, and why new experimental blocks are an opt-out and not an opt-in feature. The new blocks alone would have been enough to confuse some website editors, but I had to fix multiple regressions or incompatibilities after the WordPress 6.9 update on several customers’ websites. Custom block variations vanished from the block inserter, while new experimental blocks and core block variations appeared instead. Enqueueing custom block variation styles in the backend seems to have changed slightly.
So have the cache keys, temporarily breaking several popular third-party plugins, and the default styles of wp-columns seem to have changed. The latter issue is kind of my own fault: we should never rely on default display:flex when we can just add it explicitly, even more so in a classic / hybrid theme where we write our own markup and so we can add unambiguous class names to avoid or at least reduce undesired side effects.
Lesson learned: if we have to support WordPress in 2026 and beyond, we’d better improve our restrictions, add tests, test early, and raise our invoices and rates accordingly. I wonder if customers will understand though, when every marketing department claims that “AI will do everything” now.
@karpstrucking I cannot reproduce the issue you’re describing. I put together a test plugin which does the same as you showed:
add_action(
'wp_footer',
static function () {
if ( is_front_page() ) {
wp_enqueue_style('enqueued-at-wp-footer', plugins_url( 'enqueued-at-wp-footer.css', __FILE__ ) );
}
}
);
The enqueued CSS file enqueued-at-wp-footer.css is as follows:
body:after {
content: "Stylesheet successfully enqueued at wp_footer!";
background: lime;
padding: 1em;
position: fixed;
bottom: 0;
right: 0;
}
On the front page, I successfully see the lime green message coming from the stylesheet:
Stylesheet successfully enqueued at wp_footer!
I also see the stylesheet appearing in the HEAD as expected due to the hoisting in WP 6.9:
<link rel="stylesheet" id="enqueued-at-wp-footer-css" href=".../wp-content/plugins/enqueue-styles-at-wp-footer/enqueued-at-wp-footer.css?ver=6.9" media="all">
You can try it on Playground.
-
This reply was modified 3 months, 3 weeks ago by
Weston Ruter.
@westonruter for this particular site the issue was resolved using the snippet provided by @wildworks
the site uses an older custom theme, so my guess is that it’s doing something elsewhere in the theme that isn’t “the WP way” but was, until 6.9, still working
@karpstrucking As opposed to using the should_load_separate_core_block_assets filter, I suggest instead using the Load Combined Core Block Assets plugin to do the same. This will allow you to easily turn off the workaround when the issue is fixed, and be able to test the fix in core before turning deactivating the plugin.
Additionally, it would be helpful to have details about how your theme is constructed to facilitate reproducing the issue.
design breaks when using grid blocks. CSS value for is-layout-grid is empty. Disabling the admin toolbar restores the grid to normal. wow?
add_filter( ‘should_load_separate_core_block_assets’, ‘__return_false’, 100 );
The above code worked.
Elementor is not involved.
@devanykr Please use the Load Combined Core Block Assets plugin instead (which involves the same code), since it makes it easier to test whether the issue is fixed once 6.9.1 is released.
It would be helpful if you could test the fix for the ticket as well. Not sure if you’re set up to do that.
Do you know if the problem is solved with the WordPress 6.9.1 update?
@xwolf Thank you! That fix is the only thing that works!
Hopefully 6.9.1 solved these issues.
