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?
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.)
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.
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.
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!
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
Plugin boilerplates can do some of the heavy lifting during initial development. We look at four options to speed up your plugin creation. https://t.co/ZtMsdBxAHw
— Advanced Custom Fields (@wp_acf) June 5, 2023
© 2023 Advanced Custom Fields.
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.