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.

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?

I'm thinking about doing something like this, upon first cache clear. If the 'standard.front_page' menu item still exists in cache, take its settings (weight and enabled) and create the dynamic link. When the cache clear is ready, the 'standard.front_page' menu item has ceased to exist.

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,

I implemented an interesting idea by borisson_: leave the standard.links.menu.yml be. So we create a new dynamic "Home" link with the weight and status of the static one, and we simply disable the static "Home" link.

The problem is that on a new install, you have two "Home" links: one enabled dynamic link, and one disabled status link. I'm not quite sure how to proceed from here, input is welcome.

2. Static Home menu item was altered (by disabling/enabling it or changing weight). After deleting standard.links.menu.yml and clearing cache, the static Home menu item is still there. Let's use its values for our new dynamic menu item, and disable the static menu item since we can't delete it.

The only alternative is that, if someone changed the static menu item, to let the now orphaned menu item exist in a disabled state. That leaves us with a disable menu item that has a "reset" option that results in a fatal error. And seeing that the original intent of this issue was to make things more user friendly, I don't think that's an option.

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

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.

Hi @CatsFromStonehenge, thank you for your input. The solution we're aiming for is not to make a better warning message but to make the Home menu item editable/deletable just like any other menu item. We're still working on this though.

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.

diqidoqCreditAttribution: diqidoq as a volunteer commented 22 April 2017 at 12:51

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>

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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.

romreactorCreditAttribution: romreactor as a volunteer commented 16 October 2017 at 19:58

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.

diqidoqCreditAttribution: diqidoq as a volunteer and at MAROQQO commented 17 October 2017 at 08:55

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)