Support

Account

Home Forums Feature Requests Migrate Database when changing Field Names

Solving

Migrate Database when changing Field Names

  • Can you please add a feature so that when field names are renamed or moved into a repeater, the database is migrated appropriately so previously set values are not loss.

    Currently if I want to change a field name from ‘old_name’ to ‘new_name’ I have to also execute the following SQL commands:

    
    UPDATE wp_postmeta
    SET meta_key='new_name'
    where meta_key='old_name';
    
    UPDATE wordpress.wp_postmeta
    SET meta_key='_new_name'
    where meta_key='_old_name';
    

    It gets worse when moving a field into a repeater, as I have to execute the following SQL commands:

    For repeater name “abc” and field name “xyz”

    
    UPDATE wp_postmeta
    SET meta_key='abc_0_xyz'
    where meta_key='xyz';
    
    # The meta_key might be a bit different if the field was also another repeater
    UPDATE wordpress.wp_postmeta
    SET meta_key='_abc_0_xyz'
    where meta_key='_xyz';
    

    You also need to insert a new record for each post id with:

    
    INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
    VALUES ({post_id}, "abc", 1);
    
    INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
    VALUES (post_id, "_abc", {field_key});
    

    As you can see this is extremely long and annoying, so please add a feature for ACF to do it automatically!

  • for a feature request like this you should open a new support ticket here https://support.advancedcustomfields.com/new-ticket/

    There is no easy way to do this that I know of except to modify the database. Changing field names, including moving fields into or out of repeaters and flex field isn’t something that should be done on a regular basis.

  • That’s why I am requesting that the plugin migrate the database for us. It’s actually not too hard to do when you know what to change on the database (i.e. just execute the SQL commands), but it just takes soooo long. Hence I’m asking a way to automate the process.

    Furthermore, I have found that I need this feature a LOT, especially during initial theme development!

    I will open a support ticket as requested!

  • 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.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.