Integration with Migrate module

Yeah, we didn't get the final release of Migrate 2.0 out until DrupalCon, and I haven't really had time to pursue getting support into contrib modules. Should be simple - copy pathauto.inc to pathauto.migrate.inc, reference it in the pathauto.info, add hook_migrate_api() - I can submit a patch to the pathauto queue if you'd like.

OK Dave, here it is (for D7).

And for D6.

Rerolled as a submodule, with examples and tests.

And for D6.

No, but I think putting the migration support into a separate module addresses this (no migrate overhead in pathauto itself).

Yes, I may have gone overboard in the pathauto case, but I'm trying to establish a new design pattern for migration integration (see #1180612: Support for migration for a case with slightly more substantial examples and tests), and thus applying it consistently. If you prefer, I can define migrate_hook_info() (probably a good idea anyway) and reroll the original patch accordingly.

#1181826: Define migrate_hook_info()

This has gone a long time without getting in. I simplified the whole thing and just put it straight into pathauto. I didn't attempt to port the tests since they appeared to need another one of the submodules, but I had an active use for this patch and it completely worked as advertised.

Updated with latest code from migrate_extras, and moved hook_migrate_api to the migrate.inc file.

Not only that, but to work with Migrate 2.5 or later the handler needs to be registered in hook_migrate_api(). I'll reroll...

'field handlers', actually.

Can we expect this patch Migrate 2.5+ api to be ported ?
Integrate it into pathauto is the best practice :)

I tried the patch, and I am a bit confused. It doesn't seem to *DO* anything,

It has a prepare function:

public function prepare($entity, stdClass $row) {

but the row, which contains "the $row argument is an object containing the data after prepareRow() and any callbacks have been applied." according to Migrate module "Commonly implemented Migration methods") in the migrate module's docs, is not used.

When I try to run a migrate update on a node (after applying this patch), nothing changes on the node I have already imported. But I have verified with the debugger that the code is indeed executed.

Attaching a patch (made against 7.x-1.2)

+++ b/pathauto.migrate.inc
@@ -0,0 +1,58 @@
+      if (!isset($row->path)) {
+        $entity->path = array();
+      }
+      elseif (is_string($row->path)) {
+        // If MigratePathEntityHandler->prepare() hasn't run yet, support
+        // the alias (set as $entity->path as a string) being formatted properly
+        // in the path alias array.
+        $path = $row->path;

$row is a representation of the source data, and in a general-purpose destination handler we cannot make any assumptions about the form of the source data. This will work for a Drupal-to-Drupal migration, but not for migrations from other systems. It's up to the migration to map the appropriate source field to 'path', and here we would use that as $entity->path.

...do we need to consider/prevent any errors if the user has an competing pathauto migrate handlers (older version of Migrate Extras and a newer version of Pathauto enabled)

Migrate supports disabling handlers by name - this is done through the UI at admin/content/migrate/configure, and the variable migrate_disable_handlers lists handlers that should be ignored. So, I would suggest an update function disabling migrate_extra's handler along the lines of:

// Huh, Migrate is doing extra serialization, guess we need to mimic it here...
$disabled_handlers = unserialize(variable_get('migrate_disabled_handlers', serialize(array())));
$disabled_handlers[] = 'MigratePathautoHandler';
variable_set('migrate_disabled_handlers', serialize($disabled_handlers));

I'll roll a new patch...

OK, this is the patch from #16 with two changes:

1. Changed the class name from MigratePathautoHandler, which is the same class name as the migrate_extras handler, to PathautoMigrationHandler (better module namespacing).
2. Per Dave's suggestion, changed registerTypes() to use simply 'entity'.

I've tested both with and without migrate_extras enabled and it works fine in both situations - with 'pathauto' mapped to 0 in the migration, alias generation is disabled during migration and the value mapped to 'path' gets used. There'll be a tiny performance hit from the redundant handler, but I think it's fine since this will be one of the (big) nails in the coffin of migrate_extras as a whole, not worth introducing the update function. Dave, if you would like to disable the migrate_extras handler let me know and I'll add the update function.

Umm, helps to actually attach the patch...

Is it actually necessary to include pathauto.migrate.inc in pathauto.info? It looks like it's unnecessary, since the migrate module uses hook_hook_info().

hook_hook_info() allows for the autoloading of the .inc file for calling hook_migrate_api(), but adding the file to .info allows for autoloading of the destination handler class. Now, I think normally you should always have the hook called before any use of the class, but I feel better to be sure that the class is in Drupal's code registry and always available.

Bump... If there are any watchers here (besides badrange and EclipseGc, who contributed iterations of the patch) who can test and move this to RTBC, that would be great.

The patch in #26 applies cleanly against pathauto 1.2. It removes the warning ["pathauto" was used as destination field in "" mapping but is not in list of destination fields] when viewing the Migration UI registration, and it solves an issue I was seeing where aliases were being duplicated for each node that was imported.
Thanks!

Forgot to change the status after my testing.

Works well, please commit.

Please commit this!

Dave, patch in #26 goes green, can you commit it?