When trying to just do the basic example (article_custom_field table with a couple of entries in it), I get this #fail: 

Fatal: Call to undefined function system_field_convert_load() in field_convert.admin.inc on line 514

Comments

joachim’s picture

joachim CreditAttribution: joachim commented
Status: Active » Postponed (maintainer needs more info)

Can you check which version you're on? I can't find that string anywhere in my code.

Something wacky seems to have happened with my commits -- the alpha1 release tag is on a spur off the 7.x-1.x branch and is not itself on any branch. Though alpha1 and dev only differ by comments anyway.

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented
Status: Postponed (maintainer needs more info) » Active

This is 7.x-1.x, commit 1e333e4e91495e793c33c0b26e0755fc8ebdaf7c (tip)

Here's how it happens:

function _field_convert_manipulate_object($plan, &$object) {
  // Call the plan module's hook_field_convert_load() on the object.
  // This allows the providing module to load its data into the object.
  // For the case of nodes, a module's implementation of this hook may be
  // almost a verbatim copy of its old D6 hook_nodeapi 'load' op.
  $function = $plan['module'] . '_field_convert_load';

Of course, $plan['module'] is 'system' because this module is masquerading as system.module.

I've gone a different direction now, so maybe this is irrelevant.

joachim’s picture

joachim CreditAttribution: joachim commented

Oh. I remember now -- that's a hook. So your module should define that function.

I should probably wrap that in a function_exists, or use module_invoke.

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented

Actually, that's "*your* module should define that function". I was trying to run the example provided :-)

Again, I just wrote a manual migration for comment_upload, so won't be using this.