Flexible Content field resets itself about acf HOT 19 OPEN

Hi @BB-000

Sorry to hear about the issue. This is definitely something I would like to help fix.
Can you please open a support ticket via the following link so we can discuss?
https://www.advancedcustomfields.com/contact/

It would be great if you could provide me with a copy of your field group data - Exported .json or the acf-json/ file.

from acf.

I'm running ACF PRO 5.6.4

from acf.

I believe I am having the same issue. I'll create the different layouts with their subfields in the correct place. After a while the subfields will all move to the first layout and the following layouts will be empty.

from acf.

Hi guys

Thanks for the bug report.
This is very odd behavior and suggests that the 'parent_layout' data for each sub field is getting corrupt/removed.

Be sure to let me know which ACF or ACFPRO version you are running. I'll try to replicate the issue locally.

from acf.

I'm also using ACF PRO 5.6.4.

Maybe this has something to do with it:

• When I have two tabs open and editing on both (tab 1: editing a page, tab 2: editing a custom field), it alerts me if i want to stay on the other page when I hit publish/update on either tabs

from acf.

Hi guys

Thanks for the replies.
I'm not able to replicate this just yet so I wonder if there is another variable at play.

Can you please keep trying to replicate the issue (perhaps with a new field group) and let me know if you can spot any patterns?

from acf.

I think my issue was similar to @eltongonc in that if I had the Field Group open in one tab and the page I was editing in another, and I updated one of the pages they would both reload. I think this is when the issue would occur.

I'll try and test this out more to get a better idea of if this is the actual cause of the problem.

from acf.

More testing confirms my suspicions, at least for my case.

When the page for the field group is open in one tab and the page that I'm editing that contains the field group is open in another tab, the fields can become corrupted when one page is submitted. This causes the other tab to refresh and that's when the data becomes corrupted. Usually it seems like all the fields get collapsed into one layout. Sometimes if a field had information saved to it in the page, it'll pull that information into the 'instructions' section for that field.

This is all been on my localhost set up; so I'm not sure how it behaves when on a live production site! I hope this helps. Let me know if there's any additional testing I can do!

from acf.

Hi @kculmback, thanks for the reply.

This causes the other tab to refresh and that's when the data becomes corrupted.
Can you elaborate a bit more on this? Why would a browser tab refresh itself when submitting a form from another tab?

from acf.

I have been able to produce this issue but it was when I was using a browser synced url and editing custom fields. Simple fix was to make sure I wasn't editing ACF fields from a browser-synced url.

from acf.

Hi @TormentedTeddy

Thanks for the info. Can you please elaborate more on a browser-synched url?

from acf.

Sorry for the delay...

When using gulp as a build tool for a theme, and using browser sync to reload the page or inject the new assets, if you have two windows opened, that are both browser synced, that are both logged in to wordpress, and begin editing fields groups in ACF, both browsers will perform a post and corrupt the field group structure.

from acf.

Hi @jmstopper

Thanks for the info.
Can you investigate this further by finding the most simple way to replicate the issue.

• Does it matter which page is loaded on both tabs (dashboard, edit post, etc).
• Does it matter if a page has recently been published (refresh may repost data).

I'm not sure if this is something I can fix from my end if a 3rd party app is triggering a reload $POST data, but I'm happy to help learn more about the issue.

from acf.

@elliotcondon I don't believe this is an ACF issue and is more just a side effect of having two browser windows executing the same actions (click, scroll, posting).

Will test and get back to you

from acf.

Thanks for the feedback @jmstopper,
That may be the issue indeed as I was using Gulp with browsersync when this issue occurred. I was reading into the documentation of browsersyc. I'm curious! does changing the port to a less generic one on ACF browersync settings affect the outcome? https://browsersync.io/docs/options

from acf.

I just ran into the same strange issue.

Observations:

• Browser sync or similiar wasn't running
• I edited the field group in Tab A and checked the group in Tab B (Location Post; post-new.php)
• Whenever I saved the fieldgroup in Tab A all fc layout subfields wandered to the first fc layout
• I did not hit save/publish in Tab B
• I reloaded Tab A and Tab B multiple times
• I recreated the fc field
• It worked after I closed Tab B
• I could not replicate the problem by reopening Tab B / post-new.php
• Tested with 5.7.0-beta2

from acf.

I'm also having this issue. I did the following:

• exported a field group as json
• deleted the field group
• imported the field group again
• added a new field to the second layout of that field group
• hit publish

Then the new field that I added to the second layout had moved to the first layout. The original 3 fields in the second layout were still there (the ones loaded from the json file) but any new ones that I add get moved to the first layout. This happens every time and I only have one browser window open.

I was able to fix it, by:

• exporting the custom field (with the fields in the wrong place) as json
• editing the json file, moving the new fields from the first layout to the second
• importing the json file

This moved the fields back to the second layout where I'd originally created them. They remain there (so far) but when I try to add a new field, that new field moves back to the first layout again so the bug is still there - I just have a workaround.

Originally found this in 5.6.4 PRO, upgraded to 5.7.0, same issue.

from acf.

I've just had this issue, how it happened to me:

Local dev site, added one new subfield to flexible content field, this updated the acf-json file

Pulled this (acf-json file) to live site. I had a couple of wp-admin tabs open, page editor and field groups

Went into the field group on the live site to check if it had updated. Sub fields all gone on live site. On the page editor, the field group is now empty. All pages using this field type are broken on the frontend

Put the live db onto my local site to check it wasn't a server php 'max_input_vars' issue as I had read elsewhere it may be. Fields gone still

Currently I've somehow got to a point where my local and live site now have slightly different issues.
Live site: in 'edit field groups' if you go to edit the field, all the subfields are gone. However on the page editor, the fields and previous values are all there.
Local site: It's almost the opposite. The field groups are there in 'edit field groups', but the page editors fields are all empty and completely field-less. Strange!
Edit: on local, I added a new field to the field group, and the page editors now show the correct ones, including the new field. Not sure why/how

Haven't been able to get them back...:(without completely rolling back database)

Should it not be getting the fields from the acf-json anyway? (this file looks fine, I have also tried rolling this back to before I added the new field)

ACF 5.8.4

from acf.

@elliotcondon Amazing support thank you, will do :)

from acf.