Standard profile: make "Home" menu link to <front> editable/deletable

I think this generally makes a lot of sense, but since there is nothing dynamic in this link, I think the code should be moved to standard_install() instead.

ConfigImportAllTest::testInstallUninstall() already contains:

    // Delete any shortcuts so the shortcut module can be uninstalled.
    $shortcuts = Shortcut::loadMultiple();
    entity_delete_multiple('shortcut', array_keys($shortcuts));

so I guess we need to add similar code for menu links.

In general +1, that's exactly what I suggested we should do in #2710469: Move contact module footer link to standard install profile.

1. +++ b/core/modules/config/src/Tests/ConfigImportAllTest.php
   @@ -92,6 +93,10 @@ public function testInstallUninstall() {
    
   +    // Delete the home menu item so the standard profile can be uninstalled.
   +    $home = MenuLinkContent::loadMultiple();
   +    entity_delete_multiple('menu_link_content', array_keys($home));
   +
        system_list_reset();
   

   wait, what? we're testing that an the *install profile* can be uninstalled? Since when can we do that?

2. +++ b/core/profiles/standard/standard.install
   @@ -48,6 +49,14 @@ function standard_install() {
   +  $home = MenuLinkContent::create([
   +    'title' => 'Home',
   +    'link' => ['uri' => 'internal:/'],
   +    'menu_name' => 'main',
   +  ]);
   

   Home should use t(). Not sure about internal:/, but I guess that's correct here, using routes and so on is technically possible but again makes editing tricky.

1. No, it is definitely not the scope of this issue. titles in links.menu.yml files *are* translatable, that means you moving it to standard_install() makes it untranslatable and it was before.

Re @wmostrey, no the langcode should not be added, that will be automatically determined to be the default site language.

You just have to change
'Home'
into
t('Home')

Thanksy looks great. I have one more comment on this, do you mind re-rolling once more:

+++ b/core/modules/config/src/Tests/ConfigImportAllTest.php
@@ -92,6 +93,10 @@ public function testInstallUninstall() {
+    $home = MenuLinkContent::loadMultiple();
+    entity_delete_multiple('menu_link_content', array_keys($home));

The only quibble I have with this is the variable name $home for something that is an *array* of menu links. Can we name it $menu_links instead?

Not sure if we then want to update the comment above it as well (i.e. "Delete any menu links" instead of "Delete the home menu item"), but I think a better variable name would make it sufficiently clear either way.

Thanks for sticking with this, looks great to me now!

+++ b/core/modules/config/src/Tests/ConfigImportAllTest.php
@@ -92,6 +93,10 @@ public function testInstallUninstall() {
 
+    // Delete any menu links so the standard profile can be uninstalled.
+    $menu_links = MenuLinkContent::loadMultiple();
+    entity_delete_multiple('menu_link_content', array_keys($menu_links));
+
     system_list_reset();
     $all_modules = system_rebuild_module_data();
 

This comment is wrong, only noticed now why that confusd me so before.

install profiles can not be uninstalled and we are not doing that.

*but*, menu_link_content is and can be uninstalled. And that's what's not possible without deleting them.

See preUninstallForum() and how it is called, I think we should use the same pattern.

Actually a bit surprised why shortcut doesn't need this, we also create shortcut entities in standard? How is this even related to standard_install(), this test isn't based on standard?

something is wrong here..

If the code is needed then in a preUninstallMenuLinkContent().

But see the second part, I do not understand why it is necessary at all. The forum part is necessary because forum_install() itself creates the menu link. But standard_install() never runs as part of that test, or we'd have exactly the same problem for shortcuts too?

Sorry I misread that. We do delete shortcuts above that. The only thing that's not correct is the comment, which should say so the menu_link_content module can be uninstalled.

Thanks, sorry again for the confusion on my side :)

This needs an upgrade path - without one existing standard installs will lose their home link :)

As commented in the drupal answers questions, I don't think anything like that will work because your hook won't exist until a cache clear, and then the menu cache is gone already.

But a cache is just a cache, we *never* store something only in cache. IIRC, we store the information on whether a menu link was enabled and its exact overriden configuration in... configuration. See \Drupal\Core\Menu\StaticMenuLinkOverrides,

+++ b/core/profiles/standard/standard.install
@@ -72,3 +81,42 @@ function standard_install() {
+  $cache = \Drupal::cache('menu');
+  $cache->deleteAll();

Why do you create a cache and then you delete it?

Thanks for opening that bug report. Very interesting that that doesn't work. So should this be postponed on that then?

The alternative would be that we use \Drupal::configFactory()->getEditable('core.menu.static_menu_link_overrides') to load the override config directly and modify it. Have you tried that?

Not on IRC today unfortunately, I might take a look at this later, though.

Hi.

How did you get on with this patch? Is it live?

I'm having a huge problem getting rid of such a menu item. If I try to edit the menu item, I'm told "This link is provided by the Standard module. The title and path cannot be edited". I removed the entry from the database, but when I clear the caches, it comes back!

Most suggested workarounds didn't work to get rid of it. Although, maybe I didn't execute the workarounds correctly.

I'm open to helping, although I've only been using Drupal for about 2 weeks, if that.

Thanks for looking into a fix :) Appreciated :)

I've added an issue report here: https://www.drupal.org/node/2859921#comment-11982233

I gave my input as a noob (< 2 weeks on Drupal). A better warning message might also be a good idea, especially to help us noobs on our way.

Thanks again for all your hard work :)

