Support

Account

Register Login

Home › Forums › General Issues › Custom Fields on post Preview

Solving

Custom Fields on post Preview

  • Anyone else having this issue? I just updated WordPress to Version 5.5.2 and Custom Fields to 5.9.2. When previewing posts the data in the ACF fields on the post no longer appear. When I Publish the posts the fields display properly. This never happened before. Seems it must be something with the updates.

  • Yep – we just updated WP and preview is not showing ACF fields anymore. Please fix!

  • I was going through my plugins and ACF Pro said it needed to be updated. But when I called up the New Version 5.9.3 details, it had a warning at the top:

    Warning: This plugin has not been tested with your current version of WordPress.

    …and also said it’s compatible up to WP 5.5.1 (we’re on 5.5.2 now, no way to change either).

    Please keep your plugins up to date/compatible with the latest WP version.

  • I’m having this issue with 5.9.3 and WordPress 5.6.

    Anyone else?

  • thanks boss

  • I found the solution in another thread:

    https://support.advancedcustomfields.com/forums/topic/preview-solution/page/3/#post-136816

  • The solution of https://support.advancedcustomfields.com/forums/topic/preview-solution/page/3/#post-136816 does not work for me. Then the “merge” filter does not work anymore.

    When will this problem be fixed? It took already years, as I can see in several bug tickets …

  • Really hoping for a fix for this. I’m a little suprised it’s taking this long.

    The suggestion of using get_post_meta() instead of get_field() is kind of lame since get_field is kind of essential to using ACF 😀

    I wish you efficient bug hunting!

  • In case you stumble upon the aforementioned solution at https://support.advancedcustomfields.com/forums/topic/preview-solution/page/3/#post-136816 and need to fix your options fields this slightly modified snippet worked for me:

    function fix_post_id_on_preview($null, $post_id) {
    if (is_preview() && $post_id !== 'options') {
        return get_the_ID();
    }
    else {
        $acf_post_id = isset($post_id->ID) ? $post_id->ID : $post_id;

        if (!empty($acf_post_id)) {
            return $acf_post_id;
        }
        else {
            return $null;
        }
    }
}
add_filter( 'acf/pre_load_post_id', 'fix_post_id_on_preview', 10, 2 );

    Obviously works only if you’re using ‘options‘ in your get_field calls, not the singular ‘option’.

  • Addition (can’t edit):

    If you’re using ACF Blocks, you’ll need this snippet

    function fix_post_id_on_preview($null, $post_id) {
    if ( is_preview() && $post_id !== 'options' && substr( $null, 0, 6 ) != 'block_' ) {
        return get_the_ID();
    }
    else {
        $acf_post_id = isset($post_id->ID) ? $post_id->ID : $post_id;

        if (!empty($acf_post_id)) {
            return $acf_post_id;
        }
        else {
            return $null;
        }
    }
}
add_filter( 'acf/pre_load_post_id', 'fix_post_id_on_preview', 10, 2 );

  • TL;DR: Use the long code block half-way down to fix this.

    I was stuck on this issue for a while. Jann’s solutions above are good, but even with edits some fields broke; they’d always work in some places, but not others. I think the problem with the previous solutions is that, by hooking into acf/pre_load_post_id and short-circuiting it with a fixed post_id, you’re preventing the native ACF code from locating the correct post ID via its function acf_get_valid_post_id.

    Finally, I found the actual cause of this issue. It’s called from the end of that acf_get_valid_post_id function, via the filter acf/validate_post_id (in includes/api/api-helpers.php)

    This filter calls the class method acf_revisions::acf_validate_post_id (which is found in includes/revisions.php — search for acf_validate_post_id).

    The problematic code in acf_validate_post_id starts with the variable $revision on line 377, and ends at line 384 (ACF PRO v5.11) — comment out that block, and previews work correctly. See the attached screenshot for this in context.

    So, the solution is to stop that block of code from running, by removing the filter which runs it:

    // Fix a long-standing issue with ACF, where fields sometimes aren't shown
