Support

Account

Register Login

Home › Forums › Bug Reports › Preview with ACF fields are incorrect

Solving

Preview with ACF fields are incorrect

  • Hi everyone

    I have had this issue always I guess.
    Though to the inconsistency and being busy – it has been an annoyance for a long time.

    Tested this with both classic editor activated, and also in Gutenberg.
    But the Preview of ACF Fields are just NOT ok. I hope there is someone at the core team reading this very soon.

    the_content() etc – those works just as they should
    But ACF Fields do not.

    Bedrock (latest of today)
    Acf 6.2.3
    Wp 6.4.1
    Tested with Posts (built in post type, that has revisions support)
    Tested in a Sage 10 theme
    Also tested in minimalistic hand crafted theme.

    You can have define('WP_POST_REVISIONS', true) or define('WP_POST_REVISIONS', false)

    The bug exists in both cases above – but in different ways.
    Both issues is not okey. This should be resolved.

    When set to FALSE:
    When post is published, and you do change an ACF field and the content values.
    – the_content() shows with updated value, get_field('text') does not. BUT WORKS PERFECT IF IN DRAFT MODE, NOT IN PUBLISHED

    When set to TRUE:
    When post is a new post, or a draft – not published. The bug is there. You can hit the “Save draft” as a workaround. BUT WORKS PERFECT IF IN PUBLISHED MODE, NOT IN DRAFT

    I have also tried this with the field key for the field – but that is not making a difference in any of the two test cases.

    This is a great annoyance for sure, and makes my client to prefer the use of Elementor instead.

    Can anyone shed a light? I believe this needs a fix in the ACF.
    I am up for sharing my screen and show my conclusions.

    There is also lots of hits on google, all with different solutions – and the replies are very varied. I guess it has to be that there are other factors, such as WP_POST_REVISIONS setting is vital in making users having different success. But they that do have success, also probably just shifts their problem for the “works with published but not drafts”, or the “works with drafts, but not published”.

  • I do have a solution that works for the case of WP_POST_REVISIONS is on, and supported by the post type. But the solution should be made in ACF, so it does not feel like the best solution as of now.

    Needs more testing, and I would like to find a way for preview to work for when WP_POST_REVISIONS is inactive, or the post type not supporting it.

    The recommendation should anyway to allow for WP_POST_REVISIONS to be set between 3-5 nevertheless.. if now revisions GUI with ACF fields even is a thing to use 😉

    AND one more thing.
    AUTO_SAVE that occurs by default every 60 seconds, that also do only save non-acf fields. That is a bummer. So the preview button still is needed to be clicked, rather than having you refresh the preview-tab. But that is not “that” much of a problem.

    One solution is to have a refresh button in Preview-page that opened – so that refreshes that easily though, and can perhaps also compare timestamps.. but making a content-check for complex pages to assure that the “refresh”-symbol should take a “You have new preview-data, refresh” seem to be to complex.

  • Update.
    Have tried two common suggestions.

    #1 CamiloAPR
    I havent fully tested the code above in detail.
    But the BIG downside is that CamiloAPR’s function to fix this – also kills all ‘options’ fields instead, bot in preview, and none-preview. Tried some changes to that function – but that did not end up solving the issue. So a no no solution.

    #2 Ivan D
    This code did not help. I can see that the code is injected in the source code. So it is not that – it just does not help.

  • CamiloAPR’s solution does indeed cause other ACF contexts to stop working, such as options, ACF blocks, etc.

    Here’s my solution that simply checks to see if the $post_id being passed in is for a “single” post along with is_preview() and otherwise doesn’t attempt to intervene:

    
/**
 * Fix ACF post ID when previewing draft posts.
 *
 * In preview mode, WordPress uses the latest revision/autosave ID, which may not contain the updated ACF meta field data.
 *
 * This support thread got me halfway there, but it had to be modified to only interfere if the post ID is a single post, otherwise fields inside ACF blocks and other contexts don't work.
 * https://support.advancedcustomfields.com/forums/topic/preview-solution/page/3/#post-134967
 *
 * @param null|int $null    The value to return. If null, then the ACF plugin will figure out the context itself.
 * @param int      $post_id The "post ID" to check. Can be a post, but can also be any number of other ACF contexts.
 */
function fix_acf_post_id_on_preview( $null, $post_id ) {
	// Only intervene if the post_id is a single post and we're in preview mode.
	if ( is_single( $post_id ) && is_preview() ) {
		// Get the actual post ID instead of the current revision ID.
		return get_the_ID();
	}

	return $null;
}
add_filter( 'acf/pre_load_post_id', 'fix_acf_post_id_on_preview', 10, 2 );

  • Hi cr0ybot.

    I have not yet tested your way as of now, I heard that there was an update for the preview feature with the 6.2.6 release.

    But seems to have some issues. In a published page/post, it seems that from the second time of hitting “Preview changes” – it works.

    But not the first time. If you reload the page/post you are editing. Then you still have to hit the preview button once – to make it work from the second preview click and forward on.

    It has blown my mind that there has been so many years without the developers not getting it right. Otherwise a great plugin for making sites of course!

  • @hejamartin

    It has blown my mind that there has been so many years without the developers not getting it right. Otherwise a great plugin for making sites of course!

    You mean since WP Engine purchased ACF in mid 2022 😛

  • Unfortunately, this has been an issue way longer back.

    I have made them a ticket, describing in details in which use cases the Preview-feature that does not work, and when it works.

    So knowing the problem – makes the solving much easier.
    But they have not even replied me yet for a couple of weeks – and I did put 40 hours to test various conditions and different things to really get to bottom with this.

    It all comes down to how revisions are internally organized within the WordPress core – but the solution is not that hard – but they still have the job to do.

    I have been using ACF since the very beginning 😉

  • Just to add that this isn’t working for us either with revisions enabled on ACF Pro 6.2.8.

    I can see the revision ID gets returned by $post_id = apply_filters( 'acf/validate_post_id', get_the_ID(), false ); but get_field() returns NULL a value.

  • We are having this issue as well. The fix provided by @cr0ybot did work for some time I believe but not anymore. Now the status of this topic is ‘Solving’ but I’m not sure if it’s been in that status for a long time. Does that mean the ACF team is on it?

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

You must be logged in to reply to this topic.