How do I keep content after changing the structure of a repeater?

• robs

• July 12, 2019 at 2:16 am

I am trying to move some fields from one repeater to another and I am losing the content that was filled out in those fields in wp-admin when I do. How can I change the structure of a repeater without losing the content?

What I have now:
Repeater
– Link
– Text

What I want:
Repeater (Existing)
– Text (New)
– Repeater (New)
— Link (Existing)
— Description (Existing)

• John Huebner

• July 12, 2019 at 2:56 am

It could be possible, but honestly, it will take a lot less time to code for than to retrofit the existing data to the new fields.

If I had to do this I would leave the existing fields and I would add a filter to both of these fields to remove them if they have no content. Please note that you need to use the field keys and not the field names.

add_filter('acf/prepare_field/key={ORIGINAL TEXT FIELD KEY HERE}", 'hide_old_fields', 20);
add_filter('acf/prepare_field/key={ORIGINAL LINK FIELD KEY HERE}", 'hide_old_fields', 20);
function hide_old_fields($field) {
  if (!$field['value']) {
    return false;
  }
  return $field;
}

What that does is only show the existing fields if they have a value.

I would add the new fields. When editing the post the values can be moved to the new field and when that is done and the values are removed from the old fields they will no longer be usable.

The next thing I would do is to alter my theme code

if (have_rows('your new nested repeater name here')) {
  // new code to show new repeater
} elseif (get_sub_field('old link field name here')) {
  // old code to show link here
}

This allows either to be used and no posts need to be updated until such time as the post is updated for some other reason, or never as the case may be.

This will take a short time to implement as apposed to potentially hours in phpMyAdmin altering meta_keys and possible missing, breaking or anything.

• robs

• July 12, 2019 at 3:47 am

I’m not trying to add new fields I am trying to move existing fields to under a new repeater

• John Huebner

• July 12, 2019 at 4:10 am

Exactly, I’m saying that I would not move the existing fields, I would create new fields and in a creative way allow both the old fields and new ones to be used until such time as the old fields have not value.

Here’s the thing, to move the content.

Your old fields, in the database, will have meta keys that look like

"{$repeater_field_name}_{$row_index}_{$sub_field_name}"

These will need to be renamed to

"{$repeater_field_name}_{$row_index}_{$nested_repeater_name}_0_{$sub_field_name}"

in addition to this there is an acf field key reference for every entry with a meta key that looks like this

"_{$repeater_field_name}_{$row_index}_{$sub_field_name}"

these needs to be renamed to

"_{$repeater_field_name}_{$row_index}_{$nested_repeater_name}_0_{$sub_field_name}"

On top of this you need to create a meta entry for the new repeater itself

meta_key = "{$repeater_field_name}_{$row_index}_{$nested_repeater_name}"
meta_value = 1 // this is the number of rows in the new nested repeater

You will also need to create an acf field reference for the new nested repeater

meta_key = "_{$repeater_field_name}_{$row_index}_{$nested_repeater_name}"
meta_value = field_abs123 // this is the field key of the new repeater

There is no simple way to do this, and I would not do this because it is unnecessary work when the issue has, what I feel, is an acceptable solution. The only reason I would do this is that a client insisted on a change of this type and then I would explain to them how to use the changes. I would not do many hours of work that is prone to errors when I could accomplish a suitable work-a-round fix in 15 minutes or less.

• robs

• July 12, 2019 at 4:32 am

Ah! Thank you for your help!