In-depth Module Documentation

Awesome thought, I added a few more lines, and a link to the README.

Users of the module should feel free to add documentation on advanced topics, such as how to add features, and create custom solutions, like for example Leaflet → does.

Users could simply add the pages, or suggest them here, depending on what they feel is best.

Hi,

I'm trying to replicate this functionality without requiring a module since I'd like to avoid leaving anything in the web server directory.
Oh boy drush has been a great addition to Drupal since I was playing with D5 but many things just make more sense as
drush php:script

I've been away from Drupal development from quite a bit and I'm taking this opportunity to get a better understanding of its new architecture.

So I'd like to ask a couple of questions about your design decisions.

Why did you add event management?
I checked the code of menu link content core module and it doesn't add any event.

Why are you skipping some translatable fields in getTranslatableFields other than the obvious ones like "langcode"?
Shouldn't be there an API to know which fields to skip?
creatDuplicate() doesn't skip any.
I plan to check what all the entity clone modules do, but your explanation would be appreciated.

thx.

Hi,

I'm a bit puzzled by your reasons for avoiding a development module that can be added/removed very quickly using composer, and instead going for a custom approach that will be hanging on the server anyways :) Though I do respect people's choices.

- "Why did you add event management?" - I added it to give the possibility of menu items alterations before import (instead of hooks), while also later adding a functionality that I needed in ImportSubscriber.php

- "Why are you skipping some translatable fields?" - Can't really give strong reasons, but when I was working on the translation part, I was gradually adding whatever fields were required. I liked having a bit of control over the fields and understanding what they're for. My mentality was to not add something that was not needed or something that was not known to me. Once it was working well, I kept it as it was. And of course avoiding anything that contained "uid" because the exports and imports are supposed to work between different sites.

The Documentation structure has been created, the guide is published. The missing parts will be completed once version 4.x is ready.

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

I finally tried the new version and it works great, thanks!

Initially I thought that it was annoying that I had to create exports and imports, but I guess some users want to use a GUI for this ...

Anyway, I still use Drush, but still needed to create exports and imports. I wasn't sure about the naming, like could they have the same machine name, and it turns out they can. So maybe, in the documentation this would be possible, to make it simpler for new users to get started? I left a note in https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → .

Also, it seems like only JSON-format is supported for Drush import, not YAML ... maybe this could be added in the README, if it is correct?

Hi @ressa,

Thank you for the feedback.

Indeed, I don't deny that having to create export types and import types could be both convenient and inconvenient. I was thinking at some point about maybe creating a 3rd option something like "quick action" where you could export one or more menus on the fly. That idea was never evolved into a plan, since I haven't received yet any feedback, but if you're the first to mention it, I might consider getting back to it to make the module more flexible for both sides.

As for the notes in the documentation about the JSON and YAML files, I am 100% positive that both YAML and JSON work with Drush. I even retested on my Drupal 11 to ensure what I am saying. Could you please describe the steps to reproduce Drush not working with YAML? At the moment I removed the lines that were saying that Drush does not support YAML, as I could not confirm this.

Thank you!

Thanks for a fast reply @bbu23!

You're right, YAML does work also ... I am not sure what went wrong. Thanks for reverting my faulty updates :)

About the documentation: I think that using for example "Main navigation" and machine name main_navigation for both export and import in the examples will make it easier for users to more easily understand the concept ...

That way, the user can see that you can actually use the same ID, both when exporting and importing, i.e.:

• drush menu_migration:export main_navigation
• drush menu_migration:import main_navigation

About the new process overall, I think it's all right. I mean, I did like the convenience of previously just being able to run a Drush command, to both export and import a menu, without having to do any configuration. Would that be possible again? If it would take a big effort, then it's not that important, more a nice to have :)

No problem, @resssa. I'm glad that YAML works as well as expected.

I did see the suggestions about the naming, indeed that makes sense though I think what I wanted to avoid was to make it look like you have to use one menu as a name. I was thinking of more scenarios, from one menu, to menu per environment to menus grouped together.

Indeed, the examples that I posted in the documentation are far from what would be considered as good examples, so I'll consider your suggestion and update the page (hopefully in a timely manner).

As for the Drush command, I'll definitely re-evaluate what I was thinking of after the version switch. I'll see what I can do, I agree about the convenience for Drush users mainly, but not only.

Thank you for taking the time to evaluate the new version and contributing as always!

You're welcome! I am also very grateful that you build and maintain such a wonderful module, it really makes things a lot easier.

About wanting to highlight different scenarios, it is a very valid point, and I did think about that afterwards ... So perhaps using "My menus" and my_menus both places could work?

It sounds great that adding a pure Drush support might be considered, but if it's too much, nevermind -- it works fine. Though, Drush was originally created partially to automate GUI interaction, so maybe it's possible?

PS. I see now in the Documentation images that YAML says "N/A" under "Drush command", which I believe was also what I saw when it failed for me ... so the reason was probably that I had selected "File upload", wrongly.

I appreciate it, thank you!

Yes, my_menus seems good.

Sure, I'll think about this one (the Drush support).

Yes, it might be because I wanted probably to have examples from both Code export and Download export. But maybe it should be with both in both cases, and not "random".

@ressa I created an issue for the quick export/import, I will push a first batch of code in that direction if you're interested to check it out.
https://www.drupal.org/project/menu_migration/issues/3486499 ✨ Bring back the possibility of exporting and importing menus directly using drush Active

Thanks @bbu23, fantastic news! I did a review, and a few minor suggestions. It's awesome to have Drush support again.

🙌🙌🙌