Is the autosaves required for you @dominik_fuchshofer? I’ve not come across autosaves having any issues in my testing, but we can add it if need be.
Edit: I think autosaves would actually cause more problems than it would solve as it’s used by the block editor.
@bpcdpc You can drop back to WordPress 5.9 if need be! That will solve the issue for now – and disable automatic updates.
We’re working to get this fixed ASAP though.
@thorben Nice catch, I forgot about context. I’ll look up the code WordPress uses to add that URL and clone that, custom post types will be different too.
function acf_filter_rest_api_preload_paths( $preload_paths ) {
global $post;
$rest_path = rest_get_route_for_post( $post );
$remove_path = add_query_arg( 'context', 'edit', $rest_path );
return array_filter(
$preload_paths,
function( $url ) use ( $remove_path ) {
return $url !== $remove_path;
}
);
}
add_filter( 'block_editor_rest_api_preload_paths', 'acf_filter_rest_api_preload_paths', 10, 1 );
That said, if this still isn’t working for you – don’t worry – we’re still actively working on the issue to see if there are cases where this isn’t working.
This issue seems to be happening because the REST API endpoint preloading is somehow satisfying the enqueues, meaning they don’t happen to the block editor itself.
As a quick fix, something like this will work:
[Removed – see updated code further down]
But this might be a bit of a sledgehammer approach to solving the issue, but I wanted to get something over to you as soon as possible for those who wanted to stick on WP5.9.1
We’ll keep digging into this though, and give a further update shortly.
We’re investigating this issue at the moment. We’ll have an update for you shortly.
Hey everyone,
We’re aware of this issue and have reached out to the WPBakery team who need to update their plugin in order to allow secure access to ACF data.
ACF 5.11.3+ supports a filter you can add to your theme’s functions.php or a plugin which will fix the issue in the meantime:
add_filter( 'acf/ajax/shortcode_capability', 'acf_wpbakery_shortcode_capability' );
function acf_wpbakery_shortcode_capability( $cap ) {
if ( isset( $_POST['_vcnonce'] ) && wp_verify_nonce( $_POST['_vcnonce'], 'vc-nonce-vc-public-nonce' ) ) {
return 'exist';
}
return $cap;
}
We’ve seen errors regarding wp.media when a third party plugin is removing WordPress’s javascripts from loading. This is usually security plugins who try to prevent wp-media.js loading for some reason.
If you roll back ACF, does the issue get resolved, or is it possible another plugin update triggered it?
Thanks for the report. We’re aware of this issue – if you click any other widget or change field etc, it should trigger the re-render and make it saveable until we can get a proper fix released!
Hey Everyone,
As you’ve probably already seen, we made some significant changes in the ACF 5.11.2 release which should help mitigate the majority of issues you’ve been experiencing in ACF 5.11 and 5.11.1.
You can view full details in the changelog (https://www.advancedcustomfields.com/changelog/) and the acf field functions documentation (https://www.advancedcustomfields.com/resources/acf-field-functions/).
Hey @pstonge
Are you also registering the fields on admin_init? If so, you might need to set a priority hook for the get_field to be later than the registration.
Hey @kezily
Could you drop us an email to [email protected] with a copy of your block registration and template code so we can try to reproduce this?
Thanks!
Hey @rasso
We made changes in ACF 5.11.2 which should resolve this issue.
Try changing your action to ‘acf/init’ instead of ‘plugins_loaded’.
ACF might not be ready to accept registration at plugins_loaded.
Hey Rasso,
Thanks for the report here, I’ve confirmed the behaviour you’ve described.
We’ll look into this ASAP and I’ll get back to you once I have a fix or workaround.
@eaglejohn Any chance you could create us a temporary admin user on the site in question and email details over to [email protected]? I’m happy to login and take a look!
Your code there should be fine – is it possible a you’ve got a pre_get_posts query filter somewhere that is stopping ACF being able to load data about that field?
@eaglejohn Downgrading to 5.10.2 will solve the issue, or you can deploy the workaround fix at the bottom of https://www.advancedcustomfields.com/resources/acf-field-functions/ as a quick fix.
That said, your code there should be fine. Where abouts is that code? Is it in a template file, or a filter somewhere?
@floodlightdesign Hey, we updated the documentation at https://www.advancedcustomfields.com/resources/acf-field-functions/ to include a sample drop in function which will revert the functionality to the old unsafe output if you’re looking for a quick drop in fix.
@johannesalfanova-dk Thanks! I’ll let the ACF Extended developer know and see if we can figure out what’s going on here 🙂
@johannesalfanova-dk Are you having issues outputting those values on archive pages, or getting the data somewhere else in your code?
Hey @nickfmc,
I’ve just tested this and it’s working okay for me. Could you share your block definition code (specifically the supports key)
Hey @retroriff,
Where about is your code that does the get_field? Could you drop us an email to [email protected] with your code for that, and we’ll take a look?
The chances are, that code is happening before ACF has been initialised, and so ACF doesn’t think the fields exist.
Hey @cbrady23 – Yup, that’s likely to be the cause. If you wrap your code inside a hook that is acf/init or later, you should be okay! But please let me know if you need any further help!
Hello,
In @benjamin74’s case, the issue was they were using get_field in a plugin but not wrapped inside an action hook – so it was executing as soon as WordPress loaded the plugin’s php file, before ACF and WordPress had initialised properly.
This “worked” prior to 5.11, but incorrectly. Because ACF had no awareness of the field, it returned the raw data from the database without any processing or formatting, or obeying any options defined on the field settings.
I’m pretty sure the only places where this can happen are in a plugin, or in a theme’s functions.php where you get_field is being called before the “acf/init” action, so ACF is not correctly loaded. In the case of functions like acf_add_options_page, or acf_register_block_type, our sample code includes the requirement to make sure acf/init has happened – but as get_field and the_field are “template” code, the vast majority of instances of their usage is in templates – where you don’t need to worry about making sure WordPress and ACF is fully initialised already – we’ll make sure the documentation is clearer about this for the future.
Hey @ado-mic,
Could you confirm your ACF version where this is happening? Could you also record a screencast of the issue happening, as I’m not able to reproduce on the latest version on ACF.
We did make some changes in ACF 5.10 around media library errors to fix this in some cases, so it’s possible your issue is already resolved.
Thanks!
Liam
Hey again @kandb,
5.10.2 is now released. Could you see if your issues are resolved?
Thanks!
