Support

Account

Register Login

Forum Replies Created

  • 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?

  • 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.

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

  • 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.

  • 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.

  • 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. 🙂

  • 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.

  • 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.

  • 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.

  • Sorry to resurrect an old thread, but I’ve just been pulling my hair with the same issue on a new project.

    It was proving very difficult to get fields and sub fields to match references, as I needed them to, for various template parts.

    In my example,the client had a broad colour palette,and pretty much every page component (built using flexible content) could use any colour from the palette.

    Rather than manually recreate the colour select field,I thought I’d be a bit more efficient and create a select field in a ‘brand options’ field group,and then clone that field whenever needed. For example:

    – Hero banner
    – – Title
    – – Image
    – – Colour (clone field)

    And

    – Flexible Content
    – – CTA Box
    – – – Title
    – – – Text content
    – – – Colour (clone field)

    In the hero banner, the data is obtained by get_field,the CTA Box by get_sub_field. The colour field for the subfield was a Lot harder to get to.

    I think part of my problem is that I quite like using unique field names, which isn’t necessary for nested content, becausevi findit easier for debugging.

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