user/[uid]/edit tab not present at user's visits tracker

I can confirm the bug, which lies in user_menu() incorrectly using %user_category where 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.

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.

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?

Works for me. A quick visit to admin/build/modules rebuilds the menu cache also apparently to see the fix working.

This one has really waited too long :)

Rerolled for D7, but applies to D6 too.

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.

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.

I need to investigate more - is this the same bug as #298722: _menu_translate returns FALSE before to_arg is available ?

@pwolanin: those two bugs seem unrelated.

Today we have:

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

Peter, could you confirm the analysis in #9?

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

@Damien - looks right - might be a simple fix.

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

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.

for D6.

With test for D7.

Actually, the test should be with user module.

1) There is some spacing issue: no space before setUp.

2) normal_user does not seem to be used.

whitespace and code cleanup in the test.

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.

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

opened follow-up issue here: http://drupal.org/node/371763

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.

Subscribing out of interest in seeing the related problem for Content Profile module fixed: http://drupal.org/node/419662

^{benjamin, Agaric Design Collective}

subscribing

subscribing

I can't reproduce this bug anymore in HEAD. It's still an issue for D6 though. We need to review the patch in #15.

Peter's patch in #15 works for D6, and as noted in #23 is already running on d.o.

thank you for the great work

subscribing

Confirming #15 also fixes Invite module local tasks for D6. Hence, marked #587632: Edit Profile-Track Invitations-for some links > Pending,Expired, new Invitation does not shows Edit Account tab as a duplicate of this issue.

tested it - thanks for the great work
any chance of commit into drupal 6?

Thanks for the testing, committed #15.