Restrict access to empty top level administration pages

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

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.

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:

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.

@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.

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

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

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.

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

Ran entire test suite with all passes.

Still applies after dbtng.

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.

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/

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.

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.

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

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

- 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.

This is a annoying bug - better title.

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.

   }
 }
 
+class AdminMenuBlockTestCase extends DrupalWebTestCase {

^^ Missing PHPDoc above the class.

+  /**
+   * Implementation of getInfo().
+   */
+  function getInfo() {

^^ We don't PHPDoc overriden functions anymore.

+    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'),
+    );
+  }

+
+  /**
+   * 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 :)

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

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

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.

/**
 * 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;
}

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.

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:

/**
 * 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;
}

Benchmarks?

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.

subscribe

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

Subscribing too, if a Drupal 6 backport is on the cards.

Subscribing.

Subscribing and looking forward for d6 patch

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?

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

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

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?

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

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.

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

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

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.

Documentation added: http://drupal.org/node/224333#system_admin_menu_block_access

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

Followup patch: #475348: Move admin/development menu category into system.module

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

+1 for 6.x backport

Drupal 6.x branch issue: #461700: Get rid of menu groups which are empty in Administer

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.

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

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.

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.

@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.

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!

Re-rolled.

locale.module changed too.

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

@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.

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.

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).

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.

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

Re-rolled.

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

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.

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

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.

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.

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?

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.

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?

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.

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.

critical means Drupal doesn't work or is insecure

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

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).

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. :(

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

@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.

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

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().

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.

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

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

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?

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.

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.

subscribe…

subscribing

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

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.

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).

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

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

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

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).

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

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 :)

subscribing

This is a critical UX bug.

subscribing

subscribe.
(coming from admin_menu)

not 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?

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

That's certainly part of the problem.

Partial fix. Is it right? Good enough?

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

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.

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

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.

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.

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

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?

@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).

@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.

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.

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).

#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..

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.

@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.

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?

@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.

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.

MENU_CONTAINER_ITEM and MENU_DEPENDS_ON_CHILDREN both sound reasonable to me.

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.

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.

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.

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.

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.

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.

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!

Extremely annoying, but only borderline a bug.

...title change then ;)

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

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

I think this is more accurate. Moving back to 8.0.x but postponing on #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees.

Any update on this now that the issue in #157 is closed?

I'm seeing this issue in Drupal 8.0.4. Enabling the permission "Use the administration pages and help" will show the "Configuration" menu item with all it's child items. Clicking any of them leads to a page with "You do not have any administrative items". Removing the mentioned permission hides the menu items but also hides the "Structure" item even if the user has access to the Taxonomy child menu item.

How to proceed here? Write a custom access check and add to service that does two things, check for "administration pages" permission and check for children of current menu item? Is that enough? Is that easy to do?

Hi there,

I've published a small module, that provides a workaround for that problem in Drupal 8: https://www.drupal.org/project/admin_links_access_filter

It's not very sophisticated, working with preprocessors - but it works for us :)

This is a much more obvious UX issue with the Admin Toolbar in action, of which roughly 25% of all non-dev Drupal 8 sites seem to have enabled

With a significantly reduced permissions on an administrative user, about 80-90% of all the links result in a "You do not have any administrative items.".

This also makes it time consuming actually testing permission access to see what the users can and can not see.

I'm not sure if this should be flagged with "Needs usability review" for that team to take a look. It's not fun opening doors to see a brick wall sitting behind it ;)

Referenced #2673914: Only show admin menu items with available Configuration pages according to permissions in Admin Toolbar queue that has taken a NIH approach to this issue, pushing back to core for a resolution.

For anyone wondering about the commits for this (#162, #163, #166, #167) those are from waaaay back in 2009. No idea why they are just now being attached to this issue. This is still an issue in all 8.x branches.

Thanks @agoradesign https://www.drupal.org/project/admin_links_access_filter works well.

9 Years and counting.. wow.

This is very Drupal. If it's a usability issue it has almost zero priority.

Usability issues are why Drupal is just too difficult to use commercially and scare off new users. Fixing basic usability issues like this blow out dev and training time commercially and confuse the hell out of new users.

Intiatives like #2847582 Out of The Box experience initiative are great but really miss the mark when it comes to addressing what needs to happen to make Drupal acceptable to users in 2017 - like this issue.

For Drupal 7 users I recommend https://www.drupal.org/project/admin_menu_source
It's a time consuming solution but allows you to rename and filter out toolbar link clutter so it's a viable possibility to provide clear and concise training to new admins and most importantly the content editors who are overwhelmed by the Drupal site-builder centric administration menu.

The Administration links access filter module just got merged in as sub module to Admin Toolbar module, and is included in the 8.x-1.21 release.

Anyone feel like the issue summary needs an update? I mean, D6.4?? :)

I had to read that a few times myself, and then I looked at the issue creation date.

I did a quick pass of the initial post so it makes sense for D8.5

This issue is related, however it is a little different since that issue refers to a regression and this one doesn't. I feel like the issues should be merged though and dealt with in one go.

Here is a very ugly, but working js workaround to remove empty menus, not clean, but my customer doesn't want to wait ;-)
It fit my needs, but maybe not all cases.

Drupal.behaviors.menu_hack = {
attach: function(context, settings) {
do {
$(".toolbar-menu-administration ul:not(:has(li))").remove();
$(".toolbar-menu-administration li.menu-item--expanded").each(function() {
if ($("ul", this).length == 0) {
$(this).remove();
}
})
} while ($(".toolbar-menu-administration ul:not(:has(li))").length > 0);
}
}

Thank you, mkalbere! Works nicely.

Tips for others. First, wrap the code in this so that $ is mapped to jQuery:

(function ($, Drupal) {
  "use strict";
  ...
}(jQuery, Drupal));

Second, for me, an empty Workflow menu item was still showing under Configuration. I don't know why. Add this ugly hack before the do loop in mkalbere's code:

      // Remove Workflow menu if MT.
      let workflowMenu = $("a.toolbar-icon-system-admin-config-workflow").parent();
      if (workflowMenu.length > 0) {
        // There is a Workflow menu.
        if (workflowMenu.find("ul").length === 0) {
          // No items in the Workflow menu.
          workflowMenu.remove();
        }
      }

Third, I wanted to give users with only the grader role access to the admin menu, but not the Drupal Help menu. These are in a single permission: "Use the administration pages and help". This code removes the Help menu item for those users.

      // Kill help menus for users who only have the grader role.
      let isJustGrader =
          drupalSettings.currentUserRoles.includes("authenticated")
          && drupalSettings.currentUserRoles.includes("grader")
          && drupalSettings.currentUserRoles.length === 2;
      if (isJustGrader) {
        $("a.toolbar-icon-help-main").parent().remove();
      }

drupalSettings.currentUserRoles was injected in hook_page_attachments():

  // Send user id and roles to JS.
  /** @var Drupal\skilling\SkillingCurrentUser $currentUser */
  $currentUser = \Drupal::service('skilling.skilling_current_user');
  $roles = $currentUser->id() ? $currentUser->getRoles() : [];
  $attachments['#attached']['drupalSettings']['currentUserRoles'] = $roles;

