User counter is output on login page for anonymous users

At the minimum, this looks like an admin_menu issue.

Ugh. Escalating...

this seems odd to me - the module should never output anything for user's without the permission.

I don't see the bug - please provide details on how to reproduce.

Well, it seems to happen on a few pages:
http://osherlibrary.org/?q=user

When I wrote my previous follow-up there actually was another site in Google's index. However, it's no longer there.

@STNyborg: You have the latest official release installed, do you?

For reference:

weird - so looks like it's getting passed though check_plain() and set as the page title.

Are you using a core theme? Are you setting the title in some odd way in your theme?

Somewhere in the Garland tabs code, the title is being passed through check_plain. I wound up modifying admin_menu.module to reset the title as follows:
$item['title'] = t('Users');

@pillarsdotnet: It would be great if you could answer the questions. Especially, since you set the version to 6.x-1.x-dev, it's important to know whether you are using the latest development snapshot or one before the first official stable release for 6.x.

EDIT: My fault, it wasn't you who set the version. Anyway, please clarify. Thanks.

Well, I looked through a lot of code that I don't completely understand. I originally downloaded the recommended version, but I tried again with the -dev module and ran a diff. No change apart from comments that I could see. Anyhow, here is my progress so far if it helps any:

The only place that the admin_menu module sets the title that way is in the admin_menu_translated_menu_link_alter function.

From the API docs, my first conclusion was that the t() function was being misused. It's not designed to handle HTML code, only straight text. So I separated out the $icon_users text so it is outside of the t() function call. But no dice, the raw html still shows up in the admin/user/user page.

Next, I found a place in includes/menu.inc where the results of that function get used, in the _menu_item_localize() function. Following the logic of that function, I first tried adding the following to the admin_menu_translated_menu_link_alter function:

Still no luck. I ran a few more text searches for $item['title'] and concluded that somewhere in the theme code, it winds up getting used in the page header and the tab header, as well as in the admin menu where it was intended. Perhaps it's a case of namespace pollution? Anyhow, to be consistent with the way the *rest* of drupal treats that variable, I made the following workaround. (Diff against 6.x-1.x-dev version):

(shrug) works for me. Your mileage may vary.

um, well that code will surely break the functionality. Could you please answer as to whether you are using a core theme?

SUN: I am using the latest official version "Drupal Administration Menu 6.x-1.0".

