ACF v4 to v5 Migration problem

• austinjreilly

• July 16, 2014 at 7:20 am

When I migrate from v4 to v5, I end up with lots of duplicate custom fields (see attachment).

Based somewhat on this thread, my first guess is that I’m experiencing this issue because of the way I tried to migrate changes to fields between my local machine and the live environment.

Basically, when I made small changes to field settings, I thought using the ACF v4 exporter I could merge the fields from my local to live environment so that I didn’t manually have to apply changes to fields. That turned out not to be the case, but the built in WordPress post importer (Tools–>Import–>WordPress) took in some of the ACF data and saved it into the database. Now, however the ACF v4 to v5 migration process is working, it’s treating those imported but not ordinarily visible fields as actual fields, and migrating them. That’s how I’ve ended up with so many duplicate fields.

Does anyone have any suggestions as to how to deal with this problem, or am I just stuck?

duplicatecus....png

• Elliot

• July 16, 2014 at 1:38 pm

Hi @austinjreilly

Thanks for the bug report.
Can you please elaborate more on the following:
he ACF v4 to v5 migration process is working, it’s treating those imported but not ordinarily visible fields as actual fields, and migrating them

I don’t really understand what you mean about the ‘hidden’ fields.

Looking forward to fixing this issue,

Cheers
E

• austinjreilly

• July 16, 2014 at 1:51 pm

Thanks for the quick response.

I’m not surprised that you’re confused, because this is hard to explain and I didn’t do a great job of explaining.

I have a production site and a test site. I made some changes to the fields on the test site (things like field labels). Using v4, I (mistakenly) thought I could use ACF’s “Export to XML” feature to overwrite the existing fields on the live site. That didn’t work, because Tools–>Import won’t let you overwrite existing post types (I can’t remember the error exactly, but it’s something like that). In order to get the custom fields for production and test in sync, I had to manually make the changes to production that I made on test (which is fine).

My working theory is that trying and failing to import fields as described above leaves some kind of trail in the database, and migrating from v4 to v5 makes that trail visible, hence all of the duplicate fields that you can see in the screenshot.

Does that make more sense?

It’s possible that this is a red herring, in which case my problem is that migrating from v4 to v5 creates a bunch of duplicate fields and I have no idea why.

• Elliot

• July 17, 2014 at 11:53 am

Hi @austinjreilly

Thanks for the info. I’ll do some testing with this one. It seems like the chances are slight, but it is a bug no less.

Cheers
E