SkillingCurrentUser is a service that wraps the standard User, adding some app-specific stuff. You don't really need it.

NB: I am not an expert Drupal developer.

I think the preferred solution at the moment is to install the very popular Admin Toolbar module, which contains a submodule which fixes it - thanks to agoradesign for his work on this.

Obviously it would still be nice if Drupal core didn't do it to begin with.

Here is what I suggest:
1) Add new option to routes, called for example '_group_route' and set it to TRUE for necessary routes.
2) Implement new route subscriber, which is executed during 'onAlterRoutes' event.
The idea of this subscriber is following: for each route with '_group_route' set to TRUE we check, if it has accessible children by any roles with 'access administration pages' permission. If we find such links, we set requirement '_role' witch points which roles should have access to this route. If there is no such links, we add '_roles' anyway with only admin role.
Attaching patch, it doesn't have any tests so far, because I think, at first we need to check, if this idea is acceptable.

- The issue still exists int Drupal 9.

- The proposal solution that @ilya.no gets looks right. Review in deep permission for parent-children sounds good.

- However not work the patch to 9.0.x branch.
If apply the patch => rebuild routes => cache rebuild => all website not work
If you try to reinstall the website => down the installation.

This is the error that I get:
TypeError: Argument 2 passed to Symfony\\Component\\Routing\\RouteCollection::add() must be an instance of Symfony\\Component\\Routing\\Route, bool given, called in .../core/lib/Drupal/Core/Routing/RouteProvider.php on line 382

