Home Forums Bug Reports Clone field JSON saving bugs


Clone field JSON saving bugs

  • I’m experiencing several issues with JSON saving related to clone fields. Here’s what is happening:

    1) I have one clone field that clones the entire group it is in, either directly or via a second group with a single clone field that targets the original group (I’ve tried both methods). Using either method, if the field is marked as “seamless” importing the JSON file causes the group to show up with 0 fields. However working directly off the JSON file works fine, as does the original setup as first created (not imported from JSON).

    2) Occasionally other clone groups (all marked as seamless), are replaced with the content of the actual fields when saving the JSON file. I have a standard “options” field that gets repeated in a flexible content, and every now and then the JSON file will be saved with nothing but the last field having the options, and those options will be saved as real fields instead of as a clone group (the entire clone group is copied into the group referencing it). The other options fields in other layouts are simply gone.

    I am having less issues with the “group” clone fields, however it seems to be impossible to access repeaters inside of grouped fields (using have_rows() / the_row()), as a feature request I’d like it if grouped clone fields functioned as 1-row repeaters for use with have_rows(), so that any contained repeaters / flex fields can be accessed normally inside them. For my purposes the grouped fields don’t work well, but the seamless fields are extremely buggy.

  • This reply has been marked as private.
  • This reply has been marked as private.
  • I can confirm I am having the exact same issue. Every time I import a field group that uses clone fields the clone fields aren’t present screen when editing that field group but are still visible within my acf-json files and on the page they were meant for. Any editing done to that field group removes them however.

  • I just tried creating a simple field group with cloned fields, exported the group with the cloned fields as well as the group that is being cloned. I then imported this export and everything seems to be working fine.

    there is nothing that I can do with the json code you posted into the content editor, it has been altered by the editor and it is impossible to import it from here.

    Can either of you provide a simple example export that exhibits the problem you’re having? Just enough fields so that I can see the issue. No one is going to read through 6 field groups and 500+ fields to try to figure out what you’re talking about.

    If you can provide a simpler example that exhibits the problem, put the export in a .zip file and attach it rather than posting the whole thing into the comment form.

  • This reply has been marked as private.
  • Were you able to use the above info to replicate the problem?

  • Sorry, I didn’t see your post when you added the files. I just imported them, both the simple and the big one. The simple one showed no problems. I don’t know if I’m seeing issues with the complicated one, can you give me instructions to produce the problem.

  • Tomorrow I’ll see if I can record a screencast of what I am seeing, this is 100% reproducible on my end (I’ve tried it on three different WP installs, and rebuilt the fields multiple times). The complex example should import/sync with 0 fields, while the simple one should work as expected except that the clone field should be imported into the main field group as if it wasn’t a clone field (ie, you can edit clone field group’s fields inside the main field and no clone field is present in the main field, but if you look at the JSON it should be a clone field and was created as a clone field, also editing these fields is buggy and reordering them does not save).

    I’m not sure if I’m not explaining it adequately or if you are not experiencing the same issue I am.

  • I’m not saying it isn’t, just that I’m not seeing it on a testing site. For example, the simple example you gave me when I edit the field with the cloned fields, I see a clone field and not the fields that are cloned. So the question here is, what is different between my site and yours. On my site the only thing I have running is ACF at the moment and the 2015 theme with no changes.

  • This reply has been marked as private.
  • I see that someone else is also having issues similar to this, and that it may be related to importing via the menu vs syncing from the acf-json folder. If you are importing manually vs syncing that may explain why you aren’t having these issues (I always sync, and am depending on the sync functionality for what I’m trying to do).

    If you try this again make sure to use the sync feature rather than the manual import, I assumed they worked the same but it seems like that might not be the case.

  • I took seeing the video for me to understand and for it to sink (no pun intended) in that this is a field syncing issue, and not an importing issue. I have reported this topic to the developer.

  • Yeah, it doesn’t help that I originally thought that this was an on-save bug due to my mangled JSON files (which I now realize were happening after saving the field groups without noticing that the seemless fields had been replaced).

    Please also convey my request for a the_row() equivalent for grouped fields – it would be enormously helpful. Thank you for your help and sorry for the confusion.

  • Hi guys

    Elliot here – ACF dev.

    Just want you to know that I’ve got this issue on my to-do for 5.4.7

    Thanks for your patience!’


  • Hi Elliot,

    Many thanks! I will go ahead and mark this as solved.

  • Hi guys

    Good news. I’ve started testing, debugging and believe to have found and fixed the issue!

    Can you please edit the file ‘admin/field-groups.php’ and replace the function ‘check_sync’ with the following:

    This should solve the issue of a sub clone field replacing itself with selected fields during sync!


  • Hi Elliot,

    I just tested this against my two example files and both worked – this seems to have fixed the issue. I did not test if a field could recursively copy its container field without an intermediary clone field in a different group, as I consider it a minor inconvenience if that’s still not possible – I suspect you probably fixed that as well though.


  • Hi @kmdg

    Thanks for the reply! I’m glad to have fixed the issue and plan to release an update shortly


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

The topic ‘Clone field JSON saving bugs’ is closed to new replies.