Reference

Field eligibility

The plugin accepts post-backed values when it can prove the complete metadata path and stable ACF field-key ownership.

Verified: 28 August 2026 · Field Renamer 0.2.0

Accepted in version 0.2.0

Database-owned definitions and unambiguous ACF Local JSON definitions are supported. Eligible targets include top-level fields, value-bearing Group and Repeater subfields, Flexible Content subfields, and Flexible Content layout names.

  • Top-level value-bearing fields
  • Group, Repeater, and Flexible Content subfields
  • Flexible Content layout names
  • Post-based field-group locations with stable, unique ACF keys
Field Renamer field list showing eligible and refused fields
The field list resolves eligibility before you choose a target.
Flexible Content layout selected as a supported rename target
Flexible Content layout names appear as their own supported targets.
Impact review for a Flexible Content layout-name rename
The layout review counts exact occurrences in the parent layout sequence.

Refused before migration writes

Unsupported selections do not create a migration.

  • Repeater, Flexible Content, and Group container names
  • Fields reached through Clone; Tab, Accordion, and Message presentation fields
  • PHP-registered definitions
  • Options, users, terms, comments, widgets, menus, blocks, attachments, ACF definitions, and WooCommerce HPOS orders
  • Ambiguous Local JSON, duplicate rows, destination collisions, foreign references, or cross-store ownership

New-name rules

A new name must begin with a lowercase letter and contain only lowercase letters, numbers, underscores, or dashes. It may be at most 191 characters, must survive WordPress sanitization unchanged, must differ from the current name, and must not collide with another active ACF field name.

Need help with this workflow? Open a support request →