Added #2748261: Granting permission to use administration and help sites adds empty menu items as related and closed that as duplicate. Also added @sic here as a contributor for creating the other issue.

Tested via above mentioned steps. Issue is still there on 9.1
Please provide if there is any patch available for 9.1

Attaching patch for D9 with interdiff for previous patch. I've fixed adding roles with OR conditions, instead of previous AND. Also added code for checking menu tree for separate function, because in admin/config menu tree we have other routes with possible empty content, so now it's recursive function.

After applying the patch #195 and following the steps to test(role, permissions, user...). The menu structure for the new user still appears. So needs more work.

I've tested again and it works ok for me. The only problem I had is contrib module Menu Admin per Menu, which adds its own custom access checker for menu 'entity.menu.collection' and return positive access result. But when I disable this module, logic works fine. Added couple improvements for tests.

Hello,

Patch #199 looks good. But I think we need tests for. Am I right?

Cheers, Paulo.

Hello, Paulo! Thanks for the review. Yes, need to write some tests.

Adding a test.

Fixing code standard.

Looks good now.

Nice top see these old issue getting some attention, thanks!

I thought this could use a before and after screenshot so I tried to make one. I was not able to make a user with access to the admin pages on 9.1.x with a minimal install. I gave the user has every permission available. Like the test, Block and Toolbar are installed.

Then I decided to review the code.

1. +++ b/core/modules/system/src/EventSubscriber/GroupRouteSubscriber.php
   @@ -0,0 +1,145 @@
   +use Drupal\Core\Routing\RouteSubscriberBase;
   

   Can we please put the use statements in alphabetical order.

2. +++ b/core/modules/system/src/EventSubscriber/GroupRouteSubscriber.php
   @@ -0,0 +1,145 @@
   +   * @param Symfony\Component\Routing\RouteCollection $collection
   

   Should be \Symfony

3. +++ b/core/modules/system/src/EventSubscriber/GroupRouteSubscriber.php
   @@ -0,0 +1,145 @@
   +   * @param Drupal\user\Entity\User $test_user
   

   Should be \Drupal

4. +++ b/core/modules/system/src/EventSubscriber/GroupRouteSubscriber.php
   @@ -0,0 +1,145 @@
   +   * @param string $test_role
   

   Seems really odd to be using $test_user and $test_role. Why not just $user and $role?

5. +++ b/core/modules/system/src/EventSubscriber/GroupRouteSubscriber.php
   @@ -0,0 +1,145 @@
   +    // Load all menu links below route
   +    // and check if route has any accessible children by any of roles.
   

   Wrap to 80 character.

   And this need a tweak, what does 'children by any of roles' mean?

6. +++ b/core/modules/system/src/EventSubscriber/GroupRouteSubscriber.php
   @@ -0,0 +1,145 @@
   +              // User is allowed to visit this page, but need to check,
   +              // if it's also group route with inaccessible children.
   

   Line wrap to 80 characters.

   I wonder if 'group route' should be group_route'. I don't really know.

