Support

Account

Register Login

Forum Replies Created

  • Hey there, we had some fixes to make our side which we did in 6.4.0.

    This issue hasn’t come about because of an ACF update, however – it’s WordPress 6.8 which has triggered the error. Our fixes brought our core to be compatible with WordPress 6.8, but the error can still happen if your code triggers ACF to initialise early. We could prevent ACF ever initialising early, but that would result in broken sites, rather than sites with warnings, so it’s definitely not the best option here.

    We’re looking at adding a _doing_it_wrong additional notice in our next release if you trigger this error, which would help you figure out where the problem is in your code at the expense of double the notices.

    For now, your best bet is to check your functions.php file for get_field or acf_add_options_page as they tend to be the two places we’ve seen most commonly trigging this.

    Thanks,
    Liam

  • Hey folks,

    If you’re getting this error, and you’ve upgraded to ACF 6.4.0, it means you’ve code in your custom plugins or theme that is forcing ACF to initialise too early.

    This is likely to be called like get_field or acf_add_options_page.

    Once you’ve found the ACF calls which are happening too early, you can wrap the code in:
    add_action('acf/init', function() { [existing code] });

    to resolve this error.

    Thanks,
    Liam

  • Hey there,

    ACF doesn’t do any processing or parsing of any assets defined in block.json’s core asset handlers, so any issues here will either be core issue, or something specific to your theme or site.

  • Hey,

    Solving is a default state for posts once they’ve had a reply. It doesn’t mean anything related to our backlog as this is a community support forum.

    Feature requests should be made on advancedcustomfields.com/feedback and bugs reported via the support team.

    That said, this isn’t something we can fix our side. We use the WordPress provided logic here. The code sample provided above, using parse_blocks would be incredibly inefficient to do on a production site as it’s very expensive, and you’ll be parsing the whole page twice essentially.

    The way blocks render, it’s not really viable for this to possible as blocks work without awareness of each other, outside of context – but if it were to become so, it would need to be provided by Gutenberg.

  • Hey there,

    We believe this issue happens on hostinger with their latest version of their plugin. They’re leaking styles to apply to the whole of the WordPress admin.

    Please reach out to them if you’re running the hostinger plugin, and if not please open a support ticket so we can dig deeper.

    Thanks,
    Liam

  • 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: https://www.advancedcustomfields.com/resources/javascript-api/#filters-select2_escape_markup

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

    Thanks,
    Liam

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

    Thanks,
    Liam

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

    Thanks,
    Liam

  • Hey folks,

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

    Thanks!

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

    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 );
Viewing 25 posts - 1 through 25 (of 73 total)
1 2 3