Add menu destination plugins

There can be a bunch of hooks that fire when you save menu items and menu links. I suggest writing a dest plugin that calls the right menu CRUD API functions.

Caveat: I dunno if those API functions call menu_rebuild() but if they do thats a performance killer.

I will be very glad to review/continue this.

@agentrickard: It would be great if you can post a patch soon, so I do not start from scratch.

Ok, I will test this soon, in the meantime a patch.

Sorry, I will include the info file changes on the next patch.

Ok, here the same patch with the info file additions.

I have just tested MigrateDestinationMenu and it works fine.

As mentioned the only really thing to change could be replacing the menu_{save,delete}() functions with custom ones that clone its functionality except from the call to menu_cache_clear_all(), and then on MigrateDestinationMenu::postImport() for menu_save clone and on MigrateDestinationMenu::postRollback() for menu_delete clone call the cache clear.
I guess that's the only way to avoid rebuilding the cache for each menu_custom.

Please let me know about your opinions on that approach for menu_custom's and I could code that change(I am importing too little menu_custom's to really see the impact).

I will review the MigrateDestinationMenuLinks soon.

Copied from table_copy.inc, eh?;) There's some cruft that's not relevant for your plugin - specifically, setting tableName and keySchema, for example, which are specific to table_copy.inc.

There's no reason to use bulkRollback without a bulk API to call - just implement rollback(), deleting one menu/link at a time.

In the prepare(Rollback) and complete(Rollback) methods, you're passing 'Menu' and 'MenuLinks' as the destination type - this corresponds to the values passed to registerTypes and the convention is lower-case underscore delimited: menu and menu_links.

Thanks.

@mikeryan - So are you recommending deleting bulkRollback()? That's what I interpreted from your comment.

You also talk about prepare(Rollback) and complete(Rollback) methods, in moving the registerTypes convention to lower-case underscore delimited (menu and menu_links), I'm assuming this means:

    migrate_handler_invoke_all('Menu', 'completeRollback', $menu_names);
    migrate_handler_invoke_all('Menu', 'complete', $object, $row);

&

    migrate_handler_invoke_all('MenuLinks', 'prepare', $object, $row);
    migrate_handler_invoke_all('MenuLinks', 'complete', $object, $row);

but also in menu.inc the same functions need to be changed in prepareRollback() & completeRollback().

I'm still exploring this module, but need this function, so am trying to help this issue along.

Here's a patch for review though based on your feedback.

I didn't mean to remove rollback capability completely - just implement rollback() (one item at a time) instead of bulkRollback() (which only makes sense where the core API has a bulk delete function).

In the MigrateDestinationMenuLinks prepareRollback() and completeRollback methods(), the first argument to migrate_handler_invoke_all() should be menu_links (matching the calls in prepare() and complete()).

I've update the menu_links destination a little.

It's working well for saving menu link items.

What is needed is some help with Stub migrations.
Some menu items are imported before their parents.
I've implemented a createStub function in my custom class that extends MigrateDestinationMenuLinks.
And it does create a stub menu link when it runs.

But it doesn't update the Stub when the parent link is imported later.
Any pointers appreciated.

This one works with Stub migrations too.

Now with a proper patch

MigrationDestinationMenuLinks should implement rollback(), instead of bulkRollback(), as per Mike's comment in #14.

MigrationDestinationMenu doesn't seem to implement rollback at all.

Thanks. I'll work on switching menu and menu_links to rollback(), then.

Ok, I took the patch in #18, implemented rollback() for menu.inc, and also tweaked and added comments to prepareRollback() and completeRollback(). The rest should be the same as before. I'll do the same for menu_links.inc tomorrow.

And now with rollback() implemented for menu_links.inc.

Other than that, I did a basic implementation for menu and menu links, and it works for me so far. I'll try something more complicated next that forces menu link stubs to be generated.

Alan, stub generation works for me as well. I've cleaned up the comments some more, and reordered a couple functions so that menu and menu_links are consistent. This patch is ready for review.

Here's how I implemented createStub(), in case anyone else wants to use it to test with. This works for a D6 to D7 migration. For other sources, just change plid and menu_name to the right names.

  /**
   * Creates a stub menu link, for when a child is imported before its parent
   *
   * @param $migration
   *  The source migration
   * @return
   *  int $mlid on success
   *  FALSE on failure
   */
  protected function createStub($migration) {
    // if plid is 0, that means it has no parent, so don't create a stub
    if (!$migration->sourceValues->plid) {
      return FALSE;
    }
    $menu_link = array (
      'menu_name' => $migration->sourceValues->menu_name,
      'link_path' => 'stub-path',
      'router_path' => 'stub-path',
      'link_title' => t('Stub title'),
    );
    $mlid = menu_link_save($menu_link);
    if ($mlid) {
      return array($mlid);
    }
    else {
      return FALSE;
    }
  }

Edit: removed menu_cache_clear_all(), as the cache is now cleared in postImport() per #25.

Some cleanup - comments, variable names changes, ... The one meaningful change is to do menu_cache_clear() in postImport/postRollback, so it only gets done once per import process, not for every item imported.

Untested... Sam?

Tested and works as expected.

For menu.inc:
menu_cache_clear_all() is called on import and rollback, once for each menu.

For menu_links.inc:
menu_cache_clear_all() is called once during postImport and postRollback, rather than for each link.

Committed and pushed for D7, thanks to all who contributed!

Leaving open for backport to D6, should anyone be motivated...

I have just created a follow up on #1621906: Support destination system of record for menu links migrations

Adds additional detail.