I would like for the new menu.module to deprecate my contrib menus.module. It already incorporates much of the same functionality; however, a couple of features are missing. I would like to be able to mark menu items as always being expanded. So the following menu is possible:

Where the item 'jim' is always expanded regardless of the current page.

The only other difference is that my menus.module does not require a path/URL. For example, item 'jim' above does not have to be a link, in which case it serves simply as a grouping item. In menus.modules, these items can be expanded by linking to the current page with an additional query item (i.e. http://.../this/page?menu_expanded[79]=1).

I will create and submit patches that implement this same functionality in menu.module.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jhriggs’s picture

FileSize
7.98 KB

This patch addresses the first item. Menu items with children in the default Navigation menu and user-defined menus can be set to be always expanded. An "Expanded" checkbox has been added to the menu item edit form (admin/menu/item/edit/*), and an "expanded" column has been added to the menu list table (admin/menu). An 'expanded' column is added to the menu DB table, and database.* and updates.inc have been appropriately updated. It is quite a small patch for some really nice extensibility IMO.

jhriggs’s picture

Setting to patch.

matt westgate’s picture

+1

There are some sites where I would like to expand by default the 'create content' item since it only contains a couple of children links. This makes it more obvious what an user can do by quickly viewing what they can create and also saves a 'create content' click for experienced users.

TDobes’s picture

I would certainly love to see this functionality as well... but do we need to add a column in the db to implement it? Is there a reason why we couldn't just add a MENU_ALWAYS_EXPANDED bit, which would end up getting stored in the "type" column?

jhriggs’s picture

FileSize
3.99 KB

Great point, TDobes! This patch does just that: uses a MENU_EXPANDED bit in the type field. No DB changes necessary.

JonBob’s picture

I'm ambivalent about this change. It was considered during the Drupal 4.5 round of menu system changes, and dropped. The problem is deciding where function ends and presentation begins. We have our theme system in order to separate function from presentation, and so we try to keep as many decisions as possible that relate to presentation confined to theme functions. Each option we add to the menu administration constrains further the possible menu presentations.

It sounds paradoxical that adding choices would limit options, but consider what happens when the menu is presented as a DHTML, dynamic menu. Does this "always expanded" make sense in this case? Should it be "initially expanded" instead? I guess what I'm saying is it's easy to look at the stock presentation of a feature and think of it as the way things have to be, rather than just one possibility. I'm not necessarily opposed to this change, but we have to think about what the theme is responsible for and what the menu system itself is responsible for.

By the way, most uses of this feature I can think of could be easily accommodated by just disabling the parent menu item. For example, in mathias' example, just disable "create content" and rename the child links appropriately, and you have basically the same effect without a patch. The only thing this lacks is the visual grouping the "always expanded" method confers.

If this does get implemented in core, it should indeed be done with a flag in $type rather than a new menu field. Setting to "active" for that reason.

JonBob’s picture

Follow-ups got crossed.

jhriggs’s picture

I completely agree that it is up to the theme to determine the presentation. That's exactly why we have theme_menu_tree(). A theme could easily ignore, enhance, or undo any always-expanded settings. In that respect, I guess you could consider this a "hint" to the theme as to how the admin wants the menu to be displayed. The default will display it expanded. This is no different from how MENU_IS_LOCAL_TASK is a "hint" to the theme. It is usually implemented as a tab, but it could be used by a theme to revert the look of the menus to that of 4.4 (yuck!) or display it some other way.

Personally, I think this setting could result in a big gain in extensibility and usabilty, especially when used strategically. I think the grouping is really important in some cases. Disabling the parent doesn't help my situation, for example.

Dries’s picture

Note that we are currently in a feature freeze. It is still unclear how wanted/important this addition is. Also, I'm a little worried about the menu module's complexity: it is becoming increasingly hard to understand the code, and the people who don't exploit all the special features, pay a performance penalty for these kind of special cases. I'm not going to commit this patch yet.

moshe weitzman’s picture

+1 from me. The functionality is useful, and I concur with the argument that this bit is a *hint* to the theme system, who may choose to ignore it or not.

jhriggs’s picture

FileSize
3.99 KB

Here is an updated patch that simply syncs with HEAD and fixes a missing CSS class in the menu table on 'admin/menu'.

pbowyer’s picture

+1

I'm missing this feature in my design. Drupal provides so many good ways of organising content, and expanded menus are one of the necessary ones - I can't just have the parent item inactive!

trinux@linuxcordoba.org’s picture

I'm missing this feature in my design. Please update.

trinux@linuxcordoba.org’s picture

I'm missing this feature in my design. Please update.

Dries’s picture

Committed to HEAD.

Anonymous’s picture