Problem/Motivation

It'd be great to be able to only migrate menu links from certain menus (in other words - to filter links by bundle).
We already have these availabilities for nodes and taxonomy terms:

As a workaround, you can accomplish the same outcome using skip_on_value/empty. See comment #6 for an excellent explanation and examples!

It will be also possible to achieve with #3069776: SQL source plugins: allow defining conditions and join in migration yml, but the filter my menu name seems as important as filter by node type or taxonomy vocabulary. I think it should exist directly in MenuLink plugin.

Other counterpoints:

  • An optional config like this one at the source level can make things like migrate-status (the drush command or its GUI equivalent) more informative / better representations of what you're doing.
  • There's a speed/performance benefit to limiting items during the source phase rather than skipping in the process phase.

Proposed resolution

Add a condition by menu_name to the existing menu_link source plugin. As a result, links can be limited in the following way:

source:
  plugin: menu_link
  menu_name: [main-menu, navigation]

Remaining tasks

Review, add change record, commit.

Issue fork drupal-3064016

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alisonjo2786 created an issue. See original summary.

alison’s picture

Patch in progress.

alison’s picture

Issue summary: View changes
alison’s picture

Maybe to-do: Rename "menu_names" config key b/c too similar to existing field, menu_name -- right? or?

Maybe to-do: Rename this plugin to better match the plugin it's extending (menu_link)??

alison’s picture

Status: Active » Needs review
xurizaemon’s picture

Can this be done already using Yaml? Eg, import only menu items in "navigation" or "user" menus:

  menu_name:
    source: menu_name
    plugin: skip_on_value
    not_equals: true
    method: row
    value:
      - navigation
      - user

Or look up the mapped value from the menu migration, and skip any menu items not allocated to a migrated menu:

  menu_name:
    -
      plugin: migration_lookup
      migration: my_menu
      source: menu_name
    -
      plugin: skip_on_empty
      method: row

I haven't tested these, and corrections are welcome, just checking if this plugin is necessary?

Alison your proposed PR above does have the advantage that it could exclude a large number of items for consideration by preventing them showing up in the source.

DamienMcKenna’s picture

Agreed with @xurizaemon - this could be handled using the skip_on_value plugin.

I think this speaks to needing more HOWTO documentation on common scenarios to help people identify solutions that already exist.

alison’s picture

Thank you for the feedback! I do use the skip_on_empty/value thing, too, like to only migrate published nodes, and yet...

*Personally*, I really do want to limit the source data, when it comes to menu links (this thread), users, and URL aliases -- not just skip during processing.

Are y'all feeling like it seems to edge-case-y for a community plugin, or?

alison’s picture

Issue summary: View changes
alison’s picture

Issue summary: View changes
Matroskeen’s picture

Title: Source plugin to only migrate menu links from certain menus » Allow menu_link source plugin to filter menu links by menu name(s)
Project: Migrate Plus » Drupal core
Version: 8.x-5.x-dev » 9.3.x-dev
Component: Plugins » migration system
Issue summary: View changes
Status: Needs review » Needs work

I think this is a reasonable request and it can be a part of the default Drupal core plugin.
We already have similar conditions in Node and Term plugin, so why not follow the same pattern here?

skip_on_value is rather a workaround and not that useful for large datasets with many links.

I'm moving the issue under the Drupal core project and will open a merge request soon.

Matroskeen’s picture

Status: Needs work » Needs review

The first commit contains only test changes, so it failed as expected.
I also added a draft change record: https://www.drupal.org/node/3219548

This is ready for review 😊

Matroskeen’s picture

Pushed one more commit with documentation improvements.

It might look a bit out of scope, but:
a) We need to edit the documentation of child classes to point that the parent class has some configuration keys;
b) We missed somehow adding documentation for menu link plugins in #3199741: Add documentation for remaining source plugins;

Matroskeen’s picture

Issue summary: View changes

I reverted my previous changes to plugins documentation because it will be handled here: #3225227: Fix source plugin documentation.
Also, updated the IS a bit. Still needs review 👀

danflanagan8’s picture

Status: Needs review » Needs work

@Matroskeen, this looks really good. I noted in GitLab that the comment is repeated. Other than that it looks nice. The tests make sense. And the new code in the MenuLink source plugin follows the same pattern as in the Node source plugin, which is good. Things are consistent.

I tested the patch locally as follows. I applied the change to MenuLink and then ran a full migration from the drupal7 fixture. Everything was fine.

Then I updated the menu link migration to look like this:

source:
  plugin: menu_link
  menu_name: menu-test-menu
  constants:
    bundle: menu_link_content

I ran a fresh migration from the fixture and correctly saw that menu link content was migrated for the Test Menu but not for the Navigation menu.

Then I changed the menu_link migration again to read as follows:

source:
  plugin: menu_link
  menu_name: 
    - menu-test-menu
    - navigation
  constants:
    bundle: menu_link_content

This time the menu link content was correctly migrated for Test Menu and Navigation.

After the comment gets updated, this will be RTBC.

Matroskeen’s picture

Status: Needs work » Needs review

Whoah, no idea how that happened 😳
Thanks for the review! Hopefully, it's good to go now.

danflanagan8’s picture

Status: Needs review » Reviewed & tested by the community

Ha! No worries. Looks good now.

quietone’s picture

Status: Reviewed & tested by the community » Needs work

Just noting this feature is not needed by core, which is the benchmark for adding features to migrate.

My two cents is that this case is fine, it is following existing patterns for adding a condition on a content source plugin. However, this does need tests, just some additional test cases to \Drupal\Tests\menu_link_content\Kernel\Plugin\migrate\source\MenuLinkTest should be fine. Setting to NW for that.

Also, I'll check with the other migrate maintainers.

Matroskeen’s picture

Status: Needs work » Needs review

@quietone, thanks for looking at this issue.

I agree that it's not needed by core, nor node_type property by Node source plugin, nor bundle by Term source plugin. However, it increases the DX and doesn't add too much complexity.

It would be partially covered when #3069776: SQL source plugins: allow defining conditions and join in migration yml lands, but we're not there yet. Besides, filters by bundle are essential and should be available in original source plugins in my opinion.

Additional tests cases are already available in \Drupal\Tests\menu_link_content\Kernel\Plugin\migrate\source\MenuLinkTest.
You can have a look: https://git.drupalcode.org/project/drupal/-/merge_requests/813/diffs#b12...

quietone’s picture

Status: Needs review » Reviewed & tested by the community

@Matroskeen, my apologies for missing that the test was there.

I reviewed the patch and the test both look fine. And nice to see an example included in the doc block. (That must be second nature now for you, Matroskeen).

There were no objections from any migrate maintainer for adding this to core. This is bringing menu in line with other source plugins that allow selection by bundle. As benjifisher pointed out it is 3 lines of 'dead simple' code with tests and documentation.

Therefore RTBC.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

I think this is fine to make really simple - it does seem like a useful feature.

Committed 510b590 and pushed to 9.3.x. Thanks!

  • alexpott committed 510b590 on 9.3.x
    Issue #3064016 by Matroskeen, alisonjo315, danflanagan8, quietone: Allow...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.