ACF Blocks with block.json generates wrong CSS file URL in editor

• room34

• April 10, 2023 at 3:21 pm

Am I doing something wrong here, or is this a bug?

I’m creating ACF Blocks using block.json and in my block.json file I have this line:

"style": "file:./tile.css",

This CSS is loading (inline, in the head) correctly on the front end, but on the back end it’s not loading, and I also noticed there’s a 404 error in the console… the CSS file is being requested, but the URL is wrong.

For example, if the URL should be this:

https://example.com/wp-content/themes/mytheme/blocks/tile/tile.css

…the URL it’s actually requesting is this:

https://example.com/wp-content/plugins/var/www/html/example.com/wp-content/themes/mytheme/blocks/tile/tile.css

Note /plugins/ in there. That’s part of what it’s generating as well, which seems relevant too, as if what it’s doing is PLUGINDIR . get_template_directory() …

As I asked at the beginning… am I doing something wrong, or is this a bug in ACF?

• room34

• April 11, 2023 at 4:28 pm

Answer: Yes, I am doing something wrong, although I haven’t figured out a fix yet. I realized this issue is happening because I have ACF embedded in my custom theme rather than running it as a standalone plugin. (I do this to have more control over updates for a couple of mission-critical plugins I use in conjunction with my theme… but I’m starting to second-guess the benefits of the approach.)

• room34

• April 11, 2023 at 6:59 pm

Upon further investigation, this was not the answer after all. I made the decision to remove the embedded ACF from my theme and install it standalone, and the problem is still happening… on the front end, the CSS is loading properly, but on the back end, the URL it’s requesting is this (parts in all-caps edited for privacy):

https://DOMAIN/wp-content/plugins/var/www/PATH/wp-content/themes/THEME/blocks/tile/tile.css?ver=6.2

It may be worth mentioning that this is a Multisite installation, although I don’t think that has anything to do with it.

• room34

• May 16, 2023 at 7:21 pm

Is no one else having this problem? It is still a major issue for me. My ACF blocks look fine on the front end but totally broken in the Block Editor. It seems like somewhere ACF is using a [something]_path() function instead of a [something]_uri() function when enqueuing the style.

• room34

• May 21, 2023 at 11:41 am

OK… well, no one here seems to have anything else to say about this, but just in case a future ACF PRO user encounters this same issue, I’ve found a workaround.

Using the "file:./whatever.css" value still never works for me in the editor (though it’s fine on the front end), but I’ve discovered that registering the script/style first, then registering the block and using the handle in block.json works.

So for example, wherever you’re registering the whatever block, you’d have these lines:

wp_register_style('whatever-css', get_theme_file_uri('blocks/whatever/whatever.css'));
register_block_type(get_theme_file_path('blocks/whatever'));

And then in your whatever block’s block.json file, you’d have this:

"style": "whatever-css",

It works!

• grex22

• September 4, 2023 at 1:27 pm

@room34 – this very annoying and very perplexing issue showed up for me as well, also on a multisite installation. I just wanted to say that, while you got no response here to your question, thanks to you returning to the forum with your solution, you likely saved me hours and hours of troubleshooting (and several gray hairs).

Thanks for sharing your knowledge!

(It also appears that there’s some semi-significant bug somewhere that may need further investigation)

• opicron

• July 26, 2024 at 5:31 pm

Same here, thanks!

Just to add:

Just make sure to use wp_register_style for all styles.

Do not add the style names to register_block_type, instead put style in the block.json.

ps: I had to opt-in the following

block-styles-loading-enhancements-in-wordpress-5-8/

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

• lgladdy

• August 2, 2024 at 6:45 am

Hey there,

ACF doesn’t do any processing or parsing of any assets defined in block.json’s core asset handlers, so any issues here will either be core issue, or something specific to your theme or site.

• darrelplant

• September 11, 2024 at 1:27 pm

Just for posterity’s sake, I’m using the same CSS background images in two different blocks. Both blocks are registered the same way:

register_block_type(__DIR__ . '/blocks/rotator-inventors-notebook');
register_block_type(__DIR__ . '/blocks/rotator-news');

The enclosing DIV for the notebook hsa the following CSS:

background-image: url(/wp-content/uploads/upper-black-band.png), url(/wp-content/uploads/lower-black-band.png),url(/wp-content/uploads/tlf_medium-spotlight_background.jpg);

That works just fine and looks like this in the Inspector:

background-image: url(/wp-content/uploads/upper-black-band.png), url(/wp-content/uploads/lower-black-band.png),url(/wp-content/uploads/tlf_medium-spotlight_background.jpg);

The identical CSS in the outer DIV of the News rotator though generates this in the background-image:

background-image: url('/wp-content/themes/theme_v5/blocks/rotator-news//wp-content/uploads/upper-black-band.png'), url('/wp-content/themes/theme_v5/blocks/rotator-news//wp-content/uploads/lower-black-band.png'),url('/wp-content/themes/theme_v5/blocks/rotator-news//wp-content/uploads/tlf_medium-spotlight_background.jpg');

making all of the image URLs relative to the block definition rather than the root of the server. Not sure why it works on one block rather than the other, they’re practically identical.