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:
- https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/modules/node...
- https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/modules/taxo...
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.
Comment | File | Size | Author |
---|
Issue fork drupal-3064016
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:
- 3064016-menu-link-source-allow-condition-by-menu changes, plain diff MR !813
Comments
Comment #2
alisonPatch in progress.
Comment #3
alisonComment #4
alisonMaybe 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)??
Comment #5
alisonComment #6
xurizaemonCan this be done already using Yaml? Eg, import only menu items in "navigation" or "user" menus:
Or look up the mapped value from the menu migration, and skip any menu items not allocated to a migrated menu:
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.
Comment #7
DamienMcKennaAgreed 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.
Comment #8
alisonThank 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?
Comment #9
alisonComment #10
alisonComment #11
MatroskeenI 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.
Comment #13
MatroskeenThe 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 😊
Comment #14
MatroskeenPushed 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;
Comment #15
MatroskeenI 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 👀
Comment #16
danflanagan8@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 theNode
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:
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:
This time the menu link content was correctly migrated for Test Menu and Navigation.
After the comment gets updated, this will be RTBC.
Comment #17
MatroskeenWhoah, no idea how that happened 😳
Thanks for the review! Hopefully, it's good to go now.
Comment #18
danflanagan8Ha! No worries. Looks good now.
Comment #19
quietone CreditAttribution: quietone as a volunteer commentedJust 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.
Comment #20
Matroskeen@quietone, thanks for looking at this issue.
I agree that it's not needed by core,
norHowever, it increases the DX and doesn't add too much complexity.node_type
property by Node source plugin, norbundle
by Term source plugin.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...
Comment #21
quietone CreditAttribution: quietone as a volunteer commented@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.
Comment #22
alexpottI think this is fine to make really simple - it does seem like a useful feature.
Committed 510b590 and pushed to 9.3.x. Thanks!