Support

Account

Register Login

Home › Forums › Bug Reports › ACF Clone field in group not importing properly

Solving

ACF Clone field in group not importing properly

  • Plugin Version: 5.8.11
    WP version: 5.4.1

    Steps to replicate:

    Suppose I have setup in the admin a one field group that contains non-clone fields setup ready to clone for other groups, and another field group with a group type field and then inside these, there are instances are clones in them so:

    Field Group w/ clonable
    — field text
    — field image
    — field select
    — group field
    —- sub field
    — repeater field
    — …

    Field Group
    — …
    — Group field
    —- …
    —- cloned field text
    —- cloned image field
    —- cloned group field
    —- …

    I export BOTH the field group with non-clone fields and the field groups that contain clones of them as a JSON and the json file retains the clone relationship

    The problem starts when I import the json file into the separate site. On import, all instances of clone fields inside group fields are “flattened” in a sense, or any relationship with the cloneable fields are gone and they are now set up as their own fields instead of clones so…

    Field Group w/ clonable
    — field text
    — field image
    — field select
    — group field
    —- sub field
    — repeater field
    — …

    Field Group
    — …
    — Group field
    —- …
    —- field text
    —- image field
    —- group field
    —- …

    I tried importing the non-clone field group first, then the field group with clone fields but that didn’t work either. Is it possible to import the fields while maintaining clone relationships?

    pls help. thank you!

  • Hi there,
    Did you figure this out> I have a similar situation. On import of field groups with clone fields the “contents” of the clone replaces the clone field.
    Thanks

  • I’ve just had the same issue. I use a clone field for reusing colour choices across different areas of a site. (One client has 11 colours in their palette, so entering that in a select field each time I need it is a bit of a faff!)

    This had worked fine for me in the past:

    1. Create select field in a Sitewide Defaults group.

    2. Clone the field wherever needed.

    The clone field seems to import OK if it’s just a regular field, but causes a bug if it’s a sub field, such as in a flex or repeater field.

    In my case, the cloned field is converted to an equivalent regular field and triplicated.

    For example, I use “section” as the field name and enable the prefix fields option, so that the final field is used as “section_colour”.

    After import, I find three identical select fields called “section_colour”. Note, these are NOT clone fields but have been converted to a select field (as that’s the type for the base field which has been cloned)

    I then tried to remove the extra ones and resetting the clone relationship but on saving the field group the problem repeated. Three of the same converted fields again.

    I’ve never had this problem before. I’m using 5.11.4 on WP 6.0.3.

  • Just to follow up on this. After doing some further testing, I was getting a bit closer by changing the display type from “Seamless” to “Group” before I did the export / import.

    When I imported my Page Blocks field group, the field keys were preserved, however, the clone field value was “Unknown field”.

    I then took a look at the field group for the source fields (Sitewide Defaults), and they were gone! Importing deleted the fields which were being cloned.

    Next, I imported these cloned fields again (Sitewide Defaults). The keys match.

    Checking back in my Page Blocks field group and ACF has picked up the cloned fields correctly. “Unknown field” has been replaced by “colour”, the name of the cloned field.

    So, I went for broke and I switched this to Seamless. Instantly it broke the clone relationship again. It converted it to a Select field with the same values.

    I’ve turned on the display of field labels and noticed something interesting.

    In Page Blocks, my “section_colour” clone field key is “field_5ec2c2ae8fc5e”

    In Sitewide Defaults, my “colour” field key is “field_605b6e3946788”

    When the bug occurs and the clone field becomes ‘flattened’ as a regular field, the key merges. It becomes “field_5ec2c2ae8fc5e_field_605b6e3946788”.

    All of this happens when the clone field is inside a flex or repeater. Works fine if it’s outside the repeater.

    The biggest concern here is that it either duplicates/triplicates fields and deletes the source field. Very strange.

  • Thanks very much for the detailed descriptions. I will work through them. So far I’ve gotten where I needed to by re entering everything and that’s quite a chore. I am intrigued by the seamless/block thing. Going to give that a shot.
    Cheers

  • You’re welcome, it’s serendipity that we’re having the same issue at the same time!

    I think I’m going to have to go that route too, just as I’m up against a deadline and can’t afford any data loss on an existing project.

    If you’re starting a new project it might be worth sticking with Group for now, as switching between display types once you have real data in there isn’t feasible.

    Something I think I’ll try tomorrow is using local json to save the fields. The idea of that is to assist moving between environments, so might do the job.

    Out of interest, does the bug only appear for you if you do it in a subfield, or are you getting it on a regular field too?

    Let me know and I’ll report as a bug because this has been an issue for years it seems.

  • I just build a small sample group that includes a clone group and it worked. Maybe its only an issue with clone subfields inside flexible content fields??

  • That’s great, thanks so much for checking.

    I’m going to run the same tests on another test server I have just to rule out anything odd like Redis caching the old values or something. I’ve had strange things with Redis caching db queries in WooCommerce when they were stored in the options table. My cloned base fields are in Options too.

    I’ll file a bug later / tomorrow and keep you posted. 🙂

  • That will be awesome. Thanks a lot

  • Just a quick follow up, I tested on my own test server today and the field groups imported perfectly. I think there must be some environmental factors involved, as there’s only one environment where this isn’t working (which annoyingly is the one I need to work!)

    This isn’t an isolated issue though, as the three of us on this thread have found it.

    To me, it feels like something is getting stuck in a cache somewhere. Mind if I ask what your server is like?

    On my dev server that is working I have page and db caching switched off.

  • I am running my tests on a mac using local by flywheel.
    Some of my results after your previous input:
    I created a simple setup with a field group with a couple of text fields (test group). Then two more field groups: “group that includes (seamless)” and “group that includes (not seamless)” with one text field followed by a flexible content field that contains one clone field which contains “test group”. These two groups that include have seamless and block settings on the clone field. When I export all the field groups and then import them on a different wordpress instance, I find that the “seamless” one does not work while the “block” one does work. I am attaching the json file.
    I think this points to the “seamless” or not issue. If you want to, maybe trying it in the environment you said was working for you will give more understanding.
    Cheers

    .

  • Thanks cseevinck! I can’t download your json for some reason, but I can work out what you mean about the test setup.

    I tried migrating the fields to another test site and everything was fine, including using Seamless clone fields as sub fields. The only environment I’m having trouble with is the one I need it to work on!

    Out of interest, have you tried development mode on Flywheel? This prevents all caching so should prevent any conflicts with existing fields.

  • https://getflywheel.com/wordpress-support/dashboard-tour/#advanced

  • Yeah, I am not using flywheel, but what is now https://localwp.com/. It does not include the “advanced” tab that flywheel hosting provides. I can’t see any options in it that addresses caching.

  • Ahh sorry, my mistake. This is a very strange issue, as it’s just affecting one server of ours.

    I contacted support on this bug so will let you know when I hear back. For now I’m just going to have to recreate new fields manually.

  • Hi @curious-toad
    I posted a question on facebook acf group about this issue and got an interesting suggestion. It was to use the Local JSON feature (https://www.advancedcustomfields.com/resources/local-json/) – I didn’t know about it at all. What you do is create an acf-json file in your theme folder (there are hooks to change the location). Acf looks for the folder when a field group is updated/saved and puts a json copy of the group in the file. This means that the changes to acf field groups can now be migrated to other sites using normal file change procedures rather than database stuff. If that file present on your “destination” site, Acf will show that there are changed/new field groups available for “sync” and if you click sync on each group that needs a sync, you’re done. I tried this on the test environment I set up and it works well.
    I wanted to check with you if you have tried this approach and if you still see issues if you have tried it? I am hesitant to change my workflows in case this has more problems. I plan on testing this on my “real” expanded setup when I get a chance and will let you know what I find.
    Cheers

  • Thanks for following up – that’s great to know it’s working well as that’s exactly what I want to try!

    Unfortunately time pressures for this project mean I have just created the fields on production by hand, as we were due to pull a fresh copy of the database over to staging anyway.

    Once the dust has settled I was going to try this local json approach as I think it’ll also help with collaboration between devs.

    When you synced the fields, did you get any of the issues with fields jumping out of the field group, being converted to regular field etc?

    I saw on a forum post here a recommendation to use the setting to make the fields private to disable syncing (so that it’s all controlled via the theme/plugin version control). Did you look at that as well?

  • No issues with fields jumping out–it seems to work as desired. In my “simple” test I had cloned fields with and without the “seamless” selected and the “seamless” did not work before. Both work for me with this local-json approach — encouraging.
    Yeah, I saw some stuff on the “disable syncing” and while I don’t think I will need it for this project, I can see how useful it would be for an environment where there are multiple people playing with this stuff.
    Keep well

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

The topic ‘ACF Clone field in group not importing properly’ is closed to new replies.