follow-up of #1578694: migrate fields can't be run missing cck_country Drupal 7, countries does not provide an upgrade-path for D6 users of cck_country.
These are stuck or forced to tweak DB or use custom code in order to do that.
The field is probably easier to handle and upgrade than most others.
Any hope to see either countries.migrate.inc implemented or a countries_update_7000 written ?

I'm sorry but I can't myself afford the time to write (but more importantly understand) an upgrade-path for each and every D6 modules I use which are still missing one.

CommentFileSizeAuthor
#11 1840472-11.patch2.86 KBdrzraf
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alan D.’s picture

Migrate support was added here: #1378662: Add support for Migrate API

Reopen if you have issues

btw, hopefully I will find the time to roll a new tag soon, the last one was Feb 9, so this is lagging behind the dev branch slightly!

Alan D.’s picture

Status: Active » Closed (duplicate)
drzraf’s picture

Then it's more about a support request :
Going to D7's /admin/structure/content_migrate:
field_cckcountry :

Other information
    Missing field module: 'cck_country'. This field cannot be migrated.
    Missing widget: The 'cck_country_select' widget is not available for the field_cckcountry field, it will be set to the default widget.

How would I run a content migration ?

drzraf’s picture

Category: task » support
Status: Closed (duplicate) » Active
Alan D.’s picture

Project: Countries » Migrate
Component: Code » Miscellaneous

Hi just transfer queues to see if there is any way that the countries module can assist users upgrading from cck_country field. Internally the schema is very similar I thing.

Thanks in advance

drzraf’s picture

Alan, I anticipate a bit on migrate maintainers answer, but
what the drush-magic-script should looks like (in order to run the cck_country-to-countries migration without depending on migrate restrictions) ?

I believe MigrateCountryFieldHandler exists for a reason, how is prepare() expected to be called and to save fields value ?

mikeryan’s picture

Project: Migrate » Countries
Component: Miscellaneous » Code

Implementing a migration path between two contrib modules is most certainly not in the Migrate module's domain - it's up to the destination module to make use of the Migrate API in implementing the migration path.

Alan D.’s picture

I personally have extremely limited time atm, I was just trying to get pointers....

drzraf’s picture

I looked at #1232028: Support for Migrate package which was about cck_email, so while the code is very similar to the one already commited into countries it does not give a hint about the migrate API.
#1821878: Migration of location_cck data into addressfield has no patch available.
http://drupalcode.org/project/migrate_extras.git/blob/refs/heads/7.x-2.x... wasn't helpful either.
But it seems that cck/modules/content_migrate/content_migrate.api.php could be helpful, especially hook_content_migrate_field_alter() which gives what appears to be a hint about the migrate hook to implement:
http://drupalcode.org/project/cck.git/blob/refs/heads/master:/modules/co...

drzraf’s picture

hum, after a deeper look cck content_migrate does not really use the migrate API.
But content_taxonomy does.
It does not provide module.migrate.inc but rather a new distinct sub-module, see:
http://drupalcode.org/project/content_taxonomy.git/blob/refs/heads/7.x-1...

drzraf’s picture

Status: Active » Needs review
FileSize
2.86 KB
drzraf’s picture

just posted #1841578: cck_country upgrade-path so that cck_country authors know they're (still) needed to review this.

drzraf’s picture

Category: support » task

ping

drzraf’s picture

ping

Alan D.’s picture

Title: upgrade-path from cck_country » Migrate support: Sub-module for upgrade-path from cck_country / general support

This would definitely need addressing:

+    else {
+      // TODO: is it possible ?
+      print "warning: unknown field configuration, please report the following at https://drupal.org/node/1840472\n";
+      var_dump($field, $record);
+    }

Maybe drupal_set_message() instead?

And I guess general migrate support can be added at the same time. We just done a big D6 to D7 data migration and I do not think that this was used, or if from another unrelated issue post... And may not have any testing...

The raw code from my local countries.module.

# info file
files[] = countries.migrate.inc

# main module
/**
 * Implements hook_migrate_api().
 */
function countries_migrate_api() {
  $api = array(
    'api' => 2,
    'field handlers' => array('MigrateCountryFieldHandler'),
  );
  return $api;
}

# countries.migrate.inc

/**
 * @file
 * Base integration with the Migrate API class.
 */

/**
 * Custom extended MigrateFieldHandler class.
 */
class MigrateCountryFieldHandler extends MigrateFieldHandler {
  public function __construct() {
    $this->registerTypes(array('country'));
  }

  public function prepare($entity, array $field_info, array $instance, array $values) {
    $arguments = (isset($values['arguments'])) ? $values['arguments'] : array();
    $language = $this->getFieldLanguage($entity, $field_info, $arguments);
    $delta = 0;

    foreach ($values as $value) {
      $return[$language][$delta]['iso2'] = $value;
      $delta++;
    }

    return isset($return) ? $return : NULL;
  }
}

Makes sense to wrap all of this into one sub-module :)