Migration from ACF

Probably the biggest thing needed to know would be the field meta_key’s that ACF gave, so that you can properly map those to the IDs used in CMB2 fields. CMB2 doesn’t do anything custom in terms of where the content is stored, it’s all in either wp_postmeta, wp_termmeta, wp_usermeta, or the options table, depending on exactly what you’re using it for. The rest is just coding to configure the UI and the types of fields added.

@tw2113

I assumed this would mean the “key” beginning field_*, eg. field_5b39e6dc170b7.

Turns out, that doesn’t hook up with my first CMB2 field – but the human name I gave that field, source_url, does.

Is that right?

With the following…

<pre><code>// URL text field
	$cmb->add_field( array(
		'name' => __( 'Website URL', 'cmb2' ),
		'desc' => __( 'field description (optional)', 'cmb2' ),
		'id'   => 'source_url',
		'type' => 'text_url',
		// 'protocols' => array('http', 'https', 'ftp', 'ftps', 'mailto', 'news', 'irc', 'gopher', 'nntp', 'feed', 'telnet'), // Array of allowed protocols
		// 'repeatable' => true,
	) );

`

… I was able to place a CMB2 field that correctly shows on the edit page, even if I deactivate ACF Pro. Seems great!

So, in this scenario, am I close to being able to kick ACF?

—

Separately, I’m also surprised to see a whole “Custom Fields” box on the post page, showing all custom post meta.

I hadn’t seen that before, and it looks like it belongs to neither ACF nor CMB2 but, rather, is part of WP. I didn’t know this.

Even without either ACF or CMB2, I guess I could manage post meta in a rudimentary fashion using this?

• This reply was modified 2 years, 3 months ago by parakeet.

If field_5b39e6dc170b7 meta key holds the value you’re intending for this Website URL, which your CMB2 code example says has an ID of source_url then those would be the two needing mapped together in some sort of migration effort.

Yes, that would be the ancient because it’s been around since for ever custom field box from WP core. Dropdown of all “available” meta keys with option to create new ones, then a field to provide the meta value. Very rudimentary, which is why things like ACF and CMB2 all took off like they did. You can click the “Screen options” tab in the upper right area and turn off the display of this metabox if you need.

Why is a migration/mapping necessary?

In my wp_postmeta, post ID 133927 has two (relevant) post metas…

1:
meta_key: _source_url
meta_value: field_5b39e6dc170b7

2:
meta_key: source_url
meta_value: https://www.example.com/my/added/page.html

I believe #1 is just ACF’s signpost/proxy pair (wherein field_5b39e6dc170b7 is a ref to the field info held in a post of type “acf-field” and _source_url is a pointer to the real meta_key)…

#2 source_url contains my actual value. Despite being created in ACF, this shows a) when I connect “source_url” to a CMB2 box and it shows b) in the WP native “Custom Fields” dialog.

I guess my real next steps, if I want to switch tools, are…

1. Deleting ACF fields and field groups (this _should_ remove post types ‘acf-field-group’ and ‘acf-field-type’).

2. Deleting all meta_values with value field_5* across wp_postmeta, wp_termmeta, wp_usermeta and wp_options. I think this should leave the real meta data in place but just delete all the ACF refs.

3. Code-up CMB2 equivalents, wiring up the same meta_key names to the new boxes. CMB2 seems like a cleaner way to throw up boxes, leaving the data storage to native methods and without all the extra signposting.

Sounds about right for what remains.

Thanks.