Under Drupal 6(.4), even if a role has *no* User-Management related permissions, the "User Management" menu does not hide - it still shows, with no items under it. Selecting the menu takes the user to a page that simply states: "You do not have any administrative items."

It seems to me, that the menu simply should not be present.

To reproduce, using a brand-new D6.4 installation:

1) login as the site's superuser, and create a new role - name it anything you wish
2) In the 'permissions' page for the new role, make sure the role has *no* user management permissions - under "user module", deselect everything.
3) create a new user for the site, and give this user the newly created role
4) log out as the superuser, and login as the new user, with the new role
5) notice that under 'Administer', you still have "User Management" - clicking it will take you to that silly page that states that you have no administrative items...

This is a *very* annoying bug. I do *not* wish the "User Management" menu to be displayed for certain roles - ie., 'site editors', whose function is simply to add and edit content to the site.

Files: 
CommentFileSizeAuthor
#120 296693-hide-empty-admin-120.patch3.57 KBpwolanin
FAILED: [[SimpleTest]]: [MySQL] 18,916 pass(es), 24 fail(s), and 2 exception(es).
[ View ]
#103 menu_group_item_nice_little_query.patch1.65 KBchx
Unable to apply patch menu_group_item_nice_little_query.patch
[ View ]
#92 empty-categories-page-tree-problem.png129.62 KBsun
#92 drupal.empty-categories.92.patch17.35 KBsun
Unable to apply patch drupal.empty-categories.92.patch
[ View ]
#88 drupal.empty-categories.88.patch17.11 KBsun
Failed: 14541 passes, 2 fails, 0 exceptions
[ View ]
#86 drupal.empty-categories.86.patch13.5 KBsun
Passed: 14479 passes, 0 fails, 0 exceptions
[ View ]
#83 drupal.empty-categories.83.patch13.47 KBsun
Passed: 14492 passes, 0 fails, 0 exceptions
[ View ]
#82 drupal.empty-categories.82.patch10.85 KBsun
Passed: 14477 passes, 0 fails, 0 exceptions
[ View ]
#73 revert.patch7.33 KBcatch
Failed: Failed to apply patch.
[ View ]
#70 revert.patch4.96 KBcatch
Failed: 12298 passes, 0 fails, 1024 exceptions
[ View ]
#67 queries.png373.83 KBcatch
#66 head.png438.94 KBcatch
#66 patch.png407.28 KBcatch
#64 system_block_access_revert.patch3.6 KBcatch
Failed: 12045 passes, 0 fails, 512 exceptions
[ View ]
#62 system_block_access_revert.patch2.82 KBcatch
Failed: 12118 passes, 0 fails, 238 exceptions
[ View ]
#55 system_block_access_revert.patch3.51 KBcatch
Failed: Failed to apply patch.
[ View ]
#42 296693-menu-hide.patch7.14 KBboombatower
Failed: Failed to apply patch.
[ View ]
#39 296693-menu-hide.patch6.39 KBboombatower
Failed: Failed to apply patch.
[ View ]
#30 menu_item_grouping_01.patch5.16 KBXano
Failed: Failed to apply patch.
[ View ]
#29 menu_item_grouping_00.patch3.87 KBXano
Failed: Failed to apply patch.
[ View ]
#23 drupal.hide-empty-admin-menus.patch6.01 KBsun
Failed: 8502 passes, 1 fail, 0 exceptions
[ View ]
#20 drupal.hide-empty-admin-categories.patch6.03 KBsun
Failed: Failed to install HEAD.
[ View ]
#19 296693-empty-admin-categories.patch6.66 KBdeviantintegral
Failed: Failed to install HEAD.
[ View ]
#15 296693-empty-admin-categories.patch6.69 KBDamien Tournoud
Failed: Failed to apply patch.
[ View ]
#9 296693-empty-admin-categories.patch7.19 KBboombatower
Failed: Failed to apply patch.
[ View ]
#3 empty-admin-categories-no-patch.png70.59 KBwebchick
#2 296693-empty-admin-categories.patch5.25 KBDamien Tournoud
Unable to apply patch 296693-empty-admin-categories.patch
[ View ]

Comments

icouto’s picture

The same problem is also reproducible for the "Site Building" menu - ie., even if the role has no permissions for any of the menu items in the menu, the menu itself is still displayed. I suspect the same thing might happen also for the "Site Configuration" menu.

This *is* a serious problem to me, as one of the main tasks I have when setting up a Drupal site is to 'dumb down' the admin interface for newbie users. Not being able to easily hide these menus means that the interface ends up being overly complicated for low-level admin users - like site editors, who have no business managing users, or playing around with the site configuration.

Currently, the only way to overcome this bug is to split the Administer menu into several menus (one for each role needed), and use the BLOCK permissions for each menu block individually. In my case, for instance, I ended up having to split the menu into "RegisteredUser", "SiteEditor" and "SiteAdmin" menus. This is not a proper solution, it is a time-consuming, inelegant hack. I end up with 3 or 4 separate menus, containing totally related functions that had to be split in order for me to be able to control role access to them - when they really should be under just a single menu.

I do not need several different menus. I need just ONE menu, that properly restricts its items' visibility according to the user's permissions.

I hope this will be fixed for D7.

Damien Tournoud’s picture

Title:Overly Persistent "User Management" Menu» Empty admin categories should be hidden
Version:6.x-dev» 7.x-dev
Component:menu system» system.module
Status:Active» Needs review
StatusFileSize
new5.25 KB
Unable to apply patch 296693-empty-admin-categories.patch
[ View ]

That issue has been identified several months ago. Here is a first patch for it.

webchick’s picture

Status:Needs review» Needs work
StatusFileSize
new70.59 KB

Confirmed this problem. Would be nice to back-port fix to 6.x as well.

Steps to reproduce:
- Create a role called "editor" and an "editor" user assigned to that role.
- Give the role both "administer nodes" and "access administration pages" permissions.
- Log in as "editor" and go to "Administration"
You'll see entries for Site building, etc. in the navigation menu even though those result in "Access denied" when you try to go there. See attached screenshot.

Let's get tests with this patch though to make sure this bug doesn't recur.

boombatower’s picture

The code in #2 uses system_admin_menu_block() which does allot of extra stuff then is necessary to determine if there are children. Plus _system_settings_access doesn't seem like the right name for the access callback for two reasons.
1) It could be used by contrib, no need for private declaration (_).
2) It relates to other items besides settings.

In my attempt at this in #263616: Move SimpleTest out of "Site building" I used the following code:

