User pages display incorrect title instead of "Menu link title" when link paths are added to a default menus

I can confirm this bug on a clean install of 7.22.

Set to needs review.

Please test it out. Clear caches after installing the patch.

I can confirm this is an issue (my issue was on the log in page). From the looks of it your patch will fix the problem, however I don't know if it is necessarily the correct solution. I have not tested this, but I wonder if this would happen with other module generated menu items getting defined in a menu from the D7 admin section?

Can we confirm that this is limited just to the user account pages? I can see that these pages are the most likely to be noticed since many sites need login/register links, but was this always an issue in D7 or was this introduced by some recent commit... perhaps something with how the menu system is handled?

To get an idea of when the issue began, I spun up new sites with the oldest version simplytest.me supports, 7.12, and was able to recreate the issue by adding links to the "User menu" for the paths user/register and user/login. When I then visit either of those paths in another browser window as an anonymous user, the page title shows up as "Home". I then tested the latest 7.x dev release and confirmed that the issue persists.

In the 7.x dev release, I also tested adding the paths user/password and user to the "User menu" and both of those then show the wrong title. The user/password shows up as "Home" like the rest, but the user path then shows the title as whatever you enter as the "Menu link title" for that menu item.

I'm marking the issue "Needs work" since the patch appears to only address the forms for user/register and user/password, but not user/login or user.

I also tested the latest 8.x dev release, but was unable to recreate the issue there.

Here's an updated patch that also corrects the user/login or user page titles.

Does this warrant the addition of some tests for the issue?

I just ran into this problem and the #8 patch fixed it for me. Thanks!

I'm attaching an updated patch that incorporates feedback I got from chx on IRC, along with some updates to the Menu > Breadcrumbs tests.

Normally this would need to get fixed in Drupal 8 first and then backported. But in this case, I verified that the issue does not exist in Drupal 8.

Wow, I didn't even notice that for 2 weeks and I was about to go live! :/

I did some more tests and found that the page titles change to "Home" when I add them to any of the built-in menus, not just the User menu.

It is likely that this isn't an issue in D8 because all the routing has been changed to symphony components.

Works for me, I wouldn't say that I did a huge amount of testing though.
+1

I'm so glad to have found this issue. I thought I was going mad. I now realise that this appears to have happened on most of my sites. I usually put a menu link for "log in" in my secondary menu, and it seems to make the title of the page "Home" for user/login and "My account" for user.

I'm not sure about the patch. Sure, manually overriding the title will fix it, but isn't this a deeper Drupal problem? I've experienced it before with my own local tasks having the wrong title, and in that case I also solved it using drupal_set_title() in the page callback. I spent hours trying to work out where they were getting 'Home' from, but seeing it happen to Drupal core as well explains a lot.

I've tracked down the problem to menu_get_active_title() in includes/menu.inc:

/**
 * Gets the title of the current page, as determined by the active trail.
 */
function menu_get_active_title() {
  $active_trail = menu_get_active_trail();

  foreach (array_reverse($active_trail) as $item) {
    if (!(bool) ($item['type'] & MENU_IS_LOCAL_TASK)) {
      return $item['title'];
    }
  }
}

If you don't have user/login in the menu, then it will use the title of the user menu link (which is automatically created for you with a title of 'User account'. If you add user/login to the same menu (i.e. as a root element), then the active trail will be:

Home > Log in

The array gets reversed, so it finds 'Log in' first, but it fails the bitmask check, so moves on to 'Home', which is then set as the title.

There is something fishy about this logic in my opinion. It should be determining the title of the page from the information in hook_menu(), not from the custom menu links. I might put a link to it in any menu, it doesn't mean I want to change the title of the page to the parent of the menu link.

According to user.module's hook_menu():

$items['user'] = array(
  'title' => 'User account',
  'title callback' => 'user_menu_title',
  'page callback' => 'user_page',
  'access callback' => TRUE,
  'file' => 'user.pages.inc',
  'weight' => -10,
  'menu_name' => 'user-menu',
);

