Profile link in logged-in block is dependant on 'access user profiles' permission.

i use theme_username to generate that link, which is a standard drupal core theme call. if you're not happy with how it works, you'll need to file an issue against drupal core.

How about this for a patch?

The reason you don't get a link unless the administer users permission exists is because we are trying to get the themed username for an arbitrary user, where it just happens to be the currently logged in user.

One way to solve that would be to patch core to make an exception when a user tries to access their own username as a (linked) HTML entity.

But another way is for Login Toboggan not to link to /user/[uid], but simply to link to /user, putting the username as the content of the anchor.

Hence this patch. (check_plain is needed because the format_username returns the raw username)

A slightly different approach, which still invokes the protections offered by template_preprocess_username(). All you need to do is patch theme_lt_loggedinblock() to add a link_attributes and link_path to the array that is passed to theme_username.

I have profile2 installed, so YMMV in terms of the name of the permission in user_access(), but this override in my template.php works like a charm

/**
 * Override the default LoginTobbogan user block so that users get links to their own profiles
 * (Drupal's template_preprocess_username only adds a link for users who may see ALL profiles)
 */
function MYTHEME_lt_loggedinblock($variables){
  $account = $variables['account'];
  $theme_data = array('account' => $account);
  if ( (int) $account->uid && user_access('view own main profile') ) {
    //copying code from template_preprocess_username()
    $theme_data['link_attributes'] = array('title' => t('View user profile.'));
    $theme_data['link_path'] = 'user/' . $account->uid;
  }
  return theme('username', $theme_data) .' | ' . l(t('Log out'), 'user/logout');
}

But surely this shouldn't have to be done at the theme level. The module should output a valid link at this point whatever the theme, and the patch that's at RTBC establishes that.

I understand that the maintainers don't want to progress feature-requests, but I wonder if either of them would like to commit this bug-fix patch now it's RTBC?

Finally committed! I agree with the point at #6 so have committed as is.

Thanks, Steve

This is a very old thread, and I should have responded to comment #6 when it came in (I don't know why I missed it). But I think this is a mistake. The reality is that Drupal core is doing some stuff in the theming layer that this patch now bypasses. So whether it's silly to do that in the theming layer or not, the fact is that that is where it happens for Drupal core.

The code in template_preprocess_username() that is bypassed by this patch includes:

$name = $variables['name_raw'] = format_username($account);
  if (drupal_strlen($name) > 20) {
    $name = drupal_substr($name, 0, 15) . '...';
  }
  $variables['name'] = check_plain($name);

and, this:

// We do not want the l() function to check_plain() a second time.
  $variables['link_options']['html'] = TRUE;
  // Set a default class.
  $variables['attributes_array'] = array('class' => array('username'));

That seems like a mistake: among other things, the loss of the "username" class may break styling on existing sites.

I understand the problems you highlight. But, surely, whatever the correct solution is, someone should be able to install

• vanilla Drupal 7
• Login Toboggan
• Bartik

and the block should work correctly.

The patch as committed may have undesired side-effects in the block. But, in the absence of a change to core (which seems unlikely this late in the lifecycle of Drupal 7), we need an alternative patch against this module alone that will solve the problem.

I'm not proposing a change to core, I'm proposing a different change to theme_lt_loggedinblock(). I apologize for not supplying a patch, and will try to do so later today, but the code is posted above.

OK, thanks. I misunderstood. I thought you were suggesting a template change at the theme level, rather than a patch for the module.

Here's the promised patch.