In addition I have tried to recreate the error on other pages but without success (!). The error only appears on the user login page (see http://ihsg.agriscience.info/user) [layout and content are still being processed] and apparently only when printing out the stored values $head_title and $title.

It should have been obvious from my comments, but I am using a fresh install of Drupal (was version 6.2, now version 6.3) and the error appears on the admin/user/user page. I have not (yet) changed from the default Garland theme.

EDIT - rereading, it wasn't obvious. I had originally mentioned Garland but somehow edited out in a later revision of my comment. (I usually preview several times before submitting.)

And yes, I am aware that my change breaks the intended functionality, but imho the browser titlebar is the wrong place to put the number of anon/logged users followed by a graphic icon. So I'd rather drop the feature than break standards. I'm not willing to invest the time to rewrite the otherwise excellent admin_menu module in order to implement a feature that I don't particularly need. So I present my workaround in case anyone else is similarly situated. Note: workaround is different from fix. Hopefully, the module author will provide a fix, which would entail using some other namespace than "title" for his feature, when "title" is so obviously used in areas where a graphic icon will not work.

I am having the same issue. Just upgraded from 6.2 (worked fine) to 6.3 (now the problem mentioned above).

Attached is a screen shot.

Attachment	Size
admin_menu_error.jpg	52.52 KB

I've found a workaround for this but I'm fairly new to Drupal so I'm not sure if its good programming. I modified the admin_menu_translated_menu_link_alter function in admin_menu.module. On line : 255 I added

This checks whether the user is logged in, if not it sets the title to "Login" which solves the bug on the user login page. It seems to work ok and is probably useful as a temporary measure.

I've got the same issue. Subscribing

I'm still a bit perplexed - this could not ( I think) be happening unless you are setting the active menu somewhere.

When I visit /admin/user/user on my local (D6) install with admin_menu running, I get the expected:

#290437: Title Problem on path 'user/login' and #293154: Conflict between Zen and Admin Menu have been marked as duplicate of this issue.

Sorry for the duplicates!

Although this issue is caused by Admin Menu it somehow seems to occur only in combination with some other modules. In my case all the problems disappear as soon as I deactivate local menu.
I noticed that some of the sites with this problem are using nice menus.

So, my guess is that the issue appears as soon as there is another module that changes Drupal's menu system in some certain way.
Unfortunately, I wasn't able to find the peace of code that is causing all this.

On my site the problem is not restricted to http://mysite.tld/user. There is also something weird happening at http://mysite.tld/admin. (Look at the block title and the favicon in the breadcrumbs in the attached screenshot)

Two further examples of the error:
http://www.isis.vanderbilt.edu/user
http://www.haase-jaekle.de/drupal6/user

Attachment	Size
admin_menu.jpg	11.6 KB

extect, are you certain that the problem is caused by the Administration Menu module? My feeling is that the problem is caused by the Local Menu module and exasperated by the Administration Menu module.

Hi,

Came across this issue from another context.

Setup: Drupal 6.4 with garland theme.
Modules: admin_menu 6.x-1.0, menu_breadcrumb 6-x.1.1

If I install/enable the module menu_breadcrumb, then the issue arises when I visit /admin/user/user and /admin/user/user/create.

If I disable menu_breadcrumb, the issue goes away. If I re-enable menu_breadcrumb, the issue returns.

Perhaps this might be easier for you to reproduce?

I had the same problem as bengtan above with the same module setup, although on Drupal 6.3. I've tracked it down to the fact that menu_breadcrumb looks up the menu_links table to find out which menu admin/user/user belongs to, and the result is that it belongs to two menus: navigation and admin_menu. Now menu_breadcrumb sets the active menu to the first result, which is somewhat arbitrary and which is probably why the bug is hard to reproduce and why davidseth (at #14) was ok on 6.2 but not 6.3. The desired result is that menu_breadcrumb picks the navigation menu instead of admin_menu, so here's a quick fix:

I've also looked into local_menu, which I also have installed, and it also sets the active menu in much the same way as menu_breadcrumb, so you may also use the same fix:

Both these fixes mean hacking modules, which I know shouldn't be done, but they should work for everyone for now unless you somehow want the active menu set to admin_menu.

In any case this seems more like a compatibility issue than an admin_menu bug since I'm not sure if there's much that can be done on it for a fix. My current thought is that modules such as menu_breadcrumb and local_menu should have options to manually exclude menus when setting the active one. Unless someone can think of a fix for admin_menu itself then perhaps we should open issues with these modules.

Waiting for more comments before re-categorizing this issue...

Shane, thank you very much for taking the time to track this down. Your findings are very very valuable.

Given these facts, there are only the following possible assumptions:

- Either all contrib modules need to check (exclude) certain conditions when trying to determine the active menu item
- or the menu system in D6 is unable to deliver the proper information
- or admin_menu must not register an existent path that might lead to menu link path clashes
- or admin_menu must not use the menu system at all.

Well, after discussing this thoroughly with smk-ka and reviewing the code of local_menu and menu_breadcrumb modules, we came to the conclusion that both of these modules are improperly querying data from the menu system. The error is caused by this query (in both modules):

...which does not check for access permissions (!). Now, this is just the trigger. The real caveat is that those modules are unable to check access permissions in a database query, because the new menu system invokes (arbitrary) callback functions to check whether a user has access to a given path. The required behavior depends on the module's intention, but basically: To get the proper result, they would have to query all possible paths (including parent paths), test whether the current user is allowed to access each path, and return the best match.

Even more findings, similar issue: http://drupal.org/node/295476#comment-984615

...which would mean that also Token module in D6 is using a wrong database query.

Daniel, thanks for the quick reply and for also looking into this!

After taking another look at the menu_breadcrumbs and local_menu modules it does seem that they check for access. The sql result is passed to the menu_link_load() function, which calls _menu_link_translate(), which calls _menu_check_access(). I'm pretty sure that this last call does all relevant menu access checks, although I haven't looked at it in-depth or tested it.

In any case I've been thinking about your assumptions and here's my current train of thought. The question "to which menu does this item belong?" is similar to asking "what is the alias to this path?" in that multiple results can be returned in both cases. Now since paths with multiple aliases are not recommended maybe so should items belonging to multiple menus. The conclusion to this is that all the modules in question, including admin_menu, are not properly implemented (admin_menu registers items in a menu that are already in other menus, and the other modules are expecting single results when multiples are sometimes returned). Of course this is not good news for admin_menu since it uses existing menu functions extensively and effectively. In the end I would much rather fix Drupal's menu system to handle items in multiple menus, but I don't think that would happen until D7 or later.

Here's how I see it right now: the easiest way to a fix is to have exclusion lists in all relevant menu-seeking modules; the better fix would be to revamp admin_menu; the right way to fix is to work on Drupal's menu system.

Lastly, I haven't been able to check either 6.x-1.x-dev or 7.x-1.x-dev of admin_menu for this issue (only 6.x-1.0) and I apologize if it has already been taken into account when making these versions.

Yes, _menu_check_access() gets called, but the result (which is stored as attribute $item['#access']) is never actually used, that's the problem. Instead of using the first database result, the modules should cycle through *all* results and choose the one that fits best.

However, determining the best match seems to be not possible with the current menu system. Ideally, it would implement menu "weights" which would allow modules to determine the best fitting result: the Navigation menu set to very high priority (low weight) because it is usually the best match, followed by other regular menus (or equally weighted), and a very low priority for admin_menu (or even a special "don't use" value for any modules that duplicate the menu tree instead of adding to it).

For now, however, these modules should just try not to pick menu items for which the current user doesn't have access to. IMO this *should* work in 99% of all cases (but haven't tested yet).

