How ACF Stores Group, Repeater, and Flexible Content Fields
Field Renamer 0.2.0 supports value-bearing subfields inside Repeater, Group, and Flexible Content structures. It also renames Flexible Content layout names. Each nested value must match the complete parent path and the selected child field-key reference before the plugin snapshots or copies it. Repeater, Group, and Flexible Content container names remain unsupported because their names prefix descendant metadata keys.
How repeater data is actually stored
A repeater writes one row holding the row count, then a pair of rows per subfield per row index. A three-row repeater called specs with one subfield looks like this.
specs 3
_specs field_64d7712ac0f42
specs_0_label Weight
_specs_0_label field_64d7712ac1a03
specs_1_label Material
_specs_1_label field_64d7712ac1a03
specs_2_label Origin
_specs_2_label field_64d7712ac1a03Every row index shares the child field key. The plugin combines that reference with an anchored path such as ^specs_[0-9]+_label$. It stores a separate snapshot for each matching metadata row, including multiple rows on the same post.
How version 0.2.0 scopes the rename
Group names become literal path segments. Repeater and Flexible Content parents contribute a numeric row segment. The selected child name closes the anchored path. The scanner then requires the same-post underscore reference to equal the selected child field key. A broad suffix match does not qualify.
The manual path
Take a backup, then run the SELECT form first and read every key it returns before you change anything. Anchor the pattern at both ends.
SELECT meta_key, COUNT(*) FROM wp_postmeta
WHERE meta_key REGEXP '^_?specs_[0-9]+_label$'
GROUP BY meta_key;
UPDATE wp_postmeta
SET meta_key = REPLACE(meta_key, '_label', '_title')
WHERE meta_key REGEXP '^_?specs_[0-9]+_label$';This manual pattern is specific to the parent name specs and child name label. It does not prove field-key ownership or retain a recovery snapshot. Confirm the SELECT returns the intended value and underscore-reference rows before running the UPDATE.
Then update the child definition, clear persistent object caches, and inspect records with different row counts, including an empty Repeater and the largest Repeater on the site.
Flexible Content storage
A Flexible Content subfield uses the parent name, row index, and child name, such as blocks_0_heading. ACF does not insert the layout name into that metadata key. The parent blocks value stores the ordered layout-name sequence as a serialized array. Field Renamer uses the child field-key reference for subfields and updates exact entries in the parent sequence for layout-name renames.
What remains blocked
Renaming a Repeater, Group, or Flexible Content container would change the prefix for every descendant field, which creates a multi-definition migration. Version 0.2.0 blocks those container targets. It also blocks Clone ancestry because one cloned definition can appear under more than one storage path.
The impact review shows each nested target, its parent path, affected posts, and total metadata instances before you approve the migration. See the impact review →
Common questions
Can Field Renamer rename a Repeater subfield?+
Yes. Version 0.2.0 matches the complete Repeater path and child field-key reference, then snapshots and verifies each row instance.
Can it rename Group and Flexible Content subfields?+
Yes. Value-bearing Group and Flexible Content subfields use the same path-and-field-key ownership checks.
Can it rename Flexible Content layout names?+
Yes. The plugin snapshots the serialized parent value, replaces exact layout-name entries in place, and supports rollback against the latest row sequence.
Can I rename the parent Repeater itself?+
Not safely with a simple query. The parent name is a prefix on every subfield key, so renaming it means rewriting every composite key on every record as well.