Support for migrate v2.4 (subfields)

We probably need to do this in a way that it won't break migrations that were already created using older methods. I can't tell if you're taking this into account.

Eyeballing this patch, it shouldn't affect existing migrations. The new subfield method passes the subfield internally using the same method as the former arguments method, the main thing this adds is documentation of the available subfields.

Guess it does affect the old code;). So, it should be fixed to support legacy code, and there should be a new test added for the subfield approach.

OK, here's some refactoring plus updated examples. This version allows the subfields to be arrays with distinct values per primary value (i.e., in a multi-value date range field each data has its own from/to). The testbot isn't going to be happy until #1832544: Class registration for Migrate 2.5 or later is committed, so that should go first, but the tests do pass in my environment with both patches present.

#6: migrate_subfields-1715700-6.patch queued for re-testing.

I think #1832544: Class registration for Migrate 2.5 or later needs to be committed before this patch will pass testing...

Code is clean and causes the Date Migrate module to function properly with the Migrate module v7.x-2.5, following the application of the patch from #1832544: Class registration for Migrate 2.5 or later.

Agreed. I applied the patch in #6 and had no problems migrating a date with the new subfield syntax.

Great news. How can we get this into date? I (and many others from what I can tell) are stuck in the water trying to import calendar events into Drupal with Migrate. It looks like the with this patch, the capability is there but when will it move to code with an even brief example of how to apply it.

Thanks all!

#6: migrate_subfields-1715700-6.patch queued for re-testing.

Silly me, #1832544: Class registration for Migrate 2.5 or later isn't committed yet...

Updated patch - I had trouble with timezones coming in with empty strings, !empty() works better than isset().

@mikeryan, this works great for me. I simply extended (overrode) the DateMigrateFieldHandler in my custom migrate_d2d module since the patch hasn't been committed yet and that works fine.

Works great! Thank you very much!

Two more additions to date.migration.inc are needed or migration fails because of undefined language variable.

<?php
      // Add language subfield
      if (!empty($arguments['language'])) {
        if (is_array($arguments['language'])) {
          $language = $arguments['language'][$delta];
        }
        else {
          $language = $arguments['language'];
        }
      }
      else {
        $language = NULL;
      }

and

<?php
  public function fields($migration = NULL) {
    return array(
      'timezone' => t('Timezone'),
      'rrule' => t('Recurring event rule'),
      'to' => t('End date date'),
      'language' => t('Language'), //Added to array so you can $this->addFieldMapping('field_event_date:language')->defaultValue('und');
    );
  }

One more fix is needed to deal with date fields that are not date ranges. The date.migrate.inc file assumes there is a field_date:to subfield. If none exists the following error messages are thrown.

3	Informational	Undefined variable: to File /home/spjdco5/public_html/spjdc.net/drupal7/sites/all/modules/date/date_migrate/date.migrate.inc, line 142(file: /home/spjdco5/public_html/spjdc.net/drupal7/sites/all/modules/date/date_migrate/date.migrate.inc, line 142)
3	Informational	Undefined variable: to File /home/spjdco5/public_html/spjdc.net/drupal7/sites/all/modules/date/date_migrate/date.migrate.inc, line 154(file: /home/spjdco5/public_html/spjdc.net/drupal7/sites/all/modules/date/date_migrate/date.migrate.inc, line 154)

The class should determine whether there is a 'to' subfield and if not skip this test.

One more thing. Considering that it has been nearly 9 months since the last version and over 7 months since the last dev version, and there have been at least two patches to adapt to new versions of migrate, can you roll a new release incorporating the changes.

@Mikeryan: I've use your #16 patch and all works well, start and end date are registered, except for this issue: dates are imported 1 day back!

For example:

source dates:

• start date: 2005-07-08
• end date: 2005-07-10

resulting imported dates:

• start date: 2005-07-07 <- Notice the day before!
• end date: 2005-07-09 <- Notice the day before!

How can this happen?

Thank you for helping me

It is likely that you are having timezonebissues where the modulebis converting from your tz to utc. One fix is to append 00:00:00 to dates before importing.

Thank you rsbecker for your suggestion: I've tried it but doesn't work.

Instead, specifying precisely the timezone, everything works perfectly:

$this->addFieldMapping('field_period:timezone')
         ->defaultValue('Europe/Rome');

Thank you very much!

This patch has been incorporated into the consolidated patch at #2034231: [META] Integrated patch for migration changes.