<?php
function system_admin_menu_block_page_access($path, $string) {
  if (
user_access($string)) {
   
$count = db_result(db_query("SELECT COUNT(mlid)
                                 FROM {menu_links}
                                 WHERE plid = (
                                   SELECT mlid
                                   FROM {menu_links}
                                   WHERE link_path
                                   LIKE '%s'
                                 )"
, $path));
    return (
$count > 0);
  }
  return
FALSE;
}
?>

Which alleviates the call to the other function.

Should think about the name of the function. The reasoning behind my choice is that the items that only display a list of children use system_admin_menu_block_page so it would only seem nature that system_admin_menu_block_page_access would be used for them.

Damien Tournoud’s picture

@boomatower: Ok for the name change, it makes sense and I don't really care :)

The objective of using system_admin_menu_block() was to limit code duplication and database queries as most as possible. Your solution was not enough, because we also need to check for access of each menu item, not just count them.

I turned that issue around over and over, and came to the conclusion there is no better way.

Damien Tournoud’s picture

I forgot to add: "... but of course, I only want to be proven wrong!"

boombatower’s picture

Assigned:Unassigned» boombatower

Working on writing the test, and a few cleanup items along with it.

icouto’s picture

Thank you, everyone, for your superhumanly quick response to this!

I was wondering, if we are going to see a back-port of the fix in D6, as mentioned by webchick.

boombatower’s picture

Status:Needs work» Needs review
StatusFileSize
new7.19 KB
Failed: Failed to apply patch.
[ View ]

Adds test and changes access callback name per #4 and #5.

@icouto: Depends on what this is considered. If this is considered a bug/or necessary feature then it most likely will be. It would be useful as SimpleTest 6.x-2.x would use this and I'm sure there are others, not to mention default use-cases as per #3.

The test needs assertLink and assertNoLink: #297894: Add assertLink and assertNoLink to SimpleTest
which requires: #297869: Add xpath method to Simpletest and refactor existing tests

Will need those to get in first, but we can still review this patch. (although you will need to apply those.)

After patches applies test passes.

boombatower’s picture

After applying the above patches and then applying this one tests pass.

boombatower’s picture

Ran entire test suite with all passes.

boombatower’s picture

Still applies after dbtng.

lilou’s picture

Status:Needs review» Needs work

There is a bug with the last patch :

1. Give anonymous user these permissions :

access administration pages and administer blocks or access site reports.

2. Clear cache

3. Logout

4. Go to admin page >> Access denied, and no menu link

5. Refresh >> Notice error :

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'system_admin_menu_block_page_access' was given in D:\Serveur\www\drupal\7.x\includes\menu.inc on line 502.

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'system_admin_menu_block_page_access' was given in D:\Serveur\www\drupal\7.x\includes\menu.inc on line 502.

boombatower’s picture

Hmmmm...two interesting things:

  • The notice only comes up once...at least for me.
  • Adding debug code it becomes clear that user_access() returns TRUE, but the $content is empty.

It would seem the issue is in the existing code not the new code, but yet it works without the new code....

When I run the site as anonymous I get:

error  PHP Fatal error: require_once(): Failed opening required './includes/database/mysql/query.inc' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in .../drupal-7/includes/bootstrap.inc on line 1399, referer: http://drupal-7.dev.loc/
Damien Tournoud’s picture

Status:Needs work» Needs review
StatusFileSize
new6.69 KB
Failed: Failed to apply patch.
[ View ]

There are three bugs here:

* Drupal don't use absolute paths for loading include files, and the current path can change, especially during the execution of shutdown functions. This is solved in #259623: Broken autoloader: convert includes/requires to use absolute paths. Please try that patch.
* Access control on /admin don't work properly, probably because system_admin_menu_block_page_access() recursively calls itself. For now, I disabled that access control on /admin.
* Hide descriptions/Show descriptions toggles didn't work for anonymous users (it was relying on a $user parameter). I changed this to use session for anonymous users.

keith.smith’s picture

Not to be overly picky on code comments, but:

+   * Ensure that menu items that without "visible" children are hidden.

An extra "that" or something?

+ *   The path of the menu item to ensure has children.

Something's not quite right there.

I see this is another good use of compact mode, which I wholeheartedly approve. We don't use setting enough.

These are minor, so I'll leave at CNR and you can take care of them during the next substantive re-roll.

Anonymous’s picture

Status:Needs review» Needs work

The last submitted patch failed testing.

sun’s picture

Subscribing and marking for later review. Administration menu module users are suffering from this.

deviantintegral’s picture

StatusFileSize
new6.66 KB
Failed: Failed to install HEAD.
[ View ]

Here is an updated patch which applies against HEAD and fixes the comments in #16. It's working as expected for me.

sun’s picture

Assigned:boombatower» Unassigned
Status:Needs work» Needs review
StatusFileSize
new6.03 KB
Failed: Failed to install HEAD.
[ View ]

- Renamed menu item access callback to system_admin_menu_block_access(), since the additional "page" suggested that it would be used for determining access to a page, but we are just checking admin block/category access here.

- Optimized system_admin_menu_block_access() to check for the user permissions first.

- Removed all changes related to compact mode, as those are unrelated to this issue. (please create a new issue, since the changes make sense)

- Renamed test case.

Also ran tests, tested manually with a test user (and having admin menu module installed) and everything seems to working properly.

sun’s picture

Title:Empty admin categories should be hidden» Empty admin categories are not hidden

This is a annoying bug - better title.

Damien Tournoud’s picture

Status:Needs review» Needs work

Changes in #20 make sense, but this is an old patch, and its test doesn't comply at all with our (relatively new) Test Writers Guidelines.

<?php
  
}
 }
 