subscribing...

thanks for the quickfix on the database query !

works in our case.

Previous to doing this, I disabled admin_menu and i got icon_users as the title in the /user page for anonymous users. Don't know if this says anything to you, not a developer but I thought I'd let you know in case it shows a clue of whats happening (using menu_breadcrumb).

Here is a list of all the modules we have currently (on drupal 6.4):

In case it helps, thanks for the effort guys!

Thank you very much for the quickfix to the menu_breadcrumb. Works on my site now...

Sorry, this is not a real solution.

Nice to see my first (small) contribution to the Drupal community is helping. =) Although I agree that it's only a quickfix.... Created issues for menu_breadcrumb (#303247: Menu Breadcrumb setting active menu to undesirable menus) and local_menu (#303249: Local Menu setting active menu to undesirable menus).

@smk-ka Thanks for correcting me about the access callbacks, I see what's going on now, although I don't believe checking for access is the solution in the end. If a logged-in user has access rights to the admin_menu menu then couldn't the active menu be set to admin_menu? I believe that's what's happening in my case... Anyways, I like your idea about a sort of weighted menu system to fix things across the board.

subscribing..

I'm using menu_breadcrumb here.
Tried the quick fix at #22. Doesn't work.

The fix is by changing the line to read like this:

PS: I know it's a dirty fix. But at least it works for the moment.

@wuf31: Please check the related issue Proct0t created in #30.

I see I should have been following this issue instead of mine. I think the overall problem is that drupal does not have a way to relate node information to a menu item. I think the beginning of a solution is to add a mid column to the node table and upon a save of a node obtain the mid and add it with the node. Then all these modules that are having to do lookups using the path can actually look at a specific node and obtain the exact menu. This would need to be a D7 fix so this is a future fix, but I think it's the right start. One thing I don't necessarily understand is how when you edit a node it always chooses the right menu item in the menu settings box. When I get to work I'll research what they do and see if I need to put in an issue for drupal.

By design the D6 {menu_links} table can have any number of links pointing to the same path.

The query might be better fixed by writing:

There should be only one such link in the table.

subscribe

I'm using Administration Menu 6.x-1.0 and I have the same issue as in #14. In magical way drupal changes chars: <, > into &gt and &lt. I thought this was issue, but the real issue is that non logged user don't have to know how many users are on the site, and how many of them are successfully logged.

