Forum Replies Created

  • Due to the way select2 works, we’ve had to disable html in select2 results by default, restoring the default select2 behaviour.

    Instead, you need to manually override the escaping function using a JS filter for a specific field type, key or name.

    You can find more information on this here:

  • Hey folks,

    Could you all please contact [email protected] so we can run through some debugging and get copies of your field groups etc?

    We’ve not have a reliably reproducible case of this bug yet, so you can help us get to the bottom of it and we’ll sort out a patch in an upcoming release.


  • Hey there,

    Please reach out to Elementor for this. ACF is still returning the same types it always has, so this is an error their side.


  • Hey there,

    We’re aware of this issue and have it on our backlog. It only affects the legacy version 1 of ACF Blocks, so if you upgrade to v2, you’ll be good as this wrapper doesn’t exist in ACF Blocks v2 – but we’ll have it fixed up in a future release if you don’t want to change.

  • Hey there,

    You’re best off contacting our support team for this rather than the community forum, as users here won’t be able to know any details of your account.

    This error happens when, during an update check, the plugin is told your license isn’t valid for the current site URL. This can happen if you’re using a multi-lingual plugin or some other way to serve one site on multiple URLs.

    Alternatively, this can also happen if there is a technical issue when checking for updates. If that’s the case, manually checking for updates again via “Check again” on the WordPress updates page will force a refresh, and then updates may work.


  • Hey folks,

    We managed to get this fix into 6.3 just before release. Could you confirm it’s working correctly now?


  • We’re aware of this issue which happens in the update thread due to PHP opcache storing the old version of an updated ACF Class.

    Unfortunately, there’s no way to resolve this other than performing a one-off manual update to get past the update. While the error will still happen for you in the update thread, it is only present for the update and no end user will ever see the error. You’re free to ignore it and everything will work find on the next page load.

    SPM detects the PHP error triggered in the update thread and performs a rollback for protection.

  • Hey, thanks for the report here…

    I’m looking into this now and I’ll try and get it fixed in a upcoming release.

  • @taupecat Thanks for confirming! I’ll keep you updated here as we work through making sure this doesn’t happen again.

  • Additionally, we think these errors are cached results of update checks, which you can resolve by forcing an update check on ACF’s updates page, or by calling:

    If you try this and it does work, please let me know!

  • @taupecat We’ve not seen any cases where PRO features are actually disabled, the error seems to be separate to that?

    Are you unable to create options pages or edit pro fields? If so, could you email [email protected] with more info, feel free to make it for my attention (Liam) and we’ll get to the bottom of this immediately.

    You shouldn’t need to change anything about sites, as the next update should correctly remove the error, but obviously if you are unable to use PRO features we’ll need to fix this sooner for you.


  • Hey everyone,

    Really sorry about this error. We had an API outage earlier today which ACF is caching the error state incorrectly. We expect this error to resolve itself within 24 hours when the next update check happens.

    If anyone with the error could share their database options (in wp_options) starting acf_pro_ to us in support via [email protected] that would be very helpful here to make sure we understand the case.

    We’re working to make sure this doesn’t happen again, and make sure the error is more sensible than a generic “something went wrong” error.


  • Hey @zzaaxx,

    We’ve published some sample code as a gist which will let you debug this easier on the frontend:

    It will output a backtrace where the error is happening, so only useful for local development instances.

    Could you let us know what the raw value is for the second row in that repeater? It is likely to be some other character which has become a safe htmlentity.

  • Hey Glen,

    We’ve had this thought too, and even played around with some proof of concepts here – but we’re not happy with the fixed width of the sidebar; some field types literally do not work properly in such a small space.

    We’ve also had some initial discussions with the Gutenberg team about this problem. Whilst we can invent some kind of new expanding UI which would handle this, we’d much rather try and get the block editor to consider our use case so all plugins have the ability to handle this case properly.

    We’ll have more on this in the coming months as we begin to modernise our block editor experience into a more native feel.


  • As far as I can see, this issue should only occur if you’ve got the same ACF group JSON in multiple places, in which case we’ll use the last one.

    If you’ve only got it in one folder, this issue won’t occur.

    We’ll dig in the code here to see if we should still add that break for efficiency, but having the same ACF JSON file in multiple places read or written from ACF is not supported and unexpected things may happen!

  • Hey @blakemiller,

    You’re mixing up filters here. save_paths doesn’t support a type argument, as it’s for filtering the whole array, although we do pass you in the post as an argument so you can detect if it you like:

    apply_filters( 'acf/json/save_paths', $paths, $post );

    Alternatively, you can use the save_path (no s) setting with a type argument, so something like:

    add_filter( 'acf/settings/save_json/type=acf-post-type', 'set_custom_json_save_path_for_post_types' );
    function set_custom_json_save_path_for_post_types() {
    	return get_stylesheet_directory() . '/acf-json/post-types';

    We have to keep both around for backwards compatibility, so sorry it’s a bit confusing!

  • Hey there,

    Setting “mode: edit” in your block will only set the default mode that should be used for the block. If you then want to disable the toggle, you need to set “supports: mode: false” in your block.json too.

    	"apiVersion": 2,
    	"name": "acf/home-solutions",
    	"title": "Lösungen (Home)",
    	"description": "Der Lösungen Bereich - nur für die Startseite",
    	"category": "xxx",
    	"icon": "star-filled",
    	"keywords": ["home", "lösung"],
    	"acf": {
    		"mode": "edit",
    		"renderTemplate": "home-solutions.php"
    	"supports": {
    		"align": false,
    		"mode": false,
    	"style": ["file:./style/home-solutions.css"]
  • Hey everyone,

    We’ve rolled out a fix for this as part of ACF 5.12 which was released just now.

    The fix is slightly different to what we worked on in this thread, as disabling the REST preloads also stopped block preloading from working. So our approach disabled edit mode block preloading only for now, which is what triggers the issues with enqueues not working correctly.

    If you added the test code earlier, you can go ahead and remove it! If you’re still having issues, let me know.

  • Yeh I agree excluding autosaves is needed, the current code in should solve that issue.

    I had concerns disabling autosave preloading would break autosaves altogether, but it seems WordPress doesn’t dynamically load anything into the editor from an autosave anyway – it only redirects you over to the autosave URL; so there shouldn’t be any issues removing the preloads.

  • Just an quick update, this issue will work – but as @dominik_fuchshofer suggested, if there is a current autosave it will still be broken.

    We’ll need to do some more internal code changes to handle autosaves – but disabling them as Dominik’s code should solve the issue for now, while we can get the release ready.

    Could you try the following code, and see if you have any issues?

    function acf_filter_rest_api_preload_paths( $preload_paths ) {
    	global $post;
    	$rest_path    = rest_get_route_for_post( $post );
    	$remove_paths = array(
    		add_query_arg( 'context', 'edit', $rest_path ),
    		sprintf( '%s/autosaves?context=edit', $rest_path ),
    	return array_filter(
    		function( $url ) use ( $remove_paths ) {
    			return ! in_array( $url, $remove_paths, true );
    add_filter( 'block_editor_rest_api_preload_paths', 'acf_filter_rest_api_preload_paths', 10, 1 );
  • 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(
    		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.

Viewing 25 posts - 1 through 25 (of 68 total)