Exportable via features

Absolutely, I welcome any contributions you may have.

subscribe - this would be nice functionality, and I'd be willing to generate a patch if FatGuyLaughing is no longer interested. One question - would you be willing to make the module explicitly depend on features, or should there be an admin option added to choose to use a machine name? Otherwise, there could be a scenario where a user has features enabled, the variables are generated using that machine name, features is disabled, and taxonomy_menu breaks...

thanks,

Adrian

@acrollet Take a look at http://drupalcode.org/project/taxonomy_menu.git/commit/428b60d I just committed the variables as machine names. That may get you what you want to some extent.

I'd rather not be dependent on features but I would totally be down with a ctools dependency.

I think what dstol provided is a nice start, but it still doesn't solve the issue that the taxonomy_menu_vocab_parent variable still refers to a mlid, which is not a proper export.

In order to solve this issue, I propose the following patch, which uses uuid when available to export a new variable, called taxonomy_menu_vocab_parent_uuid, which points to the UUID link path of the parent menu item.

There is still one step missing which is when to actually rebuild the menus: the code I added allows to properly export taxonomy menu variables, but it won't rebuild the menu automatically when needed.

+1 RTBC
Tested on one of my projects where parents does not matter and it seems to work well :)

Patch #6 doesn't work with latest version of uuid module because it doesn't handle menu items.

Fatal error: Call to undefined function uuid_menu_path_to_uri_transform() in /.../sites/all/modules/contrib/taxonomy_menu/taxonomy_menu.module on line 160

The problem of patch in #6 is that we store parent menu item twice - once as mlid and other as uuid. In this case if mlid is specified - then uuid is ignored.

I have rewritten taxonomy_menu so its store parent menu item only as uuid. For generating uuid i use functions from features modules - instead of mlid we store "menu-name:link-path".

This patch works for me well and taxonomy_menu is now fully integrated with features for export/import and revert

Fix for patch #10

One more fix :)

Finally patch with all fixes

Now 100% finally patch with all fixes

RTBC for me :)

Working for me as well :-)

Patch from 19 applied and merged to 7.x-1.x branch. Should appear in the dev release shortly.

The commit referenced in comment 23 has been reverted in the new dev version. The patch produced identifiers which were not truly unique, causing menus to be attached to the wrong parent in certain circumstances (see #1706260: Attaching to a menu item which has a path that is shared by other menu items may select the wrong one.). This will have to be reworked and recommitted.

Thanks!

I just rolled out 7.x-1.4, which makes the revert official.

Is there a way to rebuild menus via code? I've used _taxonomy_menu_rebuild($vid) within my module to force a rebuild. When I run a 'drush site-install' the code works perfectly. However, when I try to deploy my code to an existing Drupal site, and run a "drush updatedb", that function (_taxonomy_menu_rebuild) seems to go into a infinite loop. Any suggestions on rebuilding the taxonomy_menu?

Thanks,

Please open a new issue. For help with reporting issues, see here: http://drupal.org/node/73179

Here's how I solved this temporarily. Feedback welcome.

EDIT: this doesn't work when you revert from the command line, which doesn't play well with the batch api apparently. But if you're doing this more or less manually until an exportable option is available, simply comment out the call to batch_process() in taxonomy_menu.batch.inc (at the end of _taxonomy_menu_insert_link_items_batch()) each time you want to run this post_revert hook (don't forget to comment it back in after!).

/**
 * Implements hook_post_features_revert().
 *
 * Hook up vocabularies with menu items.
 */
function my_feature_post_features_revert($component) {

  if ($component == 'variable') {
    // menu router paths keyed by vocab machine name they should be attached to
    $paths = array(
        'blog_categories' => 'blog',
        'vocab2' => 'path-two',
    );

    foreach ($paths as $vocab => $path) {
      $menu_item = menu_link_get_preferred($path, 'main-menu');

      if (isset($menu_item['mlid'])) {
        variable_set('taxonomy_menu_vocab_parent_' . $vocab, $menu_item['mlid']);
      }

      module_load_include('module', 'taxonomy_menu');
      _taxonomy_menu_rebuild($vocab);
    }
  }
}

I guess 'needs work' is a better status.
#19 gives a patch which is initially RTBC anc committed.
#25 reverts the patch.#30 gives a possible solution to the problem.

One thing about #30

_taxonomy_menu_rebuild() expect $vocab as vocabulary id, so to fix it just replace to

module_load_include('module', 'taxonomy');
$vocabulary = taxonomy_vocabulary_machine_name_load($vocab);
_taxonomy_menu_rebuild($vocabulary->vid);

Has this ever been resolved? I would like to be able to export taxonomy_menu using Features, but the reliance on the mlid rather than a UUID brakes the export of the "parent" menu variable for me. Any suggestions much appreciated, thanks.

Inspired by the patch in #19 (which no longer applies to either the current dev or the released version of this module) I have rewritten it to use menu link UUIDs generated by the features_menu_uuid module. This patch detects if features_menu_uuid has been installed and it does nothing, even if applied, if that module is missing. To use this patch, you need to export the parent menu link using the features_menu_uuid module. I have tested it on my set-up successfully.

It should not confuse the parent with an incorrect menu even if there are multiple links with the same path, which was a limitation of #19 that caused it to be reverted in #25.

Unfortunately, my patch only works if the parent menu has been generated by the menu module and not if the parent menu comes from a view or some other entity that generates it dynamically. This is because features_menu_uuid only supports menu module menus, see a short discussion of this at #3124241: Set UUID for exported menu items that already exist.

Also, I have not attempted to force the taxonomy_menu rebuild as suggested in #30.

I have changed the issue meta to 7.x-1.x-dev as 7.x-2.x-dev has been marked as unsupported and looks like an abandoned branch. This patch is based of the somewhat supported 7.x-1.x-dev.

Thank you for your contributions.
Drupal 7 is no longer supported.
Closing this issue as outdated.