// in previews (ie. from Preview > Open in new tab).
if ( class_exists( 'acf_revisions' ) )
{
	// Reference to ACF's <code>acf_revisions</code> class
	// We need this to target its method, acf_revisions::acf_validate_post_id
	$acf_revs_cls = acf()->revisions;

	// This hook is added the ACF file: includes/revisions.php:36 (in ACF PRO v5.11)
	remove_filter( 'acf/validate_post_id', array( $acf_revs_cls, 'acf_validate_post_id', 10 ) );
}

    Removing the filter works in all the use cases I tried, although I’ve only tested in a Gutenberg environment, and haven’t checked if it works with the Classic Editor plugin yet.

    It’s a somewhat nuclear fix, as it removes the other code related to previews — but it doesn’t prevent non-preview code from running, like filtering acf/pre_load_post_id does.

    I think this is a core ACF bug that needs addressing.

    Also, when the code mentioned above was added in 5.5.10, I don’t think the code should have been put into the filter acf/validate_post_id — in the version before that (5.5.9), that filter wasn’t used internally, and currently, it’s used exclusively for previews (bailing immediately if preview is not in $_GET). So if it needs to stay in ACF core, it should be moved to a method that’s more aptly named.

    Notes for posterity:

    The whole filter code was added in 5.5.10. The changelog mentions an issue with previews:

    Core: Fixed bug preventing values being loaded on a new post/page preview

    Before 5.5.10, in version 5.5.9, the filter acf/validate_post_id wasn’t used internally, with extra code being used in the function acf_get_valid_post_id (in api/api-helpers.php) instead. See the second screenshot for the old code.

    acf_validate....png
    acf_get_vali....png

  • Not sure if this forum is actually maintained. Delicious Brains has acquired ACF and I’m wondering if they will set up a new forum? Wouldn’t it be awesome if their devs were mining this forum for all the enhancements and fixes we’ve dreamed of for years?!

    I’m bookmarking this post, though, because some Serious Brains have worked out solutions. Thanks everyone!!

  • @intrepidrealist I don’t think that DB has any intentions of setting up a new forum, or if they have they haven’t informed me.

    This is a user to user forum, the developers rarely visit this forum except for just after new releases and they watch for things that might be bugs caused by the release.

    All bug reports and feature requests should be submitted directly to the developers.

  • Thanks John!

  • darkly77’s solution worked for me in ACF PRO 5.12 where Jann’s ‘acf/pre_load_post_id’ filter solution did not. The ‘acf/pre_load_post_id’ filter wasn’t working when using get_field on terms, resulting in this error:

    
PHP Fatal error:  Uncaught Error: Object of class WP_Term could not be converted to string in /public_html/wp-content/plugins/advanced-custom-fields-pro/includes/acf-value-functions.php:77

  • The options doesn’t work with the above fixes. I hooked to the hook in the end and simplified abit and it seems this works all the way: previews, blocks, post acf fields _and_ options:

    
function fix_acf_field_post_id_on_preview($post_id, $original_post_id)
{
    // Don't do anything to options
    if (is_string($post_id) && str_contains($post_id, 'option')) {
        return $post_id;
    }
    // Don't do anything to blocks
    if (is_string($original_post_id) && str_contains($original_post_id, 'block')) {
        return $post_id;
    }

    // This should only affect on post meta fields
    if (is_preview()) {
        return get_the_ID();
    }

    return $post_id;
}
add_filter('acf/validate_post_id', __NAMESPACE__ . '\fix_acf_field_post_id_on_preview', 10, 2);

  • I have also been having this issue on my custom post types and I noticed that removing preview=true from the url query strings shows all the ACF custom fields.

    I am using WP 6.4.1/ ACF PRO 6.2.2.

  • I’m having this problem on pages and it seems to happen seemingly randomly depending on who the last person was to change the draft post. Simply re-saving the draft sometimes fixes the problem.

    I did implement @niq1982 fix and that seems to solve the issue. Hopefully somebody fixes this soon because it makes it nearly impossible to draft post for review with any level of confidence.

    I am using WP 6.4.1/ ACF PRO 6.2.3.

  • UPDATE, @niq1982 code doesn’t work if you are using a get_field() where you actually specify the post_id (e.g. get_field(‘field_name’, $somePostID) ).

    I was able to fix this by checking if the $original_post_id is indeed a revision of the $post_id.

    function fix_acf_field_post_id_on_preview($post_id, $original_post_id)
{
    // Don't do anything to options
    if (is_string($post_id) && str_contains($post_id, 'option')) {
        return $post_id;
    }
    // Don't do anything to blocks
    if (is_string($original_post_id) && str_contains($original_post_id, 'block')) {
        return $post_id;
    }

    // This should only affect on post meta fields
    if (is_preview()) {
		if ( $original_post_id !== $post_id ) {
			// Check if $post_id is a revision
			$parent_post_id = wp_is_post_revision( $post_id );

			if ( $parent_post_id === $original_post_id ) {
				return get_the_ID();
			}
		}
    }

    return $post_id;
}
add_filter('acf/validate_post_id', __NAMESPACE__ . '\fix_acf_field_post_id_on_preview', 10, 2);

  • my workaround is to call wordpress core function get_post_field instead of get_field that was not working in draft posts and then treat the response differently

    if('draft'==$post->post_status){
		$image=get_post_field('image',$post->ID);
		if($image){
			$image=...;
		}
	}else{
		$image=get_field('image',$post->ID);
                if($image){
			$image=...;
		}
	}

  • Opened a Github issue regarding this:

    https://github.com/AdvancedCustomFields/acf/issues/903

  • Polyester is less prone to shrinking than polyester versus polypropylene. Polypropylene may shrink when exposed to high temperatures during washing or drying, while polyester retains its shape and size better.

Viewing 22 posts - 1 through 22 (of 22 total)

You must be logged in to reply to this topic.