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.
The enabled column should come before the expanded column on the menu admin page so it's easier to read.
This patch also removes the 'has children?' check for ticking the expanded checkboxes. A menu item can still be set to expanded even if it has no children.
Another issue is that status messages are non-existent for adding or editing a menu or menu item, but that's out of my league. Maybe someone else could help out with that?
Comment | File | Size | Author |
---|---|---|---|
#8 | menu_touches.patch | 1.45 KB | Rowanw |
#8 | menu_columns_01.png - proposed by Senpai | 21.36 KB | Rowanw |
#8 | menu_columns_02.png - with current patch | 20.94 KB | Rowanw |
menu_touches.patch | 1.48 KB | Rowanw | |
Comments
Comment #1
Rowanw CreditAttribution: Rowanw commentedComment #2
Senpai CreditAttribution: Senpai commentedWorks as advertised, with no ill effects. Before I RTBC, I wanted to ask the Collective if disabling the Expanded checkbox for menu items who have no children would be a good idea.
We could do this at drupal_render time by checking for the existence of child elements, and setting the checkbox to 'disabled' inside the theme function so that it can be overridden by designers if necessary. Good idea, or bad idea?
Comment #3
Crell CreditAttribution: Crell commented-1 to removing the "expand" checkbox if a menu item has no children. Just because it doesn't now doesn't mean it won't have them added in the course of using the site. I may want to set up menus that should expand once content gets added. I don't want to have to come back and set it again.
Comment #4
Rowanw CreditAttribution: Rowanw commentedDitto for #3, that was the whole reason I made the change.
Comment #5
Senpai CreditAttribution: Senpai commentedI wasn't referring to removing the 'expanded' checkboxes, but merely disabling them if the menu item doesn't have any children. Ok then. No support for that idea.
Since that doesn't fly, how about moving the 'enabled' column to position #1? It makes a LOT of sense from a user interface perspective that if the first column is a known width then we could have the two most important things on the page, the 'enabled' boxes and the 'draggable' icons, right next to each other. Yeah?
Comment #6
Crell CreditAttribution: Crell commentedMight that be confusing for the DnD functionality? You'd have an extra checkbox sitting between you and the label you're targeting for the drop-target.
Comment #7
Senpai CreditAttribution: Senpai commentedHmmm, possibly, but probably not. I might just do this and see how it looks. I'm betting that with the proper theming, it won't be bad at all. Functional is the point here, after all.
Comment #8
Rowanw CreditAttribution: Rowanw commentedUpdated patch to latest release (had 2 lines offset).
I tried Senpai's idea to put the enabled column first, but since it sits between the move icons and the menu names it looks quite confusing, see attached PNG. If the checkbox was before the move icon it might look a little better, but that opens up inconsistencies with other D&D areas within Drupal. For this reason I think the columns should stay as they are in the current patch.
Patch summary again:
Comment #9
ScoutBaker CreditAttribution: ScoutBaker commentedWhile, in theory, I like the idea of having the Enabled column first, I agree with Rowanw that it looks a little odd from a usability perspective. It's easier for me to visualize what I'm moving when the Enabled column is second.
Comment #10
Pancho+1 The patch in #8 seems to be good.
I wouldn't move the enabled checkbox to the front either. Aside from D'n'D drawbacks this would also imply, disabled menu items wouldn't play any role, which is not the case.
Comment #11
Rowanw CreditAttribution: Rowanw commentedRTBC?
Comment #12
Gábor HojtsyCommitted, thanks.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.