I wonder that it isn't (until now) possible to add menu items, that are visible in the breadcrumb but not in the menu tree. You need this e.g. if you don't want to overbloat the menu, while have pages with subpages that have also subpages and so on.

The menu system is already capable of this feature, but I am speaking about menu.module, that is missing a way to configure this.

I added checkboxes, so that you have e.g. (the following is the default):

[x] Visible in tree
[ ] Expanded
[x] Visible in breadcrumb

You now have these checkboxes when editing an item in admin/menu, but also in the new menu (on-the-fly) group when adding/editing a node.

I have a technical description of the changes that my patch will commit, but also many screenshots, that show what is possible and how the changes look.

I start with the screenshots:

(1) http://d-f-g.net/drupal/menu-module-patch/node-view.png
Here you can see a very long breadcrumb, that was configured using the menu module. The menu tree on the left is expanded until the last menu item with the MENU_VISIBLE_IN_TREE flag.

(2) http://d-f-g.net/drupal/menu-module-patch/phpmyadmin-menu-table.png
This is the interesting part of the menu table, viewed with phpmyadmin.

(3) http://d-f-g.net/drupal/menu-module-patch/node-add.png
(4) http://d-f-g.net/drupal/menu-module-patch/node-edit.png
(5) http://d-f-g.net/drupal/menu-module-patch/admin-menu.png
(6) http://d-f-g.net/drupal/menu-module-patch/admin-menu-edit.png

------------------------------------------------------------------
Technical description, all changes in menu.module
------------------------------------------------------------------

- added 2 checkboxes in menu_edit_item_form():
- checkbox "Expanded" was already there
- checkboxes: added "Visible in tree" and "Visible in breadcrumb"
- used the same coding style as for "Expanded"

- added handling of the 2 new checkboxes in menu_edit_item_save():
- used the same handling style as for "Expanded"

- menu_overview_tree_rows():
- the t('edit') button is no longer bound to MENU_VISIBLE_IN_TREE
- instead to (MENU_VISIBLE_IN_TREE | MENU_VISIBLE_IN_BREADCRUMB)

- added the 3 checkboxes in menu_node_form():
- this is the menu otf section (some call it so). the checkboxes should not be missed there.

- menu_parent_options() and menu_overview_tree_rows():
- t('disabled') no longer bound to !& MENU_VISIBLE_IN_TREE (see the code...)
- instead to !& (MENU_VISIBLE_IN_TREE | MENU_VISIBLE_IN_BREADCRUMB)

------------------------------------------------------------------

Best regards, DFG

CommentFileSizeAuthor
#24 menu_in_bcrumb_not_in_tree.gif3.82 KBvenkat-rk
#14 menu.module_3.patch5.15 KBeaton
#6 menu.module_2.patch5.66 KBeaton
menu.module_0.patch3.9 KBdfg

Comments

jakeg’s picture

jakeg commented

+1

Looks good, works well.

Only comment is if we have "Home > 1 > 2" and you choose *not* to display 2 in the breadcrumb, when on 3 (child of 2) should the crumb be "Home > 1" or just "Home" ? At the moment the patch makes it just 'Home' but I would opt for "Home > 1". That's how it works on the menu block side of things as well..

jakeg’s picture

jakeg commented

I take back my comment. It works as intended, my mistake.

dfg’s picture

dfg commented

I am still thinking, that it's worth to be commited.

Impatient, but tough, DFG

dfg’s picture

dfg commented

patch still applies to cvs

eaton’s picture

eaton commented
Status: Needs review » Needs work

+1 awesome tweak. This paves the way for pathauto-like breadcrumb generation modules that automate the creation of breadcrumb paths without cluttering the normal navigation menu.

Needs to be updated to appy against the new formsapi changes, though. that should only affect the chunks at lines 13-17 and 77-79, though.

eaton’s picture

eaton commented
StatusFileSize
new menu.module_2.patch5.66 KB

Patched for compatability with HEAD and the new forms API.

It's a quick job and seems to work, though there's some goofiness with the nodeapi editing of the menu -- you can enable options like Expanded, Visible In Breadcrumb, but DISABLING any of them requires visiting the admin > menu screen and changing the options there. Probably something silly with my formapi conversion.

The basic functionality of the patch is there, though, and it'd be great if folks could take a look at it.

dfg’s picture

dfg commented

Your failure could be: $edit['type'] is now $edit['menu']['type']

eaton’s picture

eaton commented

No, after a lot of investigation that's not the problem.

As best as I can tell, the inline version of the form ALWAYS returns #default_value for the checkboxes, even if they're unselected. The normal 'edit item' version of the form -- even though the form elements it outputs are the same -- properly returns nothing for unchecked boxes, and 1 for checked ones.

I believe it's a formsapi problem -- I'm looking into it. In the meantime, this patch does work and can be tested/tinkered with.

asimmonds’s picture

asimmonds commented

Eaton: check http://drupal.org/node/35816 (The IRC quote was from you)

eaton’s picture

eaton commented
Status: Needs work » Needs review

Thanks! After applying the forms fix in that patch, this patch works perfectly. Thus, the only 'issue' with this patch is actually a formsapi bug (http://drupal.org/node/35816)

I'll go back to shamelessly pimping this patch. It's good stuff.

Souvent22’s picture

Souvent22 commented
Status: Needs review » Reviewed & tested by the community

Worked great for me. Don't know it woudln't be rolled in yet? :)

m3avrck’s picture

