Hi,
when I change the fieldname of a generated custom field its value is lost in the post where this field is assigned. When I revert back to the original fieldname the value is there again. I’d rather it to keep the value assigned to the field after changing the name. Is this wanted behaviour by design?
Hi @peterf
When you save / load a value, ACF will use the field name to find the value in the wp_postmeta table. This is pretty basic WP metadata stuff.
If you change the name, ACF will now be looking in the wrong place for the value.
You can always edit your database and change all the meta_key references from {old_name} to {new_name}.
Good luck
Cheers
E
oh I am sorry. I thought this is what the key was for.
mmm, i will try create a plugin for this kind of refactoring in database… need this to a site re-design and upgrade. thanks for information
When updating a field name from ‘old_name’ to ‘new_name’ I used 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';
@elliot Really feels like ACF could be doing this for us.
Can’t think of a situation where I would want to rename the field and not also have that reflected on the site.
I lost / can’t find my data, having made the change via SQL query.
@elliot just wondering if this is something that gets considered at all for future implementation?
This certainly is something I’m willing for. Maybe a checkbox that pops up when changing field name, asking whether data should be kept or not.
The CPT UI plugin has a similar behaviour.
The correct table is wp_termmeta, not wp_postmeta:
UPDATE wp_termmeta
SET meta_key='yournewkey'
where meta_key='youroldkey';
@fastvelocity that is not correct, wp_postmeta is what you want to update.
If anyone is still looking for a solution to this you can use something like the code snippet below. It will update post meta when you save ACF field groups. You may want to add additional checks before executing the database updates but for my case its suitable as is.
if (class_exists('acf')) {
/**
* Update meta fields on acf field name change
*/
function update_acf_field_name($data , $postarr)
{
global $wpdb;
$post_id = $postarr['ID'];
$post_type = get_post_type($post_id);
if ($post_type !== 'acf-field-group') return $data;
$prev_fields = acf_get_fields($post_id);
if (!$prev_fields) return $data;
if (!array_key_exists('acf_fields', $postarr)) return $data;
$next_fields = $postarr['acf_fields'];
foreach ($prev_fields as $prev_field) {
if (!array_key_exists($prev_field['ID'], $next_fields)) continue;
$next_field = $next_fields[$prev_field['ID']];
if ($next_field['name'] === $prev_field['name']) continue;
// add additional checks here
$res = $wpdb->update(
"{$wpdb->prefix}postmeta",
[ 'meta_key' => $next_field['name'] ],
[ 'meta_key' => $prev_field['name'] ]
);
}
return $data;
}
add_action('wp_insert_post_data', 'update_acf_field_name', 99, 3);
}
Hello.
I was looking for the metakeys your talking about both in postmeta and termmeta but I can’t find it.
I’ve also tried @nicholasarehart suggest but I can’t get it working.
If I change my image field name from image_name to _thumbnail_id I can do the trick to use my old image_name image as post-thumbnail, but I losted all the old images, so I’m trying to fix it changing those metakeys in the database.
Any thoughts?
Thanks in advance!
I wrote this tutorial that you might find helpful. It shows you how to update an ACF field name without losing its data.
https://wpforthewin.com/update-acf-field-name-without-losing-data/
I also would say that what others have suggested, with Fausto’s idea of making it selectable (update the underlying data or not when changing the field name) is a great idea.
Two immediate use cases I can think of where this would be a time saver:
– New developers who are doing lots of experimenting and realized they’ve named things in a way that no longer make sense
– Seasond developers who inherit projects from elsewhere where some dingus has just used inscrutable/nonsensical/misleading names
I mean, sure, you can poke around in the db, but I’d rather have a sane, automated way to deal with renames…
Both cases have applied to me in recent times. The first point more so that the project scope changed, and a new structure was needed.
For a DB refactoring feature (… or data migration, whatever the best label is), if there’s any worry about data integrity, then just slap a massive warning and disclaimer on it.
The ACF admin experience involves things opening & closing, drag-and-drop, forms being filled, etc. The ability for user-created elements in that experience to be renameable would be perfectly natural and expected. Going against that is a fight you can never win.
I opened a ticket on this to try to lodge this as a feature request.
natekinkead – I was hoping your tutorial would work, however, it appears it is only for parent fields? In my case, I was wanting to rename a “layout” field within a “flexible content” field type. I get the same result (modules disappear if I rename, reappear if I revert) but I don’t believe these “field names within a field”are stored in the same way?
Kit406, you’re right, sub-fields are stored a bit differently. I can’t remember how (off the top of my head). I would have to analyze the post_meta table searching for those sub-fields in order to figure out what the difference might be. I’m sure it’s doable.
Hi @ Kit406, any chance on finding a solution for your problem ? I encountered the same problem as yours. I already tried updating the wp_post post_content it’s corresponding wp_postmeta.meta_value and It didn’t work well, I hope that you can share your solution to this one. Thanks!
jay.tell, sorry, I never did find a solution, so just chose to leave as is. Very frustrating.
Completely off topic, but I’ve just come across another bug that I don’t quite fully understand too – where a repeater field ends up populating other similar repeater fields on the page with the same value, and cannot be deleted. I mention only to say that ACF “just works” 99% of the time, but damn it’s frustrating as heck when it doesn’t.
FYI, @nicholasarehart’s code seems not to work for me.
Just bumping this one – people seem to like the idea of ACF renaming things, and clearly there are going to be some edge cases where the plugin author is going to have an easier time knowing where the danger is… A year ago I did put in a feature request, and there was positive feedback there and a “I hope to fix this in future versions” response…
I’m going to update that ticket too, see if anything comes from it.