On my site I also have menu_breadcrumb and nice_menus, but I don't think they are the main reason.

I fixed it by using #15 (thanks bensmiley) with some changes.

So here it is:

I don't know Drupal very well. In fact this was my first real try to fix something in this CMS. Maybe someone do this better or in right (drupal) way and implement this permanently to this module.

This doesn't fix issue on page /admin/user/user, when user is logged in.

I think this is not our problem - a bad query in other modules:

#296534: Link paths are not unique for Local Menu module
#303247: Menu Breadcrumb setting active menu to undesirable menus for Menu Breadcrumb module

well, i've created my very first module to implement the "menu weights" idea that smk-ka has suggested. Of course i've only written this overnight and it's currently of no great quality, but perhaps I could publish it on Drupal as a starting point? My current thought is that that other modules, such as local_menu and token, would depend on this module to solve the dilemma, although I'm unsure if those module owners would be willing to depend on another module like that. The new module would effectively include and replace menu_breadcrumbs. The other possibility is that we patch Drupal itself to put this functionality into core - where I think we agree it belongs. Of course if Drupal were to actually accept this I wouldn't see it happening until D7, leaving us again with the module for now..... Any thoughts would be appreciated.

@Proct0t - that is not a fix - a single menu may contain multiple links pointing to the same path - BY DESIGN

The module is to solve the problem of finding the menu that is considered active when a single path is found in multiple menus, which is what we have determined to be the root of the problem, I thought... am I missing something?

Subscribing - had the same problem, fixes on #22 and #34 both work for me. Sticking with #34 for now, looking forward to a permanent solution. Thanks to you all for finding decent workarounds in the meantime!

Token issue:
#295177: Pathauto alias is not correct when using admin_menu

Since this cannot be fixed in admin_menu, and this issue is rather duplicate of the Token, Menu Breadcrumb, and Local menu issues, I would mark it duplicate normally, but sticking to fixed for now.

@sun - I'm curious to know what you think about having a module like the one I mention in #38 to fix this issue....

I took bensmiley's approach on #15 and added to it. I was running into the same issue with the login page as the user list page.

in place of

I put the following on line 276

Hi,
I can see there's some disagreement about the cause, and best approach to solving this issue.

I've been trying out things myself (with little luck), and also waiting to see a better direction before apply applying any proposed solution, because the problem showed up on the user login page and on the admin user list. But after seeing alexjhart's addition, and trying it -- I can say this works well for me.

Because of this I'm submitting a patch for his code (almost exactly, with a few escaped strings added). I'm adding a patch not because I think this is now completely solved, but it removes some of the most visible problems of admin_menu (for anon users and users with permission to administer other users) without seeming to break anything else -- and (for me anyway) a patch is helpful until there's a better solution... because I use admin_menu on every drupal installation.

Cheers :)
Scott

Attachment	Size
admin_menu_usr_counter.patch	2.31 KB

The other modules causing these problems have sloppy/wrong code. Please chase their maintainers. admin_menu's code is correct as is.

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

I too am having this problem, using todays dev snapshot. The patch in #45 did fix it, thanks. However, I also see the title "icon_users" on the user login page if I disable admin_menu.

As admin_menu isn't the cause for the trouble, is there a list of modules available that cause these problems?

@49: Have a look at comment #37. Those two are the most commonly cited cases.

I used #15 to patch my admin_menu and it works just fine - no 'icon_users' message or anyting like that.

Thanks

Post #27 worked for me!

I've had the same problem.
D6.6, Admin Menu 6.x-1.1, and I had Node Breadcrumb 6.x-1.0-beta2 installed.
After reading this thread I disabled Node Breadcrumb, and the problem has gone.
Many thanks, and hope this helps to add to the knowledge on the issue.

If you are using Menu Breadcrumb, check out this thread: http://drupal.org/node/303247 and try the patch listed on post #13.

It solved the problem on my Drupal 6.8 site.

I'm also having the same problem, but with Node Breadcrumb Module. Created an issue on their project page: #353519: Admin Menu Module Conflict - User Login Page

