Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
We are using Wetkit 4.5. (soon to be Wetkit 4.6.) and Wetkit Deployment.
When adding links to the Megamenu (Insert menu) the system stores the local system path (.../taxonomy/term/1353).
However Taxonomy tid's are not always the same in the source and target environments.
How can we get around this issue?
Comment | File | Size | Author |
---|---|---|---|
#11 | megamenu_system_path-2723471-11.patch | 616 bytes | sylus |
Comments
Comment #2
sylus CreditAttribution: sylus commentedI assume this is for a deployment workflow?
If so you should always use UUID's. In this case instead of TID's you would use UUID contexts where possible.
Both views + panels context can take UUID arguments instead of tids so will work across environments.
Comment #3
sylus CreditAttribution: sylus commentedThis was talked about a bit over: https://www.drupal.org/node/2636504
Comment #4
sylus CreditAttribution: sylus commentedComment #5
joel_osc CreditAttribution: joel_osc at OpenPlus commentedI think the issue is that when you create a menu link it is of the form node/[nid]... and then it deploys the prod exactly as it is in auth and the menu link may or may not point to the correct node.
Comment #6
sylus CreditAttribution: sylus commentedI thought this was what Entity Menu Links works around. It makes sure that menu links get deployed via UUID not NID.
Comment #7
shawntremere CreditAttribution: shawntremere commentedjoel_osc is correct in his description of the problem. We haven't noticed the problems with Node Ids, it has been with taxonomy Ids as there are several that have different IDs on auth and prod. Entity Menu Links is currently installed but does not appear to be working as suggested.
Comment #8
sylus CreditAttribution: sylus commentedI am still a bit confused about this, can you give a quick reproducible scenario that I can check out to confirm this behavior? Again no step too small to list. :)
It was mentioned that there is no issue with node/nids in the menu path but there is with tids in the menu path? Just wanted to confirm.
A reproducible scenario can start from the assumption that there is a base drupal wxt source + dest site already configured.
Basically what terms + menus need to be added and in what order so that can I reproduce this problem in its most simplest base case.
Thx a bunch!
Comment #9
shawntremere CreditAttribution: shawntremere commentedHere is a rundown of our situation.
Add a menu link /en/admin/structure/menu/manage/megamenu/add
The path field can only be saved as a drupal path (taxonomy/term/2159), you can't use an alias, or uuid for that matter.
We are adding the link on the authoring server. So the mega menu link gets deployed to production, and when you log in you can look at the menu link as see the path is:taxonomy/term/2159. The problem is that the term 2159 on authoring is Regulations, Permits and Licensing (for example) and is Business Basics and Financing (for example) on Production so the link is going to the wrong url.
The same issue could happen with node/nids we just have not come across this yet.
Comment #10
sylus CreditAttribution: sylus commentedThat should be enough for me to go on to debug, thanks for the steps! The taxonomy should be synced from the moment it was created on the source side. I wonder if you went to both taxonomies, if they have the same UUID. I'd bet they don't.
That said I will try to scenario today / tomorrow and report back, thanks a bunch!
Comment #11
sylus CreditAttribution: sylus commentedTook me forever to find the culprit turns out entity_menu_links was calling entity_get_info with 'term' and not 'taxonomy_term'.
Attached a patch distro will use against entity_menu_links.
Comment #12
sylus CreditAttribution: sylus commentedComment #14
shawntremere CreditAttribution: shawntremere commentedsylus,
This appears to be working on our development environment. Will do some further testing and will update on the status, but it's looking good so far. Thanks for looking into this, really appreciate it.