Support

Account

Register Login

Forum Replies Created

  • @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:

    https://site-url.com/wp-admin/edit.php?post_type=acf-field-group&page=acf-settings-updates&force-update=1

    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.

    Thanks,
    Liam

  • 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.

    Thanks,
    Liam

  • Hey @zzaaxx,

    We’ve published some sample code as a gist which will let you debug this easier on the frontend: https://gist.github.com/lgladdy/e4cb5816c835b11dd2d8f482b16fdcb6

    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.

    Cheers,
    Liam

  • 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 https://support.advancedcustomfields.com/forums/topic/update-to-wp-5-9-1-breaks-media-selection/#post-152581 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(
		$preload_paths,
		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(
		$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.

Viewing 25 posts - 1 through 25 (of 60 total)
1 2 3