"My account" used across site although "User account" is shown for Menu link title and Path

We fix issues in the dev version first and backport. Can someone confirm if this is an issue in 8.x?

Hey, first comment ever: I've tested this in Drupal 8 and the problem appears there, too. I tried to change the menu link title to words like "Fishes", "Cats" etc. and it worked. When I tried to change it to "User account", it showed up as "My account"...

Sidenote: On "admin/structure/menu/manage/user-menu", the menu link shows up as "My account", if you click on edit, it shows, the menu link title is "User account"... I also didn't have to enable this menu link, it already was.

tagging novice to make the links use consistant name

For anyone looking for a quick fix, here's a patch. Aside from fixing the bug, this also changes and removes a couple of tests that were explicitly checking for 'My account' text. This is just a quick fix though, I'm still investigating why 'User account' triggers a different callback from anything else.

I would use:
$link_title = db_query("SELECT link_title from menu_links where link_path='user'")->fetchField();

and then:
':text' => $link_title,

Thanks for the suggestion dudycz, that's a much better way to do it. Except that ':text' will cause it to run through drupal_placeholder(), wrapping it in an em tag. Let's use '@text' instead to ensure the text is HTML escaped.

I did some more digging and found that user_menu_title() is ultimately called by _menu_item_localize(), which tries to pass the title as an argument. We can just tell user_menu_title() to take an argument called $link_title and we don't have to query the DB at all. Also, there's no need for the else, so let's remove it and just return the translated title.

This patch addresses those issues and also fixes some more tests that were explicitly looking for 'My account.' I also found these places in core that make reference to 'My account.'

core/modules/contact/contact.module:22
core/modules/language/language.module:22
core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php:159
core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php:200
core/modules/openid/openid.module:796
core/modules/openid/openid.module:799

this could use an issue summary update to clarify the solution. tagging.

@YesCT, I updated the issue summary. I haven't done too many issue summaries before. I'd appreciate some feedback to know that I'm doing them correctly.

Also, I'm working on a new patch to address the failing test in #8.

Fixes the failing test in #8 where the SearchConfigSettingsFormTest was checking that the text 'User' was not anywhere on the /search page.

@dags the motivation and proposed solution sections are an improvement. The list of the tests to fix in the remaining tasks section is helpful.

I think a simple steps to reproduce section could be added. (using what was originally in the issue as a starting point). use an ordered list for that, and start with "install".

I'm still a bit confused... this patch is fixing the fact that the link can be changed to Fish, or anything, except for User Account?
So after this patch, the link can be set to be User Account?

The issue summary needs a api changes and user interface changes section.
This issue has both I think.

the UI changes section is a good place to put screenshots of before the patch (with User Account showing as My Account) and after the patch (with User Account showing as User Account).

revise summary

Woops.. was trying to update the summary and accidentally posted it in a comment.. thus why these images are attached here.

add before after screens, steps to reproduce, more info about bug.

I read through the patch, it looks ok standards-wise.
The testbot is green.
The issue summary explanations and screenshots help clarify it.

rtbc.

#12: account-menu-links-1634916-13.patch queued for re-testing.

Let's add a test case that explicitly tests both the default and non-default values for the link text (i.e. test the default value, update it through a drupalPost(), and test the new value).

Here are some tests. I kinda get the feeling that I should clean up the the naming and phrasing of variables and messages.. let me know if anyone else gets that feeling too.

Looks like the tests aren't actually failing - just throwing couple of PHP notices because of a core bug that's been hanging around for a while. See these issues:
#876580: drupal_valid_path fails for dynamic paths (e.g. user/% cannot be added to menus)
#190867: Remove access check for anonymous users when creating aliases

@dags
The tests-only patch is failing really, right?

And the related issues are related to the purpose of this issue, not the "core bug that's been hanging around for a while", right?

Are the exceptions on the patch:

Drupal\user\Tests\UserAccountLinksTests	72	0	2
Message	Group	Filename	Line	Function	Status
Undefined variable: form_item	Notice	path.inc	208	drupal_valid_path()	
Undefined variable: form_item	Notice	path.inc	209	drupal_valid_path()

similar to what I was seeing:
Undefined index: name
in: #1498674-185: Refactor node properties to multilingual?
Is there an issue for that? Or a workaround, so we can get the bot to show the patch as green? Maybe we just submit for a retest?

@YesCT I think we need #876580: drupal_valid_path fails for dynamic paths (e.g. user/% cannot be added to menus) to get in to be fixed before these tests will pass. I imagine this will need a reroll too.

adjust spacing

Let's allow others to work on this.

Tested on Drupal 9.3.x, standard install and was not able to reproduce the problem. The title is always 'My account'. Plus there was change in #2301313: MenuLinkNG part3 (no conversions): MenuLinkContent UI to display a message that the title and path of the link cannot be edited.

Still applies to Drupal 7.80, changing version.