+class
AdminMenuBlockTestCase extends DrupalWebTestCase {
?>

^^ Missing PHPDoc above the class.

<?php
/**
+   * Implementation of getInfo().
+   */
+  function getInfo() {
?>

^^ We don't PHPDoc overriden functions anymore.

<?php
+    return array(
+     
'name' => t('Admin menu categories'),
+     
'description' => t('Confirm that administrative categories, which do not contain any visible child items, are not displayed.'),
+     
'group' => t('System'),
+    );
+  }
?>
<?php
+
/**
+   * Ensure that administrative menu items without visible children are hidden.
+   */
+  public function testEmptyHide() {
?>

^^ The PHPDoc description should probably better start with test*...

testEmptyHide() is a badly choosen function name.

As an end note: it's quite fun to shoot down one of your own old patches :)

sun’s picture

Status:Needs work» Needs review
StatusFileSize
new6.01 KB
Failed: 8502 passes, 1 fail, 0 exceptions
[ View ]

After a BIG support session with Damien in IRC, this should (hopefully) be properly. :) (Thanks again!)

sun’s picture

FYI: Damien moved the compact mode fixes to #352734: "Compact mode" switch doesn't work for anonymous users...

Status:Needs review» Needs work

The last submitted patch failed testing.

Damien Tournoud’s picture

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch failed testing.

Xano’s picture

While working at #362834: Move statistics out of the administration pages and add permissions I noticed that MENU_ITEM_GROUPING has not been added to the new menu system in D7. As a result, we now have several functions that do pretty much the same. node_add_page() and system_admin_menu_block_page(). I think node_add_page() is a good candidate for a new MENU_ITEM_GROUPING. It needs some changes, but then it will do fine (See the patch in #362834).

However, that patch is not complete yet, since it displays a MENU_ITEM_GROUPING parent item even if there are no child items or if the user has no permission to access any of its child items. This is the point where chx told me to check out this issue.

  1. I believe the names system_admin_menu_block() and system_admin_menu_block_page() are improper. They don't describe what the functions do in a short and simple fashion, nor do they make the functionality appear available to non-admin pages, which should be.
  2. I suggest I suggest putting MENU_ITEM_GROUPING back in and let menu.inc automatically set menu_item_grouping() (as seen below) as the page callback. Menu.inc should also set special access callback that returns FALSE if there are no children or if the user has no permission to access them.
  3. The access callback as described in #4 only checks if there are no child items, but it should also check if the user has permission to access those children. This could perhaps be done the easiest by creating a user_access_multiple() (issue), so multiple permissions can be checked at once.
  4. <?php
    /**
     * List a menu item's children.
     *
     * @return string
     */
    function menu_item_grouping() {
     
    $item = menu_get_item();
     
    $items = system_admin_menu_block($item);
     
    // Bypass the listing if only one child is available.
     
    if (count($items) == 1) {
       
    $item = array_shift($items);
       
    drupal_goto($item['href']);
      }
      return
    theme('menu_item_grouping', $items);
    }

    /**
     * Theme a list of menu items.
     *
     * @param $items
     *   The items as returned from system_admin_menu_block().
     *
     * @return string
     */
    function theme_menu_item_grouping($items) {
     
    $output = '';

      if (
    $items) {
       
    $output = '<dl class="menu-item-grouping">';
        foreach (
    $items as $item) {
         
    $output .= '<dt>' . l($item['title'], $item['href'], $item['localized_options']) . '</dt>';
         
    $output .= '<dd>' . filter_xss_admin($item['description']) . '</dd>';
        }
       
    $output .= '</dl>';
      }
      return
    $output;
    }
    ?>
Xano’s picture

Title:Empty admin categories are not hidden» MENU_ITEM_GROUPING
Component:system.module» menu system
Assigned:Unassigned» Xano
Status:Needs work» Needs review
StatusFileSize
new3.87 KB
Failed: Failed to apply patch.
[ View ]

The attached patch reintroduces MENU_ITEM_GROUPING as a menu item type. Such menu items automatically get a page callback that lists all the item's children, or redirects the user if there is only one child.

  1. To do: Hide the menu item if there are no children. I must say I'm not sure if this is the way to go, since it could cause some links not to be visible anywhere, although they have been enabled at admin/build/menu.
  2. To do: Check if the user has permission to access any children, otherwise hide the item.
  3. Custom access callbacks should be used in parallel with the access callbacks from points 1 and 2.

See this patch in action at /node/add. See anything different? No? Exactly!

By the way: node_add_page() and similar obsolete functions have not yet been removed to keep this initial patch simple.

Xano’s picture

StatusFileSize
new5.16 KB
Failed: Failed to apply patch.
[ View ]

The attached patch also performs access control and should hide the item if a user has no access to child items. All issues pointed out in #29 are dealt with. I haven't yet tested the patch thoroughly, but it seems to work. Will do more testing as soon as I'm done with my other work here.

To do: display a message if there are no children to list.

The code responsible for the access check:

<?php
/**
 * Determine if a user should have access to a menu item.
 *
 * Users should only have access if all of the following cases are true:
 * - The user has access to at least one of this item's children.
 * - The custom access callback (if any) returns TRUE.
 *
 * @param $path string
 *   The path of the menu item to check access to.
 * @param $callback string
 *   A custom access callback to check as well.
 * @param $arguments array
 *   Arguments to pass on to the access callback.
 *
 * @return boolean
 */
function menu_item_grouping_access($path, $callback, $arguments) {
  if (
is_string($callback)) {
   
$custom_access = call_user_func_array($callback, $arguments);
  }

 
$item = array('path' => $path);
 
$items = system_admin_menu_block($item);
  foreach (
$items as $child) {
   
_menu_check_access($child, array());
    if (
$child['access']) {
      if (
$custom_access) {
        return
TRUE;
      }
      else {
        return
FALSE;
      }
    }
  }

  return
FALSE;
}
?>
chx’s picture

Benchmarks?

Xano’s picture

Title:MENU_ITEM_GROUPING» Empty admin categories are not hidden
Assigned:Xano» Unassigned
Status:Needs review» Active

I have split the patch in two. After #363951: Reintroduction of MENU_ITEM_GROUPING gets submitted I'll post a new patch taking care of access control here. This will make benchmarking easier.

mairav’s picture

Suscribe using Drupal 6.10.
Will drupal fix this to 6 version or will it be a solution for Drupal 7?

pitxels’s picture

Subscribing and looking forward for d6 patch

stella’s picture

Since #363951: Reintroduction of MENU_ITEM_GROUPING won't be committed (marked as won't fix), does this mean we're back to the patch in #20 above?

boombatower’s picture

Status:Active» Needs review
StatusFileSize
new6.39 KB
Failed: Failed to apply patch.
[ View ]

Rework of #23 (no longer applied and outdated).

  • Make use of drupal_static().
  • Implement callback for admin/development.
  • Updated test for admin/development.
stella’s picture

Patch looks good and works quite well. However there's still one edge case that isn't covered - if the user has the 'access administration pages' permission, but doesn't have access to _any_ of the sub menus, and if the help module is not enabled, then the 'Administer' menu item still appears in the navigation block and the message "You do not have any administrative items." appears when clicked.

It's an edge case (why would anyone give that permission to a user without giving them access to at least one sub-menu?!) and the message displayed is useful, but shouldn't that menu item not appear at all?

stella’s picture

Status:Needs review» Needs work

Actually this also change also needs to be implemented for the new top level admin menu admin/international in locale.module

boombatower’s picture

Status:Needs work» Needs review
StatusFileSize
new7.14 KB
Failed: Failed to apply patch.
[ View ]

I am not sure that is an issue since technically there is a menu item under "Administration". When help module is disabled the Administration menu item still displays. I attempted to add the check the the root "admin" item, but it causes an issue, possibly due to excessive looping.

Not sure we want to deal with that issue or perhaps save for follup patch. Either way this patch contains admin/international alteration.

stella’s picture

I think it's good to go as is, just to summarise what this patch does:

  • For each of the top level admin menu items (admin/build, admin/user, etc), it changes the access callback to be a new function system_admin_menu_block_page and gives it the params: path (e.g. 'admin/build') and the access permission.
  • The function first checks that the user has the appropriate access, and if not returns FALSE.
  • then checks if the user has access to any of the sub-menus, and if not it returns FALSE, which prevents the user from seeing the menu item
sun’s picture

Status:Needs review» Reviewed & tested by the community

Yes. 'admin' & 'access administration pages' we need to tackle elsewhere.

webchick’s picture

Status:Reviewed & tested by the community» Needs work
Issue tags:+Needs Documentation

Kick ass! I'm so happy to finally see this fixed! :D

Committed to HEAD! Marking "needs work" until it's documented in the 6.x => 7.x upgrade page.

Ultimately this is up to Gábor, of course, but given what was required to fix this in 7.x, I'm pretty sure we can't backport this to 6.x. It's an API change that requires module developers to make changes to their menu items' access callbacks. In addition to this being a mean thing to ask people 1.5 years after D6's initial release, it will result in hackish "if function_exists" workarounds in order for this to work for people not using the latest versions of Drupal 6. Granted, it'd only affect the handful of modules that define their own top-level admin blocks like OG, Panels, and Project. But still. Stable means stable.

boombatower’s picture

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch failed testing.

boombatower’s picture

Status:Needs work» Fixed

Guess I'll just mark fixed unless anyone says otherwise.

boombatower’s picture

Status:Fixed» Closed (fixed)

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

pitxels’s picture

should any fix be expected for drupal 6? In a different issue maybe?

kenorb’s picture

+1 for 6.x backport

kenorb’s picture

catch’s picture

Priority:Normal» Critical
Status:Closed (fixed)» Active

I'm asking for a rollback of this until the critical performance issues it introduced on every page load are resolved. fwiw Damien suggested this in irc as the original patch author.

See #520364: system_admin_menu_block_access() makes no sense and #519046: Clean up toolbar menu code for plenty of background on why this was such a bad idea.

catch’s picture

StatusFileSize
new3.51 KB
Failed: Failed to apply patch.
[ View ]
catch’s picture

Status:Active» Needs review

First I forget the patch, then I forget the status change. Sorry for the bumps :(

catch’s picture

Possible alternative to the current implementation -have a convention of 'access structure administration page' 'access configuration and modules administration page' for these top level links - then you can give the specific top level links to users as necessary and while you might need to update them manually it'll be a normal access check instead of access checking and rendering /admin on every page load. Could probably replace 'access administration pages' with this since we don't have a single centralised admin page any more. Most sites are going to be using either the core toolbar or admin_menu.module - both of which suffer from this (apart from admin_menu implementing client side caching), and both of which reduce hits on /admin anyway.

sun’s picture

As far as I get it, the new proposed IA for admin/config (which I do not support) would add categorization items below admin/config, which will face the very same problem: The parent item/link (category) must only be shown if the user has access to any child item. system_admin_menu_block_access() replaced the good ol' MENU_DYNAMIC_ITEM, which is what we are talking about here.

catch’s picture

@sun, yes that's right. Except the new IA in combination with the core toolbar means by default you'd never be displaying expanded links to the categories, just the top level link, so the original issue here is slightly mollified if we add a blanket on/off permission for those top level links.

The original issue (and the performance implications in HEAD) are then primarily going to affect core menu module and admin_menu. i know admin_menu has client-side caching, but menu module isn't and won't.

Status:Needs review» Needs work

The last submitted patch failed testing.

emmajane’s picture

Issue tags:-Needs Documentation

Documentation update:

Documentation was added in #46, but the issue is still marked as, "Needs documentation." I've given the documentation at http://drupal.org/update/modules/6/7#system_admin_menu_block_access a quick edit to improve clarity. For now I'm going to remove the "needs documentation" tag. If/when the issue does get rolled back, please re-mark as "needs documentation." Thanks!

catch’s picture

Status:Needs work» Needs review
Issue tags:+Performance
StatusFileSize
new2.82 KB
Failed: 12118 passes, 0 fails, 238 exceptions
[ View ]

Re-rolled.

Status:Needs review» Needs work

The last submitted patch failed testing.

catch’s picture

Title:Empty admin categories are not hidden» Revert system_admin_menu_block_access()
Status:Needs work» Needs review
StatusFileSize
new3.6 KB
Failed: 12045 passes, 0 fails, 512 exceptions
[ View ]

locale.module changed too.

Dries’s picture

catch, you mention a performance problem but you didn't provide any details. Care to shed some light on this? How bad is it?

catch’s picture

StatusFileSize
new407.28 KB
new438.94 KB

@Dries, I linked to two issues from #54, both of which have a fair bit of background.

Some of the performance issues were down to bad toolbar usage of menu_tree_all_data(), but system_admin_menu_block_access() is responsible for a lot more - the issue being that any link displayed which has this as it's access callback, requires the menu system to render the entire admin tree below it just to check if it's visible or not. The toolbar, an expanded management menu, or admin_menu all cause this to happen on every authenticated user page request.

#520364: system_admin_menu_block_access() makes no sense

#519046: Clean up toolbar menu code

Attached updated webgrind screenshots too.

catch’s picture

StatusFileSize
new373.83 KB

OK so currently the admin/config link just uses 'access administration pages' - but for that to show up even when empty, it really ought to use system_admin_menu_block_access(). So to show just how bad things get, here's a screenshot of the front page with devel query log output turned on - note the 5x2 queries for system_admin_menu_block() - that's 10 out of 43.

Status:Needs review» Needs work

The last submitted patch failed testing.

catch’s picture

Posted #557806: Cache the toolbar per-user which would fix the immediate issue in HEAD without showing dead-end links, and has additional stats on performance issues (approx. 20% of page execution time, and 30% of database queries on a newly installed Drupal).

catch’s picture

Status:Needs work» Needs review
Issue tags:+API change
StatusFileSize
new4.96 KB
Failed: 12298 passes, 0 fails, 1024 exceptions
[ View ]

Marked the caching issue postponed on this - to make that work will require piling hack upon hack.

Here's the difference that caching made though:

Before patch:
Executed 43 queries in 26.31 milliseconds. Page execution time was 93.31 ms.
Executed 43 queries in 29.88 milliseconds. Page execution time was 97.41 ms.
Executed 43 queries in 24.89 milliseconds. Page execution time was 84.37 ms.

After patch:
Executed 30 queries in 16.55 milliseconds. Page execution time was 71.57 ms.
Executed 30 queries in 16.96 milliseconds. Page execution time was 77.55 ms.
Executed 30 queries in 18.57 milliseconds. Page execution time was 75.16 ms.

That's just under 1/3rd of queries, 2/5 of query execution time, and around 15-20% of page execution time on a light non-admin page taken by toolbar menu rendering.

Re-rolled the patch.

Status:Needs review» Needs work

The last submitted patch failed testing.

catch’s picture

Can't reproduce those exceptions locally, either via the UI, or via the command line. Cool that there's 1024 though.

catch’s picture

Status:Needs work» Needs review
StatusFileSize
new7.33 KB
Failed: Failed to apply patch.
[ View ]

Re-rolled.

sun’s picture

Status:Needs review» Reviewed & tested by the community

The menu system is totally screwed up in HEAD anyway, so having one regression more or less doesn't count.

catch’s picture

Well yeah, it's basically a choice of which kind of regression we want - links to empty categories, or a 25% increase in database queries and quite a bit of extra time spent in PHP.

Note we /can/ fix performacne this in toolbar.module with caching, but it's going to take a lot of special-casing and workarounds, and won't work for menu.module blocks which may contain admin links, so I'd like to see this committed or won't fixed before putting any time into that.

Dries’s picture

Status:Reviewed & tested by the community» Fixed

Rolled back. Let's figure out a proper solution.

catch’s picture

Title:Revert system_admin_menu_block_access()» Empty admin categories are not hidden
Status:Fixed» Active

Let's start again then:

One idea I had, but need to look at feasibility - system_admin_menu_block_access() rendered the entire block of links with all their menu items to check access, it seems like we could bail out before that. Something like this:

Fetch the child links (still one or two queries per set of links).
If any of the child links have the same access callback and access arguments return TRUE (is this information available easily though?).

If not, return as soon as any of the access callbacks has returned TRUE to save checking all of them. I don't think either of these would be a lot cheaper though.

sun’s picture

ok. Recent discussion and back and forth on #591682: Config pages are effectively hardcoded to some subcategory of 'admin/config' clarified:

  1. This is required for Drupal 7, as long as the meta categories below admin/config/* are not removed.
  2. This is required to work on a different layer: the menu system - and not only for some special-cased top-level menu items.

Regarding 1: In general though, the Toolbar will now expose a "Reports" menu item, even if the user does not have access to sub-items (or the other way around, you can't expose a report item from a contrib module without granting the permission to access all site reports), so it's not really limited to admin/config/* categories.

Regarding 2: This means that we need to re-introduce MENU_DYNAMIC_ITEM.

David_Rothstein’s picture

Subscribe.

Yeah, I don't understand how removing the meta categories below admin/config/* fixes this problem at all... The biggest part of this problem for D7 seems to have to do with the top level of the management menu (toolbar)... all of whose items are nicely displayed at the top of your screen, even if you don't have access to any of the items underneath some of them, right?

catch’s picture

No, there are two issues.

1. Top level items - that can be 'solved' by separate permissions for viewing reports or changing themes etc.. Harder to do for /admin/config though. This problem affects the toolbar.

2. sub-categories under those top level items. For menu.module or admin_menu.module this means it shows the 'locale', 'people' or 'development' categories in the menu tree, even if there are no accessible links after them, when that tree is expanded. The original patch fixed this, in a way which caused something like a 10-15% (or more) slowdown in HEAD, hence why I pushed for a rollback. The toolbar isn't affected by this, because it doesn't expose those links - however it created a massive performance regression by causing access callbacks to be called on all of those links on every page - in the region of about 20%.

if we were to remove the subcategories altogether, then we would only need to deal with the top level items in terms of access, and such a thing could be done a lot more performantly, albeit likely in a special cased and hacky way - since we'd only need to determine the visibility of 5-6 links, not the 10-20 subcategories too. If we want to leave the subcategories in, hide them when empty, and not further degrade performance, that's currently an unsolved problem.

sun’s picture

performance regression by causing access callbacks to be called on all of those links on every page

Frankly, I don't really understand why this happened on every page. I can understand that the rendering function menu_tree_output() is invoked on every page, but I don't really grok why we need to rebuild the menu tree and therefore invoke menu_tree_check_access() on every page?

sun’s picture

Status:Active» Needs review
StatusFileSize
new10.85 KB
Passed: 14477 passes, 0 fails, 0 exceptions
[ View ]

Alrighty. After a quick discussion with smk-ka, we found a really smart way to overcome the entire issue.

This patch makes the Management menu block work correctly. (and therefore also admin_menu)

After further discussion in IRC, it seems like I was totally mistaken about the purpose of MENU_DYNAMIC_ITEM in D5, and this patch still uses that constant name, but I'll change that in the next patch - probably to MENU_GROUPING_ITEM or similar. Ping me in IRC if you have a better suggestion.

I'll also look into removing all the crappy workarounds from Toolbar and System module now.

sun’s picture

StatusFileSize
new13.47 KB
Passed: 14492 passes, 0 fails, 0 exceptions
[ View ]

We are not going to fix those awkward system_admin_menu* functions in here. Those are total hacks, entirely disregarding menu tree functionality. Those can be fixed in #618530: System module's "listing" pages (and blocks) should use menu_build_tree(), but not here.

This patch makes all functionality that properly uses menu tree data functions correctly output those grouping items and meta categories - which includes the "Management" menu block.

Hence, if you want to test this patch, then change your admin theme to Garland, so you see the Management menu block on all admin/* pages.

pwolanin’s picture

Priority:Critical» Normal

critical means Drupal doesn't work or is insecure

pwolanin’s picture

ok, sun very patiently explained this issue to me in IRC, and now I understand why it's a bug and needs to be approached at this level of the API:

  • this issue is about how we display menu links, not about actual access to paths.
  • the algorithm for determining access to a link does not check any child links if a parent link is denied access
  • the above fact makes it very difficult to sensibly use an access callback to hide a link with no visible children
  • the proposed change should not break any existing D7 (or D6) code if it's done right
sun’s picture

Priority:Normal» Critical
StatusFileSize
new13.5 KB
Passed: 14479 passes, 0 fails, 0 exceptions
[ View ]

pwolanin and me discussed the constant name, and having to decide between MENU_GROUPING_ITEM and MENU_CONTAINER_ITEM, we went for the latter.

And, yes, this patch would basically be back-portable to D6, because, although it introduces a new menu system type and constant, it doesn't really change the regular behavior of the original MENU_NORMAL_ITEM. The only modules and implementations that should be affected by this are menu rendering modules, and from all menu rendering modules I know, only Administration menu implemented a really awkward workaround that tried to fix the problem at least for the always visible top-level menu categories in D6 (i.e. content, build, settings, etc).

sun’s picture

And. Yeah. This patch is, again, an insane attempt to fix the nightmares of the menu system.

The patch fixes the actual issue, but it reveals a total flaw in a part of the menu system unrelated to this patch. Somone introduced a $max_depth parameter to menu tree data building functions without thinking about the consequence that with this forced tree limitation, the entire 'has_children' property is fucked up. As of now, no implementation is able to figure out whether a link really has no children or whether it just has been limited by the original caller. :(

sun’s picture

StatusFileSize
new17.11 KB
Failed: 14541 passes, 2 fails, 0 exceptions
[ View ]

I forgot to mark as needs work, but then again, this patch including very simple tests will let the testbot do it for me.

Status:Needs review» Needs work

The last submitted patch failed testing.

pwolanin’s picture

Priority:Critical» Normal
Status:Needs work» Needs review

@tha_sun - the max depth param isn't really used much yet - it should only be used in rare cases for optimization. I think we can account for it readily enough by not worrying about hiding the link if we are at the max depth.

pwolanin’s picture

Status:Needs review» Needs work
sun’s picture

StatusFileSize
new17.35 KB
Unable to apply patch drupal.empty-categories.92.patch
[ View ]
new129.62 KB

The problem lives elsewhere and is even more fundamental than the $max_depth parameter. A screenie explains best:

empty-categories-page-tree-problem.png

There is absolutely no way to figure out whether this category/container link (Structure) has any children or any inaccessible children, because menu_tree_page_data() only loads the menu tree to the level of the link (Structure), but not anything below.

Hence, there is no way to determine whether this link should be displayed or not (because it doesn't contain or provide anything for the user) -- unless we would replace menu_tree_page_data() with menu_tree_all_data(), because the latter always builds the entire tree.

This is a fundamental problem in the menu tree building of menu_tree_page_data(), because currently, the "has_children" property of links is completely pointless. The property is TRUE even if a link has no children. My last patch contained a (commented out) fix for that in _menu_tree_data().

However, even when fixing that problem, then we still have absolutely no way to figure out whether a MENU_CONTAINER_ITEM link should be displayed, because the menu tree we have at hand does not contain any further children we could check.

The problem does not necessarily exist with menu_tree_all_data(), because that function generates the full menu tree, so we would have any possible children to determine whether a parent link should be displayed.

Brainstorming with smk-ka, we played with the idea of conditionally lazy-fetching any sub-links for MENU_CONTAINER_ITEMs when needed to determine access to it (i.e. grab all links using the mlid of the link as plid). However, those conditional queries would then run on all pages where a MENU_CONTAINER_ITEM link is visible in the tree (and has no children), which could be a performance penalty.

Another idea was to additionally fetch further children right within menu_tree_page_data() for all MENU_CONTAINER_ITEMs if not already contained in the tree result (so it would be cached with the tree) and pass that data on to menu_tree_data().

Bojhan’s picture

Priority:Normal» Critical

Can we please keep this at highly-highly critical, we will need this to have a good IA. Because the UX-Team already pointed out, right after we ended the streak of creating all the initial categories that we need Drupal to provide more good defaults. Not to only to keep consistency but primarily to provide direction, sorry - but IA is critical.

Bojhan’s picture

#627080: [meta-issue] Additional categories admin/config Will be the issue, where we create additional categories.

pwolanin’s picture

Doesn't the earlier patch not handle this? I'm not sure why the discussion of a new algorithm.

Damien Tournoud’s picture

There is no generic solution for this "link container" problem, except by loading all the links for each user and each page (remember that the visibility of a menu link can depend both on the user and on the page, and can even depend on any other random variable outside of the control of the menu system).

We need to reduce the complexity of the problem somehow.

I suggest we only hide empty categories that satisfy the following condition: all the links below the category are:

* categories, or
* links related with a menu router whose access callback is 'user_access'

A category that doesn't satisfy those conditions will be always displayed.

With those restrictions, we can cache the visibility of the category per role. Does this seem acceptable?

catch’s picture

I can't off the top of my head think of any pages under /admin which don't have user_access() as a menu callback, so that ought to satisfy enough cases to make it viable.

sun’s picture

I wonder whether we don't have a very very similar logic with 'expanded' in http://api.drupal.org/api/function/menu_tree_page_data/7 already, which basically does what I outlined as last resort in #92.

chx’s picture

http://drupal.org/node/591682#comment-2425632 has a solution. ick but solution.

sun’s picture

Review of #591682-41: Config pages are effectively hardcoded to some subcategory of 'admin/config'

I didn't think about the option to toggle visibility during menu router (link) building, that's interesting. I don't see the need for limiting this to parent/child access callback (mis)matches, but would rather consider to introduce a fragile and ugly hack that makes a parent item invisible in case no child is accessible -- only supporting non-dynamic children.

That would at least solve the concrete use-case and problem we have now.

EDIT: I mean, for non-dynamic children, invoke the access callbacks during menu router building. If there is a dynamic item below a MENU_GROUPING_ITEM, the parent cannot be hidden.

chx’s picture

StatusFileSize
new1.65 KB
Unable to apply patch menu_group_item_nice_little_query.patch
[ View ]

during menu router (link) ?! Yes. Good idea. Let me feel the links rebuild ... striking at the evil core ... this day will last forever... (i should listen to less Judas Priest but something must keep me awake at this hour).

jhodgdon’s picture

There are typos in this patch: groupping should only have 1 P in it.

chx’s picture

Sure there are. It needs comments and tests too. Others can work on those...

pwolanin’s picture

Priority:Critical» Normal

not critical - this does not prevent Drupal from working, and is not a regression

pwolanin’s picture

catch pointed out related issues with background into in #54

Discussing this in IRC yesterday, with chx, Bojhan, and webchick, this was what I took away:

  1. This is not a release blocker
  2. Some fix to this is still a really high priority
  3. Previous fixes (as discussed in #54) that were complete had too high a performance hit.
  4. The SQL in chx' last patch ins only correct in some cases.

In terms of the menu links part of this, I suggest we proceed with a logic similar to what chx porposed, but simplify the conditions so we only hide these special links if they have zero children. This should solve the proble for user 1 or any admin with full permission, though some junior admin with partial permissions may still potentially see empty categories. I think that's easy enough and would be an improvement over the current situation, so we should do that while anyone still otivated can work on a complete fix for 7.x (or 8.x).

yoroy’s picture

Would love to test the patch that implements the above suggestion :)

David_Rothstein’s picture

In terms of the menu links part of this, I suggest we proceed with a logic similar to what chx porposed, but simplify the conditions so we only hide these special links if they have zero children. This should solve the proble for user 1 or any admin with full permission, though some junior admin with partial permissions may still potentially see empty categories.

I had a patch months ago (see #591682-27: Config pages are effectively hardcoded to some subcategory of 'admin/config') that did this but at the time people did not consider it a complete solution.

Mine hid the links on output, compared to @chx's which does so on menu rebuild. I think @chx's approach is probably cleaner if it works correctly. But if we need to try a different approach, there's a starting point for that too :)

Status:Needs work» Needs review
Issue tags:-Performance, -Release blocker, -API change, -D7 API clean-up

Re-test of 296693-empty-admin-categories.patch from comment #2 was requested by bakr.

Status:Needs review» Needs work
Issue tags:+Performance, +Release blocker, +API change, +D7 API clean-up

The last submitted patch, menu_group_item_nice_little_query.patch, failed testing.

Bojhan’s picture

Priority:Normal» Critical

This is a critical UX bug.

pwolanin’s picture

Priority:Critical» Normal

not critical

pwolanin’s picture

Priority:Normal» Critical

Looking at current D7 - these links don't show up in side blocks typically - especially with the overlay.

So the main UX problem now is pages like admin and admin/config that may have empty blocks?

pwolanin’s picture

http://api.drupal.org/api/function/theme_admin_page/7 doesn't respect $block['show'].

That's certainly part of the problem.

pwolanin’s picture

Status:Needs work» Needs review
StatusFileSize
new3.57 KB
FAILED: [[SimpleTest]]: [MySQL] 18,916 pass(es), 24 fail(s), and 2 exception(es).
[ View ]

Partial fix. Is it right? Good enough?

Status:Needs review» Needs work

The last submitted patch, 296693-hide-empty-admin-120.patch, failed testing.

pwolanin’s picture

Are the test fails real? Did this hide a link that should stay visible?

jhodgdon’s picture

The failed tests are all in language negotiation, and don't look related to this patch? http://qa.drupal.org/pifr/test/42318
I'll request a retest.

jhodgdon’s picture

Status:Needs work» Needs review

#120: 296693-hide-empty-admin-120.patch queued for re-testing.

sun’s picture

Status:Needs review» Needs work

I'm not sure why you are saying that this only affects the admin/ and admin/config and similar pages.

We can turn the following in a test, and it will fail:

* Create a new user with permissions

- access administration pages

- access dashboard (required, since Dashboard contains a hack to replace access to admin/ [WTF])

* Log in that user, and go to admin/

* Neither "Structure" nor "Configuration" should be displayed in the Management menu block.

* Go to admin/config... none of the sub-categories should be displayed in the Management menu block.

Note that I mean the Management menu block. Seeing the empty categories in the page content is a derivative bug, not the cause.

catch’s picture

Status:Needs work» Needs review

Well there's two bugs here. In D6, you don't see empty admin categories in /admin - neither did you in D7 until a couple of months back, I'm not sure which issue caused that regression - that should be critical due to the regression if nothing else.

The other issue is that menu links display for the categories even if there's nothing in them, that's the same behaviour as D6, the fix which was committed here some months ago made logged in user performance suck due to effectively rendering the entirety of /admin on every page view just to see if there was any links to show there. There's a patch somewhere to at least hide completely empty categories without the crazy access check which seemed like a decent compromise to me, not sure where that is.

Either way, these are two different, though related bugs, and not fixing the latter, shouldn't hold up fixing the former. If that takes two different issues so be it.

catch’s picture

Status:Needs review» Needs work
Issue tags:+Performance, +Release blocker, +API change, +D7 API clean-up

The last submitted patch, 296693-hide-empty-admin-120.patch, failed testing.

donquixote’s picture

Looking at system_menu() in D7:

  $items['admin/structure'] = array(
    ...
    'access arguments' => array('access administration pages'),
  );

How is it surprising that it does show up for users which have this permission?
If we don't want it to show up, we need a custom access callback for admin/structure.
A menu item is not hidden only because it has no children - that would be illogical to expect.
What did I miss?

catch’s picture

@donquixote, if you re-read this issue, you'll see that some time last year, an access callback called system_admin_menu_block_access() was added, which checked for child items of the menu item to see if the top one would be rendered. I eventually posted a patch to revert this because it was a ridiculously high performance cost - #520364: system_admin_menu_block_access() makes no sense and some other issues have more background.

However in the meantime, there's also a regression somewhere causing the empty categories to show up on admin pages themselves, which pwolanin's patch addresses (but looks like those locale tests really are broken by it).

pwolanin’s picture

@sun - I frankly don't care if links to empty page show up in the block - I think it's much less important, and I'd argue as to whether it's a bug or not.

sun’s picture

Well. At minimum, 42% of all Drupal sites/users will care. And, depending on module decisions, various larger Drupal distro/SaaS-providers will likely care, too. In addition, the UX team cares, too.

A quick fix (hack) for those page contents makes little sense to me. Instead, we need to fix the cause - possibly by remixing/combining all previous solution attempts into a new one.

catch’s picture

That's not a hack for the page contents - the blocks shouldn't show up if they're empty.

In fact, if you put system_admin_block_access() back into core with that current bug, you'd still get the child items, because those empty blocks get rendered, and that's what it checks - the actual rendered output of the block (or the renderable array now most likely).

So we at least need a baseline of D6 non-regressed functionality before trying to do a major rework of this (which is what it's going to take to fix it IMO unless someone manages to come up with a performant solution which solves the issue for everyone within the current limitations - which none of us have yet).

donquixote’s picture

#92 (sun):

Brainstorming with smk-ka, we played with the idea of conditionally lazy-fetching any sub-links for MENU_CONTAINER_ITEMs when needed to determine access to it (i.e. grab all links using the mlid of the link as plid). However, those conditional queries would then run on all pages where a MENU_CONTAINER_ITEM link is visible in the tree (and has no children), which could be a performance penalty.

Another idea was to additionally fetch further children right within menu_tree_page_data() for all MENU_CONTAINER_ITEMs if not already contained in the tree result (so it would be cached with the tree) and pass that data on to menu_tree_data().

I think that's the way to go.
In menu_tree_page_data(), we know which items hit the $max_depth level, so we can fetch further children only for those items that have MENU_DEPENDS_ON_CHILDREN and that hit the $max_depth limit. We only do this when all the items which fail the usual access check are removed, and we only fetch as many children as necessary to check if the item has any visible children.

Right now the menu_tree_check_access() happens after menu_tree_data() and menu_tree_collect_node_links(). Maybe this has to be rearranged a bit, to get the most out of it..

Then we can remove system_admin_menu_block_page_access(), because this special type of access restriction is dealt with in a different way.
Did I miss something? I guess so..

pwolanin’s picture

note the blocks are not built using just menu link data - some dirty hacks are in there to sometimes pull in local tasks too (why?), so I am not at all confident that we can unhack this mess cleanly for D7.

I continue to not understand why having links in the block that lead potentially to an empty page is really a big an UX/UI issue.

catch’s picture

@pwolanin - that was this patch #551080: List non-container items on /admin for a complete overview which IMO needs to be rolled back before release because it's a significant step back from D6.

pwolanin’s picture

catch - sorry, let me clarify the above. I think have all links in the menu links block (and in the menu admin UI) is the correct behavior. If they are not, how can you find it to add items to it?

In Drupal 6 you can put any link under the /admin link to create a new category - I consider that a useful feature. So it actually sounds like #551080 made Drupal 7 match the Drupal 6 behavior?

catch’s picture

@pwolanin: I think we crossed wires a bit.

The menu links block and the menu admin UI - yes this is the correct behaviour as far as core is concerned. I can see arguments for hiding those links if there's no children at all, and would be OK with this if it's done in a performant way. I'm less keen on the "hide the link if the current user doesn't have access to any of the child links" since that only affects sites with multiple levels of administrators, and so far the fixes for it have caused major issues on any site which exposes admin links somewhere other than /admin - cure worse than the illness etc.

However, there's another set of 'blocks' - those which appear on /admin and admin/config, generated by system_admin_menu_block() - and in D6, and D7 until recently, these were hidden if there were no links to render. Hiding those blocks correct behaviour IMO and should be fixed as a regression. If #551080: List non-container items on /admin for a complete overview caused this regression that's just another reason to revert it.

I don't think it matches D6 behaviour at all, because sub-items of admin/config aren't shown there, and we have two huge ugly admin pages (/admin and /admin/config) instead of one.

sun’s picture

I at least need the agreed on menu type constants from the patch in #92 to work around this very annoying UX problem in admin_menu.

catch’s picture

MENU_CONTAINER_ITEM and MENU_DEPENDS_ON_CHILDREN both sound reasonable to me.

boombatower’s picture

From a naming perspective

'type' => MENU_CONTAINER_ITEM
'type' => MENU_DEPENDS_ON_CHILDREN

The first is a much better "type" then "depends on children" which seems more like an additional descriptive attribute.

+1 for container item to solve this.

catch’s picture

Priority:Critical» Normal

Would still be nice to fix the menu link issue, at least for completely empty categories as opposed to ones with no access, but since there's never been a viable patch on this issue, and the D6 regression just got fixed in #805124: admin/config shows empty admin blocks I'm downgrading this from critical.

tstoeckler’s picture

Priority:Normal» Critical

Since this has the API change tag (and Release blocker as well), reraising to "critical" to raise awareness.
If this is not in fact "critical", please either move this to Drupal 8 or, if this can be done without an API change, remove the corresponding tag.

catch’s picture

Version:7.x-dev» 8.x-dev
Priority:Critical» Major
Issue tags:-Release blocker, -D7 API clean-up

Moving this to D8, there's no regression from D6 here, there has never been a viable patch that doesn't make something else worse. It would be feasible to do the crazy access callback stuff in a contrib module if people really, really want this over and above the performance of their site in Drupal 7.

tstackhouse’s picture

Subscribing. This is still an issue in D6 that is negatively affecting the UX on my sites. #461700: Get rid of menu groups which are empty in Administer was marked as a duplicate of this, but does not seem to be addressed, not to mention this was reported as resolved in that ticket, however this is still an issue.

jhodgdon’s picture

If you read the entirety of that issue, you'll see it was reported as resolved and then later reported as reverted. If you read all 148 comments here, you'll find out that the reason it was reverted is that it caused a huge performance problem (at least I think so from comment #145 above). So we don't currently have a fix, and the issue has been moved off to Drupal 8 for consideration of a good fix.

math-hew’s picture

Here's how I use CSS to hide unnecessary admin menu sections for my editors who don't need to see Site Building, User Management, and so on. I'm using D6 to run a college website with multiple editors across campus.

1) Create a role for your editor. Let's have some fun with it and call it "editor".

2) In your theme's page.tpl.php file, add the user's role(s) to the body tag as classes:
<body class="<?php $userclasses = implode(" ",$user->roles); echo $userclasses; ?> >"

Obviously it's helpful if you don't have any spaces in your roles' names, but you can easily get around that with a little extra PHP (wasn't an issue for me since none of my editor roles had spaces).

3) Hide the menu items with CSS attribute selectors like so:

body.editor #admin-menu a[href="/admin/build"] { display:none; }

That's it!

sun’s picture

Category:bug» task

Extremely annoying, but only borderline a bug.

klonos’s picture

Title:Empty admin categories are not hidden» Hide empty admin categories

...title change then ;)

tim.plunkett’s picture

Category:task» feature

With some perspective of the other sorts of major tasks we have at this staged, this is a feature request from D7.

dawehner’s picture

Version:8.0.x-dev» 9.x-dev
Issue summary:View changes

The usage of the toolbar as primary navigation helps a lot here already, as people either see, or don't see the "People" menu item, depending on their access. The problem
on the admin/overview pages though still exists.

I guess though that this can also be moved to 9.x

catch’s picture

Version:9.x-dev» 8.0.x-dev
Category:Feature request» Bug report
Priority:Major» Normal

I think this is more accurate. Moving back to 8.0.x but postponing on #1805054: [PP-1] Cache localized, access filtered, URL resolved, (and rendered?) menu trees.