Renaming ACF Repeater and Flexible Content Fields
Repeater and Flexible Content subfields can be renamed, but Field Renamer 0.1.0 does not automate them. It detects nested fields and blocks them before any migration write. Subfield data is stored under a composite meta_key built from the parent name, a row index, and the subfield name, so renaming means rewriting a key pattern across a different number of rows on every record. Here is the manual path and what to check.
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_64d7712ac1a03Note that every row index shares the same field key. The key identifies the subfield definition, not the row — so unlike a top-level field, the key alone cannot tell you which rows belong together.
Why we will not automate it yet
The row index sits in the middle of the key, so matching requires a pattern rather than an exact value — and a pattern is exactly what makes a rename unsafe. Row counts differ per record, Flexible Content adds a layout name to the key, nested repeaters compound the pattern, and a pattern that is slightly too broad silently merges two subfields into one instead of failing loudly. We would rather block the case than ship a tool that is right most of the time.
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 pattern is specific to the parent name specs and the subfield name label. It will not catch Flexible Content layouts, nested Repeaters, or a different parent name. Confirm the SELECT returns every key you intend — and only those keys — before running the UPDATE.
Then update the subfield name in the field group, clear any persistent object cache, and open several records with different row counts — including one with zero rows and one with the most rows on the site.
Flexible Content is harder again
Flexible Content inserts the layout name into the key, so a subfield lives at blocks_0_hero_heading rather than blocks_0_heading. One field can appear under several layout names, and the same layout can appear at different indexes on different records. A pattern broad enough to catch every variant is almost always broad enough to catch something you did not mean.
What we plan to support
Single-level repeater subfields with per-record row enumeration rather than pattern matching, once the verification pass can prove the row count matches before and after on every record. Flexible Content and nested repeaters come after that, or not at all.
We block this case rather than guess at it, and that refusal is the product: Field Renamer only runs migrations it can prove are correct, and says so plainly when it cannot. See exactly what it does support →
Common questions
Can Field Renamer rename a Repeater subfield?+
Not in version 0.1.0. Nested fields are detected and blocked at selection, before any data is changed.
Why is a Repeater harder than a normal field?+
Its data is stored under composite keys containing a row index, so identifying the right rows needs a pattern rather than an exact match. Row counts also differ per record, so there is no single shape to verify against.
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.
Will Repeater support ever be added?+
Single-level subfields are planned, but only once the verification pass can prove the row count matches before and after on every affected record. Flexible Content and nested repeaters come after that, if at all.