Drupal 11 compatible release for 8.x

Thank you.

Local patch might be good till you have time to follow the CR:
https://www.drupal.org/node/3447576 →

Should you have 1 hour time, technically only two major changes:

• CSS, roughly costs you less than 15-45 minutes using thoughtful reversed search and replace via any code editors. Reversed means starting from more specific to global as opposed to written docs, thus replacements must start from is-ultimenu-canvas-off, etc. to is-ultimenu-canvas, not vice versa.
• Saving both Block and UI forms, costs 15 seconds.

I am interested to know why it would take you days so we can improve docs to help smooth upgrade?

Hey, sorry, but I cannot really justify to the client why they need to spend my time on reworking this when the current code works and is compatible with Drupal 11. We have a lot on our plate and reworking the menu system is not on the list. It might be an hour or it might be more. The changes to go to 3.x are definitely breaking. I am certain there were good reasons to make them. I am not questioning that in the slightest. If we were starting fresh, I would be using 3.x, but that is not where we are.

I think they will opt to just go off the reservation so to speak.

Understood, thanks :)

Another obvious change in 3.x is it is no longer relying on media queries for the most parts, instead on touch and non-touch devices, since that is the best way to spot hoverable states.

This helps reduces CSS complexity thanks to more precise detections. On the other hand, this has a minor consequence -- it no longer supports resizing which is normally done by devs, anyway, hardly end users. You can always use media queries should you need to support resizing, though.

See the CR above for more.

Pressing CTRL/CMD + M to bring browsers' responsive view is more reliable than resizing for devs.

We'll keep it open for feedbacks if anything useful to help better upgrades.

Hey Gaus,
You convinced us and we are biting the bullet and attempting to get our site using the 3.x branch. I have it all looking identical when loaded, however, I have an instant of jumpiness on both mobile and desktop where the menu is styled wrong for a few hundred milliseconds before it straightens itself out. I tried inlining a couple key styles to no avail. The jumpiness is not present in the 8.x version. I am wondering if I has to change to "no longer relying on media queries". I am going to dive into that next. If you have any suggestions, I am all ears.
Thanks

> however, I have an instant of jumpiness on both mobile and desktop where the menu is styled wrong for a few hundred milliseconds before it straightens itself out.
Sounds like FOUC. Visit /admin/help/ultimenu, search for FOUC.

Or re-read the provided links in the CR.

In short, if FOUC, you must update your page.html.twig with the new off-canvas classes.

OK, progress has been made. I added the is-ultimenu to the classes in the template for my html element and added the is-ultimenu__canvas-on / is-ultimenu__canvas-off as needed to my page tempages. All that is looking nice. I also went through my styles and switched the styling for the mobile/desktop to rely on the is-ultidesktop or is-ultimobile class in the html element to align with the way that the module works now.

My last issue is with the desktop. On my staging site, I am seeing a flash of bad styling. Watching the page load, I am seeing the is-ultimobile class appear for an instant and then get replaced by the proper is-ultidesktop class. In that instant, things don't look so nice. I checked my html element in the template, but it is not coming from there. This seems like a possible bug. I could probably change my styles not to rely on the is-ultimobile which seems like not the way it should work. I have not overridden the module js.

This is a little off the path of this issues original topic. If you need me to start a new ticket, I can.

> added the is-ultimenu to the classes in the template for my html element
No need, already taken care of. You can remove yours.

Only page.html.twig is required for an edit.

However seeing another FOUC, what about adding is-ultidesktop class via MYTHEME_preprocess_html() function, and add conditions as needed if not sidewide.

The default is is-ultimobile since I hardly have desktop versions.

Adding both classes should not be a major issue, since one will be swapped immediately when JS kicks in.

We should add an extra variable to this function later to check for Ultimenu existence for easy copy as a condition. Not crucial for sitewide Ultimenu.

If that works, feel free to create a new bug ticket.

> The default is is-ultimobile since I hardly have desktop versions.
I think they are still pretty common to have a desktop version, especially for existing sites. I am not as familiar with the code as you, but it is not clear to me why the JS needs to add the .is-ultimobile to html element before it has figured out if we are touch or not. I will look to work around it as I am sure you have your reasons.

I think we can close this one out. Thanks for your attention.

I just have time to work on this FOUC.

Ultimenu:3.0.6 should got this cover.

More details in the updated CR: https://www.drupal.org/node/3447576 →

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