@elliot
First, I would like to understand why you choose to use two kinds of field names, one you set “field_23h9h23j” and other we set our name “product-price”. What was the problem you found to use this solution?
I’m asking this because I wanted to upgrade a website to use this plugin but I got a problem when the ACF do not recognized the old fields just because ACF doesn’t found the fields “field_987sasdnkj”. In this case, what do you suggest to migrate to ACF?
@edir
I will attempt to answer the first question. ACF uses two types of field names in order to associate the field with its object; as you see in the postmeta table of your DB, only the value is saved (in “meta_value”) for the posts’ field name (in “meta_key”). So, in order to access the rest of the field object (e.g. “label”, “format”, “type”, “choices”, etc.), ACF must be able to look this up using a unique identifier (the key). This ensures that post meta is stored the way same as (and hence, compatible with) native WP meta. So, when ACF gets a field, it looks for the meta_key with the same name as the requested field but prefixed with an underscore – this gives it the key that allows it to find the rest of the object.
@elliot
Maybe a migration tool can be difficult to implement, but looking at ACF, the possible solution to this could be implementing a function just to recheck the fields inside each group and make corrections on metadata. A button on the page that list the groups could start this tool.
Workflow to migrate content could be:
- Create a group;
- Create the fields and set each field name to the name already used in the content;
- Set the group to the post type or any other content;
- Press a button to start rebuild groups;
- The tool gets each group, open the content and check for each field name in that content, if missing the connection field_98f7s8f it writes to this content.
This is my idea, I want to listen your opinion, maybe you already have a simple solution to this.
