WordPress default block inline styles not loading in frontend

I have the exact same issue. Works fine on my local Docker container, but one of my live sites does not get block styles (specifically for the Navigation block, which is the first one you’d see). The navigation/style.css file does not even show in the source code. This is with any of the base themes.

Another site I own *does* work, so I guess I’ll have see what’s so different about that one.

After some fiddling and debugging, I found that a database reset / reinstall would make it work. That’s not a fix, obviously, so I tried to get more specific. Dropping all of wp_posts did *not* fix it;

The eventual database record I landed on was a transient with the id of _transient_wp_core_block_css_files in the wp_options table

Delete that, and default css files should load again.

• This reply was modified 1 year, 2 months ago by mevanloon.

I had the same problem with block inline css not loading on my server after deploying files and database from a local development environment.

@mevanloon put me on the right track and I confirm that deleting the transient wp_core_block_css_files from the database on the server fixed the issue. The transient caches the full path of all the css files in wp-includes/blocks/. After a migration/deployment the paths don’t work but the transient needs to be deleted before being automatically re-generated with the new correct paths. 

Deleting the transient after every deployment felt a bit cumbersome so I kept digging and came across this article that mentions the constant WP_DEVELOPMENT_MODE introduced with WordPress 6.3. Adding define( ‘WP_DEVELOPMENT_MODE’, ‘all’ );? in my wp-config.php in dev and leaving it empty (or not defining it) in production solves the issue because it prevent exactly that type of caching and transient issues.

• This reply was modified 1 year, 2 months ago by sylverbear.

Oh that’s neat, I didn’t know about that constant. I just added a line to my ‘push’ script that removes that transient from the database.

Glad to be of service, these things can take precious time when hunting down.

I just wasted a day trying to solve this. Wish I’d seen mevanloon’s solution earlier. Thanks so much. Deleting _transient_wp_core_block_css_files worked like magic.

Thanks for this solution, it works 100%. I wasted my whole day yesterday trying to figure this out on my own

Very nice!

Deleting the _transient_wp_core_block_css_files fixed the problem!

Great! Thanks for the hint.

Deleting the _transient_wp_core_block_css_files fixed the problem also for my homepage.

This was driving me insane!!
I had some buttons and tables with different styles on the development and production environment, for no apparent reason.

This topic addresses the same problem and it was marked as Resolved: https://www.ads-software.com/support/topic/wp-style-block-gap-different-on-staging-and-production-sites/

The “solution” on that topic was to install the Gutenberg plugin, and it did in fact fix it for me. But using the Gutenberg plugin on a production website doesn’t look like a proper solution, does it?

Clearing the _transient_wp_core_block_css_files did fix it for me, but adding the define( ‘WP_DEVELOPMENT_MODE’, ‘all’ ) to the dev website is a much better solution, because it prevents WordPress from creating the transients for the Core Blocks and removes the need to clear the _transient_wp_core_block_css_files on each database migration.

Thanks @sylverbear for this amazing solution!

There is a patch for this (#59111) and should be rolled out in WP 6.3.2 soon.

Thank you for posting this solution! Deleting the _transient_wp_core_block_css_files record fixed the problem for me on 6.3.1.

Thanks so much for this – I’d never have found this on my own. This fixed my issue.

THANK YOU. My brain was melting and this thread saved me from turning into a complete puddle.

In WordPress 6.3.1, deleting _transient_wp_core_block_css_files worked. The problem remains in 6.3.2, where deleting this record no longer works. Setting define( ‘WP_DEVELOPMENT_MODE’, ‘all’ ) as suggested by António Carreira, do work. However, this seems to be a rather hacky solution. What is the official way of solving this?

@colorful-tones Is there any response to the question @gaborangyal asked? Apparently with the 6.3.2 release, the patch just makes it so the hack that works (deleting the specific transient) no longer works. Is there an official, best-practice solution for this issue?