user/[uid]/edit tab not present at user's visits tracker
Xano - May 17, 2008 - 19:25
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | user.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
If I'm at the visits tracker page (part of the Statistics module) of a certain user, the tab to edit that particular user has disappeard. When going to a user's contact or view page the edit tab is present again.
#1
I can confirm the bug, which lies in
user_menu()incorrectly using%user_categorywhere it should use%user.Bugs get fixed in the development version, then backported. Here is a patch for D7 that solves the issue. It also applies (with some benign fuzz) to D6.
#2
Looks good - applies to 7.x-dev with no problem (18 line offset), menu link to user/[uid]/edit shows up once update.php is run.
#3
works for me. patch applies cleanly with the above mentioned 18 line offset.
just out of curiosity, why does update.php need to be run in order to see the effect?
#4
Works for me. A quick visit to admin/build/modules rebuilds the menu cache also apparently to see the fix working.
#5
This one has really waited too long :)
Rerolled for D7, but applies to D6 too.
#6
Can confirm presence of the bug, and that the patch fixes it. I was concerned that changing %user_category to %user might make Profile module not work, but I didn't see any issues in a quick test.
Committed to HEAD, marking back to 6.x.
#7
Well, this was changed in http://drupal.org/node/111481#comment-639820 from %user to %user_current. I assume parent/child relationships work because the placeholders are treated equal for the matching (in ref to http://drupal.org/node/109134). It would still be good to double check this with chx/pwolanin, so we can make sure that inheritance, parent menu items, breadcrumbs, etc would still work.
#8
I need to investigate more - is this the same bug as #298722: _menu_translate returns FALSE before to_arg is available ?
#9
@pwolanin: those two bugs seem unrelated.
Today we have:
<?php$items['user/%user_category/edit'] = array(
'title' => 'Edit',
'page callback' => 'user_edit',
'page arguments' => array(1),
'access callback' => 'user_edit_access',
'access arguments' => array(1),
'type' => MENU_LOCAL_TASK,
'load arguments' => array('%map', '%index'),
'file' => 'user.pages.inc',
);
?>
On a tracker page, for example
user/3/track/navigation, user_category_load is called with the map (user, 3, track, navigation). It fails to identify 'navigation' as a category and returns FALSE. That's why the Edit tab is not displayed.#10
Peter, could you confirm the analysis in #9?
#11
I came across the same bug as Damien's #9 in #347250: Multiple load users (in my case it was passing the full map as the second argument to user_load().)
#12
@Damien - looks right - might be a simple fix.
#13
in D7, putting in an invalid category gives me a new fatal error:
[09-Feb-2009 11:36:00] PHP Fatal error: Unsupported operand types in /www/drupal-7/modules/field/field.attach.inc on line 172
#14
This avoids the fatal error at ?q=user/1/edit/foo for D7, and also permits the 'Edit' tab to appear while on a tracker sub-tab.
#15
for D6.
#16
With test for D7.
#17
Actually, the test should be with user module.
#18
1) There is some spacing issue: no space before setUp.
2) normal_user does not seem to be used.
#19
whitespace and code cleanup in the test.
#20
Dries and Damien suggest removing user_category_load. However, that will obliterate this optimization:
// Cache $account - this load function will get called for each profile tab.if (!isset($accounts[$uid])) {
$accounts[$uid] = user_load($uid);
}
in D7, user_load is still not cached
and also we use user_category_load to special-case category names that may contain a slash. TO move off this we will somehow have to update old ones that contain a slash via an update function. In short - we should not try to do this today in a rush.
#21
Peter, we can worry about the right fix later, if you insist. When we do, we could worry about the user_load() caching even later -- #281596: Performance: static caching of user objects in user_load(), respecting conditions and #91786: user_load() static caching might at some point take care of that. That might take some stress out of a proper solution. ;-)
#22
opened follow-up issue here: http://drupal.org/node/371763
#23
The D6 patch is running on d.o now. Clearly not perfect in the long run for D7, but fixes a critical bug now, adn any more complete fix will require significant refactoring of user module.
#24
The last submitted patch failed testing.
#25
Subscribing out of interest in seeing the related problem for Content Profile module fixed: http://drupal.org/node/419662
benjamin, Agaric Design Collective
#26
subscribing