Hey @matthias-wagnerfalkemedia-at,
Thanks for the report, we did make changes in 5.10 that could potentially cause this, but we’ve been unable to reproduce it locally – it could be caused by the browser loading a cached or old version of the acf-input.js file though.
Are you able to clear the browser cache and see if it’s still happening? Alternatively, if you could send us your field group export to [email protected], I’ll pick this up with you there and see if we can figure this out.
If you’ve go the issue happening on a publicly accessible site you’re able to grant us access too, even better.
Thanks for your help!
We’ve just released ACF 5.10 which includes a fix for this issue! Please let me know if you continue to have any problems after updating.
Hey Everyone,
This issue (specifically, the conflict with Yoast) was solved in today’s 5.10 release! 🎉
More info in the release post here: https://www.advancedcustomfields.com/blog/acf-5-10-release-html-escaping-blocks-api-v2-block-preloading-and-more/
Hey @proxxim, thanks for the suggestion.
You could do this now using getEditorSettings which includes the color palette, so something like the following js filter:
acf.addFilter('color_picker_args', function (args) { const settings = wp.data.select( "core/editor" ).getEditorSettings(); let colors = settings.colors.map(x => x.color); args.palettes = colors; return args; });
@jonschr Yup! That seems great 🙂
And just for anyone else reading this thread, @hellmute’s issue seems to be different. I’ll update back here once we have a cause and resolution there too 🙂
@jonschr Hey Jon, you’re right that ACF prevents itself from loading, but your call to the change the setting URL is being read by the “normal” install of ACF, and trying to load the assets from your included plugin as that is still set.
Your best bet would be to copy that detection logic into your plugin, then place the whole include and add_filter inside it.
Hey @jonschr, ACF 5.9.8 changed most of the asset paths, so the issue with your section plugin is a conflict between the bundled ACF 5.9.3 and the installed ACF 5.9.8.
Because you filter acf/settings/url to your path, that’s being applied to the installed 5.9.8 too, which is then trying to load 5.9.3 assets. This is likely to break a lot of things regardless, as even on 5.9.7 you’d have been loading 5.9.3 assets.
You should probably detect if ACF is already installed and active and not modify the assets URL if it is.
Hey @hellmute
Could you drop us an email to [email protected] with your block configuration and template file please?
In the mean time, I’ll see if I can reproduce this with your elodin-section-block repo @jonschr
A form of this bug has resurfaced in yesterday’s 5.8.1 release.
The new acf_is_block_editor function in api-helper.php should presumably also check if get_current_screen exists at the start (line 5051)
I fixed it with the following code:
function acf_is_block_editor() {
if( function_exists('get_current_screen') && method_exists(get_current_screen(), 'is_block_editor') ) {
return get_current_screen()->is_block_editor();
}
return false;
}
It’s a simple bug with a simple fix, i’m sure Elliot will have 5.1.2 out the door very quickly, but if this is really affecting you,
https://gist.github.com/lgladdy/3d16dcf87c1cec4c4b6d
will help!
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!
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.