m3avrck commented
Status: Reviewed & tested by the community » Needs work

I really like this patch but it no longer applies, please update and hopefully we can get this in before another update goes in!

m3avrck’s picture

m3avrck commented

Also the patch in comment #10 eaton speaks of has been committed so this patch should be working flawlessly once updated for HEAD.

eaton’s picture

eaton commented
Status: Needs work » Needs review
StatusFileSize
new menu.module_3.patch5.15 KB

Patch now applies against cvs. Also, found a spot where I'd been writing out a debug message and removed it. :-)

eaton’s picture

eaton commented
Status: Needs review » Reviewed & tested by the community

*bump*

It applies, and no changes have been made save updating it for HEAD.

m3avrck’s picture

m3avrck commented

This patch is awesome! Certainly very useful and complements the menu functionality that was added in 4.7, let's get this baby in!

Richard Archer’s picture

Richard Archer commented
Status: Reviewed & tested by the community » Needs work

This patch no longer applies.

I do think there should be an admin interface for controlling these menu flags, but I don't think these options are used frequently enough to justify being included on the menu-otf panel. Instead, I think they should be accessible only through admin/menu.

The menu-otf panel now includes a link to the appropriate admin/menu/item/edit/* page, so there would only be one extra click to get to these settings.

Also, there is currently no user interface for the MENU_VISIBLE_IF_HAS_CHILDREN flag. There is currently an ugly work-around in menu.module for this flag. If there was a proper interface option menu_overview_tree_rows could be cleaned up. I would like to see such functionality included in this patch.

Richard Archer’s picture

Richard Archer commented

Posted by ahwayakchih to http://drupal.org/node/41315

Expanded menu item permissions bug?

On site where anonymous users can't create any content, i have "create content" menu item set to be expanded. Anonymous users can see that item, even though they can't create anything.

I've checked this problem out, and it requires the admin to have explicit control over the MENU_VISIBLE_IN_TREE flag.

I think the admin/menu/edit/* screen should allow the menu to control all these flags... anyone up for updating this patch?

rimshot’s picture

rimshot commented

BIG +1 for this one. I don't see a way to do this, even with the new 4.7 Beta code without hacking the module.

For example:
I have a "Disussion" section of the site with a few categories under it. After wrking with drupal for the past week what it looks like is unless I can appy this patch (or hack the code) what I have to end up with is a menu block with a title of Discussion. I then must create a vocabulary of Discussion and assign all my terms as children of this Discussion term. This is the only way I can get the breadcrumbs to work properly. So when you are in "Corporate" you see Home->Discussion->Corporate. Kind or redunant if you ask me.

Discussion
>Discussion
> Corporate
> K-12
> Not - For - Profit

Now, I though for a second I thought I could just diable the "Discussion" menu item. This results in the nice look of

Discussion
> Corporate
> K-12
> Not - For - Profit

Perfect! But since the discussion category item is disable then going to the "Corporate" section the breadcrumb looks like:

Home

I applied this patch to the latest 4.6 code it doesn't work. So it looks like I need to:
1. I be redundant in my categories.
2. Scrap the breadcrumb
3. Hsck the code to show the breadcrumb properly when menu items disabled.
4. Plead to put something into the drupal code to allow me to do this.
5. Other options to do what I want?

dfg’s picture

dfg commented

Too sad, that this feature still isn't implemented in Drupal. I resign.

Richard Archer’s picture

Richard Archer commented

This can even be implemented in a module now, with the new forms API.
No need for this feature to jump through the "core-worthy" hoops.

dfg’s picture

dfg commented

That's not correct. E.g. if you look at the last patch by Eaton:

@@ -539,7 +560,7 @@
       }
 
       // Call out disabled items.
-      if ($menu['items'][$mid]['type'] & MENU_VISIBLE_IN_TREE) {
+      if ($menu['items'][$mid]['type'] & (MENU_VISIBLE_IN_TREE | MENU_VISIBLE_IN_BREADCRUMB)) {
         $class = 'menu-enabled';
       }

This is a change in the administration interface of the menu module. So hardcoding is needed.

-

I don't understand why this feature still isn't implementet in Drupal. Every module developer makes menu items, that are visible in the breadcrumb, but not in the tree. Why not allowing a site administrator to define such elements?

E.g. look at the breadcrumb for this page:
Home » projects » Drupal project » Drupal » issues » menu.module feature: visible in breadcrumb, but not visible in tree

Imagine this would also be an fully expanded tree on the right...

marcoBauli’s picture

marcoBauli commented

The Category module is already capable of doing this, it might be worth having a look there.

Still sems there is a problem with menu cache that makes sites with 400+ menu items get seriously hitted in performance (see related issue here on #2)

venkat-rk’s picture

venkat-rk commented
StatusFileSize
new menu_in_bcrumb_not_in_tree.gif3.82 KB

Yes, I was going to say the same thing as kiteatlas.

In the attached screenshot, the container 'Campaigning and Advocacy' is actually under 'Programmes' as you can see in the breadcrumb trail, but is hidden in the menu tree. If I tag a node with a category under this container, the container and the category will also show in the breadcrumb trail on the node view, but the menu tree will continue not to show either.

This is accomplished through a simple radio button setting in category_menu on the container node form. It works great except for the potential hit in performance that kiteatlas referred to when there are hundreds of nodes and more.

killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Needs work » Closed (won't fix)

excellent, things that already exist in contrib don't need to be reimplemented in core. Especially if they are somwhat exotic.