Posted by j0rd on June 23, 2011 at 11:34am
45 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | menu system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | d7wtf, needs backport to D7 |
Issue Summary
In D7, whenever I go into Administration » Structure » Menus
The menu item for My account always shows "My account (disabled)"Tried clicking the "ENABLED" check box and save, it will say changes saved but the check box will revert to being unchecked.
Why is it always disabled? Although the My account menu item does still appear under the user menu block when viewed in front end.
Thanks.
This has been going on since March 15, 2011 and it still appears in latest release of Drupal. I was unable to find another issue queue with this issue.
Comments
#1
+1
#2
The bug is not that saving it has no effect, but that it is not shown in the correct state.
During construction of the form, user.module modifies the "User/My account" link to be hidden for anonymous users AND when administrators editing the menu - by calling the suspiciously named user_is_anonymous(). In this case, it should be checking for real anonymous users only.
Here's a patch that checks for anonymous users directly. My only reservation is that drupal_valid_path() also calls _menu_link_translate() which ends up calling the same code - so this change could impact there.
#3
I had the same problem.
The 'My Account' link was working originally, then after building other user menu items (login/register) it disappeared.
After not being able to figure it out, I just tried hitting 'Reset' to the right of the menu item and it re-appeared!
Definitely buggy... Every time I mess with that menu it disappears again!
Hope this helps others, for now...
EDIT: I've figured out that it's when I move the 'My Account' link up or down that it gets rid of it and when I reset it, it sits under 'Log Out', which is annoying, as I want it above it!
#4
This is a really annoying problem, any fixes?
#5
The patch in #2 will probably fix it for you.
#6
Fix in #2 works as advertised.
I'm raising the priority to major - the patch may be tiny, but the problem it solves is a huge WTF for site administrators.
#7
I'm not sure this actually qualifies as major (confusing though it may be); it does not have "significant repercussions."
I think this is still NR for three reasons:
<?phpfunction user_is_anonymous() {
// Menu administrators can see items for anonymous when administering.
return !$GLOBALS['user']->uid || !empty($GLOBALS['menu_admin']);
}
?>
The comment explicitly states that it's supposed to make menu items for anonymous visible to administrators. This is questionable to say the least, as @lyricnz points out.
I am wondering if we should not perhaps target the "my account" link specifically, rather than making a broad change. Maybe the whole pattern should get re-thunk for D8 and we can backport some small, specific fix to alleviate the confusion in D7.
Edit: reorganized comment for readability.
#8
#9
Also, bugfixes need to go against D8 first to prevent regressions.
#10
tagging for backport.
#11
+1
#12
+1
#13
"Needs work" is more appropriate, given the concerns in #7.
#14
+1
#15
Subscribe
#16
+1
#17
Why target 1 link specifically instead of just solving the issue by either the above patch or going back to the drawing board on how drupal handles links like these. This issue has been reported happening with other modules, too, so a new way for drupal to look at links like this would be the best path, imo.
#18
A solution could be to use the above patch, and then add another column to the menu administration table that has role viewing/use permissions listed.
#19
+1
#20
@Martin Mayer: "+1" or "subscribe" posts are no longer necessary. Use the follow button on the top right of the page. If you want to openly express your support for this issue, please do so by reviewing and testing patches or contributing code.
#21
[Stock response from Dreditor templates and macros.]
This is similar to:
#308263: Allow privileged users to bypass the validation of menu items
#1337546: Cannot reorder 'User Menu' items for user/register user/login as these are not accessible by admin
#22
subscribe
#23
@my-family: You don't need to post "subscribe" comments any more. There is a green "Follow" button in the upper right corner of issues that you can use instead.
#24
To work around this without patching, you can try creating a custom "My account" menu item pointing to
userand use Menu item visibility to only show the menu item to authenticated users. Worked for me.#25
Thanks for this @Cottser - worked great for me and I've reposted your workaround on the related forum page.
I do think this (and others around "My account") are very visible and confusing little bugs though, unfortunately present right out of the box in D7; if possible we could really do with a quick patch-up there.
#26
This should be testable.
#27
yktdan should get credit on this patch.
#28
Isn't that identical patch that was originally posted here? (but tests are good)
#29
@lyricnz, yes, yktdan and I just worked on the tests together at NYC Camp. It was definitely your patch. I just meant that he should ALSO get credit, even though I uploaded the file.
#30
I wasn't fishing for credits :) I was asking if xjm's concerns had been suitably addressed?
#31
Haha sorry I misunderstood.
I don't think there's anything particularly wrong with using a global like that, and I think fixing user_is_anonymous is a bit out of scope for this very clearly reproducible bug.
#32
Agree that changing user_is_anonymous() is a bit risky, so our original proposal is OK. Even the existing comment in user_translated_menu_link_alter() describes the correct behaviour 'Hide the "User account" link for anonymous users'!
Do you think it's worth describing this special case in the UI? (adding 'logged in users only' next to the /user link)?
PS: There's an unused variable $title in _menu_overview_tree_form() - but I've left it intact to minimize the patch
#33
Arguably, that UI change could be a separate patch. Happy to RTBC the functional change, and submit the UI change as a new issue.
#34
#32 should be a follow-up, #27 should be RTBC.
#35
Agree - created #1698586: Show a message about "My Account" menu link not being shown to anonymous users
#36
Agreed about splititng off #32. Can we also get a followup for the
user_is_anonymous()weirdness? I'd be okay with this being RTBC if we have a followup for that linked here.#37
There was already #327230: user_is_anonymous() is ugly. Great title.
#38
Updated for #1380958: Replace $modules list for WebTestBase::setUp() with ::$modules class properties (plus a cleanup for the class docblock).
#39
Botched the test-only patch.
#40
It's incredible that this bug is still there after 7.15 update!
#41
It would be more incredible had it not been there, since this hasn't been committed yet.
Interdiff looks good.
#42
Looks like a solid bug fix, and includes tests. Thanks!
Committed and pushed to 8.x, marking for 7.x backport.
#43
Here's a backport for D7.
The only thing to note: the test was updated to look for
<ul id="secondary-menu-links">instead of<ul id="secondary-menu">.#44
#43: 1197622-43.patch queued for re-testing.
#45
Works great. Let's put this WTF to bed.
#46
Seems to match the 8.x patch. :)
Committed and pushed to 7.x. Thanks!
#47
Automatically closed -- issue fixed for 2 weeks with no activity.