7. +++ b/core/modules/system/tests/src/Functional/Menu/MenuAccessTest.php
   @@ -70,4 +70,48 @@ public function testMenuBlockLinksAccessCheck() {
   +  public function testMenuAccessByUserRole() {
   

   This test checks only one role, that a user without access to the structure menu does not see the structure menu. It would be good to test that a user with access does see the structure menu, just to be sure nothing broke.

8. +++ b/core/modules/system/tests/src/Functional/Menu/MenuAccessTest.php
   @@ -70,4 +70,48 @@ public function testMenuBlockLinksAccessCheck() {
   +    $this->drupalPostform('admin/people/roles/add', $edit, t('Save'));
   ...
   +    $this->drupalPostform('admin/people/permissions/test_role', $edit, t('Save permissions'));
   ...
   +    $this->drupalPostform('user/' . $webUser->id() . '/edit', $edit, t('Save'));
   

   This is deprecated.

9. +++ b/core/modules/system/tests/src/Functional/Menu/MenuAccessTest.php
   @@ -70,4 +70,48 @@ public function testMenuBlockLinksAccessCheck() {
   +    $this->assertSession()->responseNotContains('class="toolbar-icon-system-admin-structure"');
   

   I ran the test locally and looked at the resulting html output. The 'structure' menu item is displayed. So this is not doing what is expected. In the html out the class of of 'structure' was 'toolbar-icon toolbar-icon-system-admin-structure'. So, that needs to be changed and then there should be a new fail and pass test as well.

I fixed what @quietone pointed on comment #210, except item 7 and 9.
I could disable the "Structure" menu item but I don't why the tests are falling when set $this->assertSession()->responseNotContains('class="toolbar-icon toolbar-icon-system-admin-structure"'); if in my case I don't see the Structure item.

I attached a new patch with the interdiff but it still needs work.

Why did #211 remove GroupRouteSubscriber.php ?

Adding back GroupRouteSubscriber.php with the feedback implemented as mentioned in #210 except point 7. I have added back the class "toolbar-icon toolbar-icon-system-admin-structure" in the test. Hence the tests will be failing as of now. Still need to fix that.

I agree everything in #210 is addressed, except the test #7.

I was facing the same issue for 8.9.x branch, so I have back ported #213 patch and made it compatible.
PFB patch for 8.9.x branch.

Re-rolling #216 with a change where we are making

admin/config/people

route as group route to handle People menu.

diff --git a/core/modules/user/user.routing.yml b/core/modules/user/user.routing.yml
index dc618eed8a..c4f379d364 100644
--- a/core/modules/user/user.routing.yml
+++ b/core/modules/user/user.routing.yml
@@ -20,6 +20,8 @@ user.admin_index:
     _title: 'People'
   requirements:
     _permission: 'access administration pages'
+  options:
+    _group_route: TRUE

 entity.user.admin_form:
   path: '/admin/config/people/accounts'

re-rolling #217 against 9.0.x branch.

the patch does not apply 9.2.x, Hear an updated patch against 9.2.x.

Applied patch #220 and it works fine.

Before patch:

After patch:

RTBC +1

mmm for Drupal 9.3.x patch #220 not works.

The structure menu for a new role with the permissions 'Use the administration pages and help', 'View the administration theme' and 'Use the administration toolbar' still is showing.

BTW

after run:

$ drush cr
$ drush ev '\Drupal::service("router.builder")->rebuild();'

the website fails

54  07/May 17:54  error     php   TypeError: Argument 2 passed to Symfony\Component\Routing\RouteCollection::add() must be an instance of Symfony\Component\Routing\Route, bool given, called in /var/www/html/contribdrupal9/ 
 55  07/May 17:54  warning   php   Warning: Erroneous data format for unserializing 'Symfony\Component\Routing\Route' in Drupal\Core\Routing\RouteProvider->getRoutesByPath() (line 380 of /var/www/html/contribdrupal9/core/li