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.
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 😉
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!
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.
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.
And no – your solution do not work.
Tried to add your code to my test cases, but unfortunately not.
Hi. I made a lengthier post in the Bug forum right now.
Not giving a solution – but with more details about the problem.
You can “upvote” it by commenting on it – since I hope they can address this issue in the very near future.
But in your case – is the acf field and WP meta being treated the same.
If the error is in ACF, then I am more positive to the ACF-team patching it.. if it is WP team.. then I will abandon wp and acf for other alternatives (okey, I wont.. but leaning towards it at least…)
Hi. I made a lengthier post in the Bug forum.
Not giving a solution – but with more details about the problem.
You can “upvote” it by commenting on it – since I hope they can address this issue in the very near future.
Upvote for this. Very stupid thing.
It works different if you have WP_POST_REVISIONS to true or false.
But in either of them, the preview is faulty – but in different ways.
Gonna start a new thread about this.
Hi John,
I got the same problem as the owner of the thread.
It is solved by using WP Migrate Lite, in which also replaces serialized strings in the database.
Which then also solves the Page Link component in ACF.
But my problem, is that on local machine, I use port 8080 and 3000 (3000 for webpack/hmr-tooling).
So this is still causing problem locally, but your root-relative snippet is a dream to fix this.
Does this filter hook up when you save your post?
And should it not be much more efficient to use the php to figure out the current HOSTNAME (domain) instead of hardcoding your domain?
It is the Field_Key unfortunately.
I guess the newer versions of AFC has more random generation of the field_keys.
I guess I would like to have a “database upgrade”/”upgrade” or a “Fix duplicated field keys”-button/function to solve this.
Making a database-hack, and many manual steps to fix this does not seem like a solution that I would feel confident in. Even though I understand somewhat steps on how to achieve a fix.
There should be an internal check which could be viewed within the admin about notices/warnings.
I remember this as a problem earlier when importing/exporting ACF groups from places, or the need for duplicating etc etc.
I wish this could be added some more checks in current version as well, especially when it comes to upgrades and other things like that 😉
I might have made a discovery here, but am not sure.
I got a field_8 used in another ‘Field Group’ as well.
Must they be totally unique?
I guess so?
It worked with the 4.x ACF though, but the upgrade now might have thrown in some issued of course.
So I got like this now:
Galllery Field Group > img (field_8)
Interest form Field Group > maxRent (field_8)
How can I make the field_8 for the img gallery to be completely unique?
Do I have to make changes in database, or is there a better way?
the field_8 is a plain simple Text field, and I got like many fields, causing no issues else where..
For ACF Pro I mean.
Got the same problem. I had to revert back one or even two minor versions.
This would be lovely to have fixed ASAP.
Thanks
I was helped out by this comment:
“We had to check
– “Translate” for “Fields Group” and
– “Do nothing” for “Fields””
I am working most with repeaters, and dynamically added fields. I guess these populated fields are being a little cumbersome sometimes – since there is a “dont translate”, “copy”, “translate” setting for each field generated.
Sometimes I of course wish to copy all content from the originating language – especially when repeaters are used – since the new language most often want the same structure.
I have been running some javascript in the Chromes Console. So that ALL fields-labels in “Settings for Multilingual content” easily can be set to “copy”-mode, and then revert them all to “Translate”. Since these settings for each field otherwise must be done one by one.
But it is not a optimal solution, if there only were a few custom meta-data – then it is no problem. But my sites tends to be built with repeaters, blocks, columns – and all through ACF of course (WordPress would not be cool if there were no ACF 😉
Hi.
Is there any ongoing development to solve this issue?
I just want to say hi – and hope to speed this up.
Am thinking of that the problems with the combination of acf and wpml really is a huge advantage since both of these plugins makes WordPress so powerful.
My concern is the “Settings of Multilingual content” that comes with WPML. But since Elliot is the true magician – I hope he/you can solve this.
But I also has these problems, that translated pages is having a hard time “copying content” from repeaters, as well as adding new blocks in other languages.
I know WPML and ACF does not really add up to a great combination in every moment, but I wish to make it a little more streamlined.
Yes, I am talking about that wp-admin listing page.
I am using the Admin Columns plugin, and that one works well.
My client would like to search for texts sometimes that are in “text”-“textarea”-fields – because there are more than 200 entries already.
The optin now would perhaps be to build a front-end page, or to restrict the usage of textareas and move “keywords” more to more controlled fields like in radiobuttons or categories etc.
But the ideal solution would that the search-form in /wp-admin/’s custom posts listings should go through the entries as expected.
Thanks for your response, I can understand that this is nothing that you will look more into. But if you do take a look at how the wordpress-search can search entries with AFC-fields, then please do ;
Thanks.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.