Rerolled the patch and change short array

Pavan B S, your patch is getting applied but I cannot see any changes with the warning, it still shows the same message *This link is provided by the Standard module. The title and path cannot be edited.*. Please describe the working of your patch too. Thanks for the re-roll.

+++ b/core/profiles/standard/standard.install
@@ -72,3 +81,42 @@ function standard_install() {
+  try {
+    $home_current = $home_manager->getDefinition('standard.front_page');
+    // Menu item standard.front_page has been altered, let's use those options
+    $home_new = MenuLinkContent::create(array(
+      'title' => t('Home'),
+      'link' => ['uri' => 'internal:/'],
+      'menu_name' => 'main',
+      'weight' => $home_current['weight'],
+      'enabled' => $home_current['enabled'],
+    ));
+    $home_new->save();
+    // Disable standard.front_page since it can't be deleted
+    if ($home_current['enabled']) {
+      $home_current['enabled'] = 0;
+      $home_manager->updateDefinition('standard.front_page', $home_current);
+    }
+  }

We would need to take into account that someone might have moved the link around or renamed it.

It could have been moved to a different place though.

Is there any issue, I am not aware of, we can relate to from here where this behavior has been caused in the development of Drupal 8 before? In Drupal 7 the only reason for not editable links were reasonably caused by menu links created by views pages (configuration prioirity weight). I think we first should track down where this decision has been made (*facepalm*) and why/where this is coming from, before we override it and wake up with another bad decision surprisingly.

<OFFTOPIC>
Do we have a WTF tag?
I can't even believe that this issue exists ...
</OFFTOPIC>

This issue is about fixing the home link in the standard profile. We should let that fix go in. That said, i'm with those saying we (also) need a general solution for this.

The problem is that module-provided (or install profile provided) menu links cannot have their titles edited, and this is unconscionably annoying. Yet the solution here is to make one link *not* be directly code-defined.

I got here looking for a way to let site administrators edit the name of the menu link that Give module provides. As a maintainer of the module I could simply give people another field in the configuration of the module, but making module-provided menu items have easily overridable, translatable titles is a common need that should have a fix in Drupal core.

Has this been resolved or altered in Drupal 8 version 4. As I accidentally deleted my initial home page and now am unable to get around this useless home menu link in my Drupal install. I know that best way is to reinstall Drupal, but maybe there we can make it customizable in the future Drupal version this way no patch is required. Would love your insight.

Thanks.

@romreactor: first things first: this issue here is a bug report, and the issue queue as a whole is a community driven issue tracker wtih support from community members (like you and me) and some companies who sponsor core and contrib development in different ways. I know you know that, but the way you ask "if it is solved" indicates that you maybe do not know how it reads what you ask for. Contribute: If you want to know if it is solved but not reported here, you should install a test project, try around with it, read the issue queue, check the latest comments, follow the latest commits and if you find out the rare case that it is solved but not reported here, you should contribute to this issue by commenting here helpful info about your tests and that some reports are missing. Or you can look into the patch in if there is anything you can help with. Many WTF issues are caused by good reasons not easy to work around, as you will find out soon.

Now to your "support request": Reinstalling Drupal is not required in your case. "To get around" your useless menu link, simply deactivate it and make a new one. Custom menu links are more flexible anyway. If your "frontpage" content is missing, check admin/structure/views if there is still a frontpage view. If not, create a new one. This is the power of Drupal. :) Greetings.

There's now a patch for the general solution: #2916639 Which is wonderful!

Still in favor of this issue also, and its patch, which simply makes the menu link not 'machine provided' when it doesn't have any reason to be.

Should this be a bug report instead of a task? It's a little silly that the title isn't editable.

I gotta +1 this and love that this has the #DrupalWTF tag. I couldn't believe I was even having to search for such a thing as to why the "Standard module" (whatever that is, since it's really an install profile) won't let me delete this link. OK, sure, most sites have a Home menu link, but not being able to remove or edit it really threw me. Not that disabling it is a difficult or ineffective alternative but really a DrupalWTF moment for me.

The patch provided in #2838106-47: Standard profile: make "Home" menu link to <front> editable/deletable doesn't work for Drupal 9.4.
Used it to create a patch for Drupal 9.4

Taking care of the findings of the failed test findings of #2838106-71: Standard profile: make "Home" menu link to <front> editable/deletable

Taking care of the findings of the failed test findings of #2838106-72: Standard profile: make "Home" menu link to <front> editable/deletable

+1 on #DrupalWTF. I can't believe I'm encountering this problem with Drupal 10 in 2023, even if it is a minor issue overall. I either have to hack some code to remove it or tell my clients "just ignore that" because it's an immovable object - no one knows how or why it exists but we know you can't change anything about it!