i was having the same issue between menu breadcrumb and admin menu. i used #22 above and that fixed the problem for me. i wish i had more time to dig into the meat of it, but i needed a quick fix and that did it.

thanks Proct0t

#22 worked for me, too. FYI.

#27 worked for me! Thanks!

Patch #27 from http://drupal.org/node/303247 worked for me too.

This seems to only be an issue with the Zen theme/subthemes. Is anyone else seeing this in any other themes?
#293154: Conflict between Zen and Admin Menu

I have several D6 sites I've encountered this with and I've done some pretty extensive testing...
The issue is not with Zen or with Admin_menu..... at least, not Admin_menu alone. It's a conflict with Admin_menu and various other modules - one thread tracks it back to something that really should be fixed in the D6 menu system sorry I lost track of that thread or I would link to it here.

In my case it's menu breadcrumb module. If I turn off menu_breadcrumb but leave admin_menu turned on, there is no issue - the user/login page when viewing anonymously prints the User Login title instead of the tag that prints when both Menu Breadcrumb and Admin Menu are turned on.

While the may or may not print in Garland (I am not sure) I do know that when Menu Breadcrumb is ON but Admin_menu is OFF then you see user_icon print instead of and this behavior is the same on Garland theme too.

Patch #27 worked for me. I am somewhat alarmed at the lack of progress on this module, however. Any way to find someone to co-maintain?

@m.rademacher: Obviously you failed to read the comment http://drupal.org/node/493236#comment-1708616. You applied the wrong patch for the wrong module and blame the wrong people for something wrong in some other wrong modules. Thanks.

@sun: Apologies for all the "wrongs" I committed. While I feel that your tone is unwarranted, I do admit my mistake. I accidentally post here instead of in the menu_breadcrumb thread. It was an innocent mistake, my problem is resolved (based on the patch in #27 from http://drupal.org/node/303247). However, I intended to ask if there was a way to help get a co-maintainer added to menu_breadcrumb, since the last update to the dev version was Feb 2009. This patch was originally posted in March 2009, and I was worried that this module (menu_breadcrumb, not admin_menu) is in danger of becoming abandoned, and I like it's functionality.

Again, I apologize for my mistake, I clicked reply in the wrong thread.

Post #27 worked for me as well, thanks for the fix. :)

#27 saved the day!

Attachment	Size
admin_menu.png	18.38 KB

None of the solutions above worked for me, but I had luck with this (adding a preprocess function):
http://thedrupalblog.com/resolving-page-title-issues-caused-menu-breadcr...

As a quick solution, I added some code to my theme template.php file in a preprocess_page function to replace the titles.

<?php
function MYTHEME_preprocess_page(&$variables) {
  if (stripos($variables['head_title'],'icon_users.png')) {
    $variables['head_title'] = 'User account | ' . variable_get('site_name', '');
  }
  if (stripos($variables['title'],'icon_users.png')) {
    $variables['title'] = 'User account';
  }
}
?>

I have this same problem using the node breadcrumb module 6.x-1.0-beta4. Because all the modules have been updated since you have published your fixes I am not sure which lines to change. I forgot to add, it only effects admin/user/user not the login page which is a good thing.

@adamsohn, see #353519: Admin Menu Module Conflict - User Login Page

Thanks, buddy. It worked like a charm :) Could you please fix all the other bugs in my system while you're at it?

Subscribe

Thx, solution in #15 works like needed

Just wanted to add that the original issue of this thread also happens with custom_breadcrumbs module. Turning off admin_menu makes the img markup go away but the text then still says "icon_users". Turning off nice_menus does not do anything in resolving this. Turning off custom_breadcrumbs makes this go away (but that's not an option for me). Does that make this an issue for custom_breadcrumbs and menu_breadcrumb?

This problem is gone with Admin Menu 6.x-3.0-alpha3 (which has problems of its own, one I know of is the "You do not have any administrative items." message at /admin, which is described here: http://drupal.org/node/511744)

Just for the record, I had the same issue in a foreign mywebsite. My workaround was to use the translation interface to translate the "@count-anon / @count-auth !icon" string into something else for my language.
I'll wait until the beta gets stable for the real fix.
Hope it helps someone.