Just a quick post as I was looking for something similar (I think). Basically renaming fields leaves a lot of “stray” data.
This is a limitation of the structure I believe – the name is used like a key/index so any change is basically the same as changing a db key. Typically, in non-WP applications, once a key is set, thats pretty much it – I couldn’t imagine one every really changing it. There is also exists the concept of field keys (the field_xxxxxxx values you see in places) – why they aren’t used instead I’m not entirely sure. I feel like certain levels of compromise were made to work with WP instead of against it.
Anyway – one tactic I have been using more recently so I don’t up with lots of garbage data is working across a few environments (which you should be doing regardless!).
My setup looks like:
Dev: vagrant machine – WP + ACFPro.
Anything goes, I change as much as needed, and when I feel like I have accumulated too much “stray” data from ACF I export the ACF json data, destroy the machine, and re-import it.
Staging: hosted machine – WP + ACFPro.
Code + ACF exports are sync’ed up from dev and data is synced down from Production. This is to test how new code changes/ACFPro fields work with the current set of data in Production. I never manipulated ACFPro directly in here through the interface.
Production: hosted machine – WP + ACFPro.
Code + ACF exports are sync’ed up from dev after being validated in staging. I never manipulated ACFPro directly in here through the interface.
I find this minimizes my renames + stray data. As I find the most common time I rename is during development of a new feature while still nutting out what I need or want. I can confidently can nuts in dev, renaming, changing new fields/features because all the stray data is destroyed at a moments notice.
The biggest catch is changing a name that has already been synced to production. In this case, I unfortunately have to wear that.
