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?

  • Hey everyone,

    Not sure why ACF hasn’t put more priority on this annoying issue, since it’s been going on for years. That said, I’ve created a workaround. It’s super hacky and not ideal, but it works.

    Basically what this does is intercept the Preview button’s click event, sends the form data to an Ajax function that creates an autosave, and once that’s done it triggers a click on the Preview button. After the first click it removes itself, so it’ll only do this once.

    Here’s the javascript that needs to be included in the admin area:

    jQuery( ( $ ) => {

	let previewBtn = $( '#preview-action .preview' );

	if ( previewBtn.length ) {

		let previewIntercept = $( '<span id="preview-action--trigger" style="position: absolute; left: -1px; right: -1px; top: -1px; bottom: -1px;"></span>' );

		previewBtn.css( 'position', 'relative' ).append( previewIntercept );
		previewIntercept.click( ( e ) => {

			const formData = new FormData( $( '#post' )[0] );

			formData.set( 'action', 'create-preview-autosave' );

			$.ajax( {
				url: ajaxurl,
				method: 'post',
				data: formData,
				cache: false,
				contentType: false,
				processData: false,
				success: () => {
					previewIntercept.remove();
					previewBtn.trigger( 'click' );
				},
			} );

			e.preventDefault();
			e.stopPropagation();

		} );

	}

} );

    And here’s the WP Ajax function that should go in functions.php or wherever you want:

    add_action( 'wp_ajax_create-preview-autosave', function() {
	wp_create_post_autosave( $_POST );
	header( 'HTTP/1.1 200 OK' );
	wp_die();
} );

  • All solutions are bad – when not coming from the WPENGINE team.

    But still, this is a good one. I have said to my clients that “click preview a second time if you do not see the preview correctly”.

    But your solution – it should also only be needed if the post has zero revisions I guess? Which you could check for, and then add this extra step.

    I like the “frontend” approach to this, instead of the more hacky php ways with actions/hooks.

  • @hejamartin I totally agree. Not sure why they’ve let it go so long…

    For us this happens on all our sites for all posts, even those with revisions already, so I didn’t add in any checks for the number of revisions.

    Oh also in the javascript that const formData should be let formData.

  • Just hopping on this thread to say thanks to gavin310 for their workaround/fix on this issue. It’s a shame the direction ACF has been going since WPE/DB bought it.

  • I made some updates to the javascript so that it shows a small loading icon inside the preview button until the ajax request is finished. It makes it feel a bit less hacky I guess 😉 For some reason it’s not letting me post it here, so you can get it here: https://pastebin.com/wGNttfSV

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

You must be logged in to reply to this topic.