This is a bit of an odd one, so some background:
We were using a plugin another developer used called “component fields”, but have decided it’s not really a fit for how we use ACF. As part of getting rid of the “components”, the plugin lets you convert their “components” into repeaters. This is fine, but all of these should really be groups – none of them “repeat”, they are just a repeaters with a single entry and will never need another entry. Having the “Add Row” button show up on these confuses the editors.
To me, it looks like Groups are essentially just Repeaters with a single entry – you use “get_field()” on the parent for both types , and then “get_sub_field” for each child. A conversion seems possible, but I’m getting zero hits on this (I assume our situation is a bit weird – most people well… repeat in their repeaters, so conversion would make no sense).
Any pointers on how to do a conversion of a bunch of these without losing data?
Yes, a group field is a repeater with a single row. However, you can’t just convert the repeater to a group. The act of switching the repeater to a group in ACF removes the sub fields.
You can probably do this if you export the field group to json, then modify the field information in the json file to match a group field and then sync the field group. I would do this by using local JSON https://www.advancedcustomfields.com/resources/local-json/, edit the file that acf creates alter the updated time and then syn the group. The important part here will be making sure that you keep the same field/subfield names and field keys.
I’ve never actually tried this, but it should work. But, as always, back up your site and DB before you try it.
I finally got around to reading a bit about Local JSON, and trying this out on a dev site and… sadly it does not work. I simply changed one field from “repeater” to “group” and the data disappeared, frontend and backend.
What’s weird is that if I look at the filed group ID, field ID for the repeater-turned-group and some subfields, the keys are unaltered. This implies that this switcheroo SHOULD work. I wonder if some validation is failing somewhere that makes ACF refuse to save data?
Time for more digging…
This is bizarre – the fields are definitely not changing, and in the db I see the keys are all the same. Even further if I simply change the field type back to “repeater” from “group”, my data reappears…
Additionally, if I try to add new data in this state, it does not show up on the frontend. And in the backend, validation is totally screwy – subfields that have no validation required fail validation for being empty (and don’t have the red asterisk).
I suspect this tampering just totally confuses some part of ACF…
The reason is that the “meta_key” in the database is different for repeater and group.
meta_key for repeater sub field = "{$parent_name}_{$row_index}_{$sub_field_name}"
meta_key for group sub field = "{$parent_name}_{$sub_field_name}"
When you make the switch the field data is then stored incorrectly in the database.
Ugh. I have over 100 of these to convert…
If you’re going to change these then don’t forget the acf reference db entry. Same meta keys as above but they start with an underscore.
