Support for "Legacy" Fields

• tommcgee

• September 22, 2016 at 9:09 am

I’m trying to migrate from Magic Fields over to ACF. Most of the data is coming over OK, as I simply create new ACF fields with the same names as MF fields.

One sticky spot is duplicated fields. For example, I’m running a site for an orchestra, and I have a page that shows the season schedule — with multiple concerts — and the list of multiple soloists.

My postmeta table for the current season’s post shows three rows with the meta_key “program_title”, with meta_values that point to the post_ids of the individual concert posts; and two “artist_artist” meta_keys that point to the post_ids of the two featured artists.

However, in the edit screen for the season post, only the first performance and first soloist shows up. And in my template coding, nothing seems to get me past the first entry.

I have the field group set up to use multiples, and I’ve given these entries the same names as in the database (program_title and artist_artist); and I’ve tried setting it as a relationship and as a post object.

How can I get ACF to recognize these post_meta entries, without re-doing hundreds of individual posts?

• John Huebner

• September 22, 2016 at 9:57 am

Short answer is that you can’t. The problem is that the old plugin you used stored multiple values in multiple rows and ACF stores these types of values in a serialized array in a single DB entry. You will need to convert the value.

My suggestion would be to create a new field name for ACF, but how you proceed from there depends on what type of field you set up in ACF. What is the field type of the field you’re trying to use?

• tommcgee

• September 22, 2016 at 10:22 am

I’d prefer to use post object type; that way I can grab fields from the related posts and display them as well. At least that’s my aim.

Where in the database is the ACF serialized array stored? It looks as though ACF is creating “child posts,” and new sets of metadata in the serialized arrays. Is this correct, and is it going to be practical for me to reverse-engineer them with some PHP code? Or am I going to hit another wall later…

• John Huebner

• September 22, 2016 at 9:44 pm

A post object field that allows multiple selections, or a relationship field, both work basically the same way, it’s really only the interface that’s different.

Basically this is what you’d need to do. Let’s just say that the old field was named “old_field” and the new one is named “new_field”. You create an acf/load_value filter for the new ACF field, information can be found here https://www.advancedcustomfields.com/resources/acfload_value/

add_filter('acf/load_value/name=new_field', 'convert_old_field_to_acf', 10, 3);
function convert_old_field_to_acf($value, $post_id, $field) {
  if ($value !== NULL) {
    // if the value is not set for ACF yet
    // then the value will be NULL
    // if the current value is not NULL
    // then return because the field already
    // had been set
    return;
  }
  // get value from old field
  $old_value = get_post_meta($post_id, 'old_field', false);
  if (!empty($old_value)) {
    $value = $old_value;
  }
  return $value;
}

Using a filter like this you can leave all the old values where they are, they will be returned for use is ACF function and eventually all of the data will be move over as posts are edited so you don’t need to go an convert everything ahead of time.

• tommcgee

• September 22, 2016 at 11:46 pm

Thanks, I’ll give this a try next time I’m on the project!

• tommcgee

• September 23, 2016 at 8:51 am

Unfortunately, this seems to do nothing. I’ve tried several fields, individual values, duplicate values, old_names and new_names, but nothing changes.

Hm. I hope I’m not stuck with Magic Fields.

I’ve got an old field, “basic_info_date”, which I’ll try to convert to a new field, “date”.

add_filter('acf/load_value/name=basic_info_date', 'convert_old_field_to_acf', 10, 3);
function convert_old_field_to_acf($value, $post_id, $field) {
  if ($value !== NULL) {
    // if the value is not set for ACF yet
    // then the value will be NULL
    // if the current value is not NULL
    // then return because the field already
    // had been set
    return;
  }
  // get value from old field
  $old_value = get_post_meta($post_id, 'date', false);
  if (!empty($old_value)) {
    $value = $old_value;
  }
  return $value;
}

This displays the Unix base time in 1970 as the date, because the value is null:

echo '<p>';	
			echo date('l, F j, Y', strtotime(get_field('date')));
			echo ' at ';
			echo get_field('time');
			echo "<br />\n";

The time shows up OK because I have a default value set.

When I modify the field names, am I breaking something? Do I need to erase the group and start over?

I’m really baffled.

• John Huebner

• September 23, 2016 at 9:32 am

You may be having a problem with the old data not being compatible with the ACF data and you might need to do additional formatting changes.

As an example, ACF stores a date… well that’s a complicated on. The date is actually stored in the database as YYYYMMDD but expects it to be YYYY-MM-DD. This change is internal as was needed to correct a problem when the time and date/time fields were added. If the value is stored in the DB in a different format then you’ll also need to change it to this format before returning it.

Relationship fields store a serialzed array of post ID values and the values need to be integers. A post object field might save a single integer of a serialized array of integers.

It should be possible to have the conversion work on the front and back end. On the front to show old values that have not been updated and on the back to populate the new fields with the old values.

One other hurdle that you might have are posts that have been updated having new fields but no values. These fields will no longer have a NULL value but will either an empty string or an empty array, depending on what type of values it stores.

• tommcgee

• September 24, 2016 at 8:03 am

Thanks for your help, but I’m going to have to go with everyone else who says converting from Magic Fields to ACF isn’t possible.

At least, it’s far more work than I’m willing to put in for a volunteer project! Maybe at some point in the future I’ll go in and modify them all by hand. For now though, I’m painted into a corner.

• John Huebner

• September 24, 2016 at 8:23 am

Everyone else? I assume that you’ve posted this somewhere besides here. Like I tell people I work with… Nothing is impossible. Possible is limited only by the amount the client is willing to spend.

But you are right, it will probably take a great deal of work. Basically you’re going to have to look at every field in the old system and figure out what might be compatible in the new system and put a filter in place for every field. In the long run it might be more time and cost effective to build an new site and repopulate all the data manually.

On the other hand, I was curious so I was looking. I can’t seem to find much information on this magic fields plugin.

You might also try WP All Export and Import. There is an ACF add on. You could probably use these to export the data from the site and then import it to the ACF field. But I still don’t think that would be an easy task.

Sorry I couldn’t be more helpful