$items['user/login'] = array(
  'title' => 'Log in',
  'access callback' => 'user_is_anonymous',
  'type' => MENU_DEFAULT_LOCAL_TASK,

As such, I would expect the title of the page to be either 'User account' or 'Log in'. Or is it a requirement to always use drupal_set_title() on a MENU_LOCAL_TASK? Either way, I don't think it should get the title of the page from a menu link that a user adds.

I hope somebody with more knowledge of the Drupal menu system can shed some light on this.

+1 This is a bug.

My custom module has titles set in hook menu. User adds a menu item in the main menu for one of the hook_menu paths. Now the page title is not the title defined in the menu hook or the menu item. It is the title of the *parent* menu item. Very confusing.

Here is a bit more on what causes this problem. I have hook_menu items with such as 'license', 'license/history', and 'license/purchase'. Each generates a different page and has a different title in hook menu. If the user creates a menu item for 'license/history', the router_path in the menu_links table is set to 'license' instead of 'license/history'. This causes the page to use the title of the 'license' page and also makes the breadcrumb wrong. As a quick work-around, I change the router_path to be the same as the link_path in the database and refreshed the cache.

I'm not wild about either patching core or fixing this manually by altering the database. Drupal_set_title in a page preprocess function fixes the h1 but not the tag in the page head. So here's the workaround I came up with. Pretty hacky.

// Save overrides in a single lookup function to keep them easy to maintain
function mytheme_brute_force_title($request_path)
{
  $titles = array(
    'user/register' => t('Join'),
    'user/login' => t('Log in'),
  );

  return $titles[$request_path];
}

// Fix the <title> tag
function mytheme_preprocess_html(&$vars)
{
  if ( $title = mytheme_brute_force_title(request_path()) )
  {
    $vars['head_title'] = $title;
  }
}

// Fix the h1 on the page
function mytheme_preprocess_page(&$vars)
{
  if ( $title = mytheme_brute_force_title(request_path()) )
  {
    drupal_set_title($title);
    unset($vars['title']);
  }
}

This had me going on for hours! Matt V.'s comment #13 gave me a clue and indeed I added user/login in the Main Menu. After I deleted it and used a non core created menu the user, user/login, user/register and user/password doesn't destroy the page title.

The original post mentions that pages like user/login also have problems but I'm not seeing anything related to that in the patches, they all say "User account".

Shouldn't we also be setting "Create new account", "Log in" and "Request new password" titles on those pages so that they don't say "Home"?

changing title according to OP's issue and #13

will test patch #11.. and post back

I am not a developer so I can't help here even if I would like to.

But I know this bug is serious. It impacts the user experience of every user (registered or wannabe) of your site, and your anonymous traffic (cause of the worse SEO).

Is this enough to ask for some attention and a commit, please?
(shouldn't this be "major"?)

I doubt it will be fixed. The real problem is with what the menu system itself is doing, which doesn't make logical sense. The trouble is that the Drupal menu system is such a "here be dragons" mess that only a few people really understand the strange things it does in detail, and they will only be working on Drupal 8.

The other problem is that many sites and modules might be relying on the (in my opinion broken logic) to set the title to the parent menu link item. If it gets fixed it could break any sites that expect the current functionality.

The best we can hope for is a band-aid solution (manually setting the title for the user account pages, since that is where most people experience it). And then any time it happens somewhere else, people will have to manually force titles to prevent them from incorrectly inheriting from "Home".

I don't think the workaround is a good idea here. It would clobber any custom page titles that individual sites are using for these pages.

Why can't we just fix this problem directly? We know that it doesn't make sense to have the front page "Home" link used as the default page title here (since the home page doesn't have tabs) so we should be able to just catch that case and deal with it. See the attached patch, which looks like a pretty simple fix to me. Can anyone think of anything that would be broken by this?

There is something fishy about this logic in my opinion. It should be determining the title of the page from the information in hook_menu(), not from the custom menu links. I might put a link to it in any menu, it doesn't mean I want to change the title of the page to the parent of the menu link.

That is true, but the flip side is that there is no other way to change the page title via the user interface for many pages, right? And in many situations, including I think the most basic cases, you do want the menu link title and page title to be the exact same thing.

So I think the current behavior makes logical sense in most situations, but in situations where it's not what you want I agree it's pretty confusing. There are ways to change this behavior (see menu_link_get_preferred()) and I think some contrib modules might do that. It's not something where we could change the default behavior in Drupal 7 core at this point (as it's the expected behavior on many sites), but we could look at ways to make it more flexible if necessary.

However, I feel like that's a separate issue from this one. The real bug here is that "Home" is being used as the page title, which obviously is the wrong behavior (and using the menu link title would pretty much always be preferable to that).

Whao, I searched for more than four hours to find out the reason for this weird behaviour and my colleague finally found this issue (many many thanks to @thomas.frobieter you saved my (working-)day)

Thank you all for discussing this strange problem. We should really set the priority up for this issue I think. "Normal" Drupal users will get crazy when this missbehaviour happens.

I've testend the patched from above and I clearly vote for #26 because THAT solutions is robust and makes a lot of sense.
Furthermore we should add testcases if possible to ensure that problem will never appear again.

Based on Anybody's statements.

The problem still exits and #26 works in production on several sites for me. Can we get some more feedback to get this RTBC?

I'd create a test case for that but I'd need some help how to create that correctly for core. We should fix this asap, it's really a mad bug.
RTBC from my side.

#26 works for me.
Thanks for the patch.

I think this component is more accurate.

This test needs improving by someone who understands the problem better.

Patch #33 (built on #26) works great, we're using it in production since month and it fixes this absolutely major BUG. RTBC if you agree. We really need to get this fixed. Confirming #31.

How can we proceed here? The issue is quite old and a core maintainer should have a look and add it to the next release please.

In my experience saying what people should do doesn't get you far.

It was mentioned in #33 that the tests need work. Can you confirm that the tests in #33 are acceptable?

The fact that the test fails without the patch and manual testing shows it is fixed are good evidence this is probably ok.

@Anybody, I would follow these steps to make sure this issue is clear without needing to read every comment.

Then I would follow these steps.
https://www.drupal.org/node/73178

All of these links can be found in the drupal.org doc page on using the issue queue.

[edit] added attribution
[edit] tokens didn't work

Just tested the changes in a 7.39 installation and running multiple sites in production since month. Works great with the patch and bad without.

@Anybody, do you mean that you ran the simpletests or that you installed it and it looks good?

Patch number 33 is now passing tests. I've applied this manually, and it works.

Committed to 7.x - thanks!

Fixed the following on commit. I thought about removing the link to this issue too (we normally don't do that) but in this case it's probably pretty hard to figure out what's going on from reading the test alone, so the link could be more helpful than usual:

diff --git a/modules/menu/menu.test b/modules/menu/menu.test
index e012fd4..8e69efe 100644
--- a/modules/menu/menu.test
+++ b/modules/menu/menu.test
@@ -73,8 +73,8 @@ class MenuTestCase extends DrupalWebTestCase {
     $this->assertEqual($description, $saved_item['options']['attributes']['title'], 'Saving an existing link updates the description (title attribute)');
     $this->resetMenuLink($item, $old_title);
 
-    // Test for the correct behavior of a menu link title.
-    // @see https://www.drupal.org/node/1973262
+    // Test that the page title is correct when a local task appears in a
+    // top-level menu item. See https://www.drupal.org/node/1973262.
     $item = $this->addMenuLink(0, 'user/register', 'user-menu');
     $this->drupalGet('user/password');
     $this->assertNoTitle('Home | Drupal');