I've been experimenting with tab-based site menus, sort of like the contributed Navigation module from 4.4. A simple modification to Block.module added extra regions for blocks (so I can put "Site Menu" in the top header or just above the main content), and CSS does the rest. It's a simple patch, and has potential uses beyond simply adding a menu to the top of my content (such as developing blocks that are appropriate to a footer, for example).
However, I'm now stumbling on another loss of functionality (as compared to Naviagation.module): I can't hide menu items. Navigation allowed me to set permissions on certain menu items, which was nice (so that my "Admin" tab didn't show unless you were in the Editor group). I can't do that with the stock Menu module.
As I've been thinking about this, I'm wondering if adding a role field to the menu table is the right answer. Perhaps, as a menu is being built, the system should parse down through the menu tree. If a tree has no nodes that are viewable to a user, that portion of the tree is pruned right off the menu. This would have the effect of hiding menu items that aren't pertinent, while also simplifying administration by making the hiding automatic (you're only need to worry about hiding the node, the menu pointer gets hidden automagically).
Is anyone working on something like this? Is this even the right approach? I'd really like to see, as a user, all the needed menuing functionality in a single module, and not have to fight to get Navigation.module ported to 4.5. It'd just be nice to have it all in one place, without several competing menu systems (Menu, Navigation, Taxonomy, or whatever else) trying to accomplish the same goal...
(that said, I think the Menu editing interface needs some work, maybe showing all the defined menus as sub-tabs in the same way that the Theme configuration page works. and there remain some issues with turning a hierarchial list of lists (nested UL tags) into an expanding block of tabs, too.).
Comments
I concur wholeheartedly
I'm doing my own inspections of different ways in which to generate and handle menus in addition to more finegrained roles for accessing menus. In addition, I would like some way to provide for adding permissions(roles) for the display of blocks.
So having some functionality to do what you suggest would be of great help.
Also, it would be helpful to know which modules are providing which blocks in the block admin page, as some modules of course use other descriptive terms (i.e. a 'topic' vocabulary would create a block called Topic by the taxonomy_dhtml module).
As to your proposed method of implementation, I believe a possible way to do it is to provide a new table called 'menu_access', which would be a relationship table (or possibly hierarchial relationship like phpgacl) consisting of a menu item id and a role id.
The reason for this is a menu item could be permitted to be accessed by several roles. This in contrast to adding a role column to the menu table which would only allow access to a menu item by one role.
That being said, I'm a 'wet behind the ears' certified newbie with drupal, so I'm not sure I'm to this task yet (although perhaps in a couple months I could come back to it). I'd be very interested in keeping abreast of any developments around this.
Further investigation...
[I just posted this on an issue commentary (http://drupal.org/node/13044), anonymously it seems. Copying it here to further discussion...]
I've done a little more research into this and have come to a couple of conclusions.
First, we can't simply "check" to see if a given menu item points to a "screen" to which the user has access. We could if menus could only point to specific nodes, but they often point to pages that are themselves comprised of other content, which may or may not be viewable by the user. We'd have to essentially create each page, check whether anything was actually visible, and then decide whether to include the menu item.
I solved this for myself (well, I've *hacked* a solution, but it's not nearly complete) by simply adding a check in _menu_item_is_accessible(), in menu.inc. I do a basic check of the user's roles against a comma-separated list of roles, stored in a "roles" field for the menu item. It seems to work, but I've had some issues with it that I haven't had time to investigate.
I'm not sure that we can hook into this routine, and I couldn't find any other way to accomplish this, so any fix to this will require a modification to menu.inc in the core, I think.
Is anyone else even looking into this?
tinkering with just that, sort of
I've been tinkering with that in a php block. How to get somthing along the lines of;
<? if (user_access('administer nodes')): ?>
Show this line
<? end if ?>
but my grammar is wrong. I don't know how to say "if the user's privileges include administer nodes" right.
tinkering with just that
Something along the line works for me:
Further Reading:
http://drupal.org/node/17170
and imho even better:
http://dev.bryght.com/t/wiki/BlockHacks
Have fun!
wernerbraun
2 Years Later
I found your post two years after you wrote it and Drupal still does not allow you to associate menu items or pages with roles out of the box. I am trying to hack out these modifications right now. It would be nice just to check a box for the roles that are allowed to access pages, and menu items (links).
I am only this far with the code inside a block...
This works fine... but how about the link to the page that contains the block!? I had to write one more block to show the link depending on the role (again). But the problem is the link in the block appears seperate from the rest of the users links, such as "create content". It is a real pain. In the end if I have time I will put all of this into an automated module. Anyone want to help out with that?
Dan Gibas, HYGEN