The Standard installation profile creates a useful "Home" menu link, but it is hard-coded. When a user wants to edit it, the following message is displayed:

This link is provided by the Standard module. The title and path cannot be edited.

This is hardly user-friendly. The only way around this is for the user to disable the Home link and create a new one instead and pointing it to <front>.

My proposal is to create the menu link programmatically and making it editable/deletable.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

wmostrey created an issue. See original summary.

wmostrey’s picture

Status: Active » Needs review
FileSize
1.41 KB

Status: Needs review » Needs work

The last submitted patch, 2: make_home_menu_editable-2838106-2.patch, failed testing.

wmostrey’s picture

Here's a patch that fixes the last two fails but I don't know how/where to fix the first two:

1.

fail: [Other] Line 100 of core/modules/config/src/Tests/ConfigImportAllTest.php:
Value array (
  0 => 'standard',
  1 => 'system',
  2 => 'user',
) is equal to value array (
  0 => 'menu_link_content',
  1 => 'standard',
  2 => 'system',
  3 => 'user',
).

2.

"There is content for the entity type: Custom menu link. Remove custom menu link entities."

tstoeckler’s picture

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.

wmostrey’s picture

Status: Needs work » Needs review
FileSize
2.39 KB

That makes sense. This patch should also fix two fails, with two remaining.

Status: Needs review » Needs work

The last submitted patch, 6: make_home_menu_editable-2838106-6.patch, failed testing.

tstoeckler’s picture

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.

wmostrey’s picture

Status: Needs work » Needs review
FileSize
3.41 KB

Thanks for the guidance. Attached patch should fix this.

Berdir’s picture

Status: Needs review » Needs work

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.

wmostrey’s picture

  1. That struck me as odd as well, I'm just rolling with it. I think it's beyond the scope of this issue, so maybe we can create a separate issue for that?
  2. I looked long for other solutions but using 'internal:/' is the only way to get a link to <front>.
Berdir’s picture

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.

wmostrey’s picture

Would it be enough to add a langcode?

$home = MenuLinkContent::create([
  'title' => 'Home',
  'link' => ['uri' => 'internal:/'],
  'langcode' => 'en',
  'menu_name' => 'main',
]);
tstoeckler’s picture

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')

wmostrey’s picture

Status: Needs work » Needs review
FileSize
3.42 KB

Here we go.

tstoeckler’s picture

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.

wmostrey’s picture

tstoeckler’s picture

Status: Needs review » Reviewed & tested by the community

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

The last submitted patch, 4: make_home_menu_editable-2838106-4.patch, failed testing.

Berdir’s picture

Status: Reviewed & tested by the community » Needs work
+++ 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..

wmostrey’s picture

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

So where do you think the following code (with adjusted comment) should live?

// Delete any menu links so the menu_link_content module can be uninstalled.
$menu_links = MenuLinkContent::loadMultiple();
entity_delete_multiple('menu_link_content', array_keys($menu_links));

Also in InstallUninstallTest.php?

Berdir’s picture

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?

Berdir’s picture

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.

wmostrey’s picture

Status: Needs work » Needs review
FileSize
3.43 KB

Here we go.

Berdir’s picture

Status: Needs review » Reviewed & tested by the community

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

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

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

wmostrey’s picture

Status: Needs work » Needs review
FileSize
4.22 KB

Something like this?

wmostrey’s picture

Status: Needs review » Needs work

Hm that won't work for people who clear the cache before running update.php.

wmostrey’s picture

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.

How do you feel about this implementation?

/**
 * Implements hook_cache_flush().
 *
 * Replace the static Home link with a dynamic one.
 */
function standard_cache_flush() {
  try {
    // Fetch the current standard.front_page menu item
    $home_current = \Drupal::service('plugin.manager.menu.link')
      ->getDefinition('standard.front_page');
    // The menu item hasn't been migrated yet.
    $home_check = \Drupal::entityTypeManager()
      ->getStorage('menu_link_content')
      ->loadByProperties(array('title' => 'Home', 'menu_name' => 'main'));
    // Populate the main menu if it doesn't exist yet.
    if(empty($home_check)) {
      $home_new = MenuLinkContent::create(array(
        'title' => t('Home'),
        'link' => array('uri' => 'internal:/'),
        'menu_name' => 'main',
        'weight' => $home_current['weight'],
        'enabled' => $home_current['enabled'],
      ));
      $home_new->save();
    }
  }
  catch (PluginNotFoundException $ex) {
    // The menu item has been migrated already.
  }
}
Berdir’s picture

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,

wmostrey’s picture

Status: Needs work » Needs review
FileSize
4.47 KB

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.

Anita verma’s picture

Assigned: Unassigned » Anita verma
wmostrey’s picture

Issue tags: +SprintWeekend2017
wmostrey’s picture

We have two options:

1. Static Home menu item wasn't altered. After deleting standard.links.menu.yml and clearing cache, the static Home menu item disappears. Let's use the default options for our new dynamic menu item (weight 0 and enabled).

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.

wmostrey’s picture

I submitted a bug at #2847653: Orphaned menu items should support removeDefinition because we can't remove the standard.front_page menu item.

Saphyel’s picture

+++ 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?

Saphyel’s picture

Assigned: Anita verma » Unassigned
Issue tags: +london_2017_january, +menu
tstoeckler’s picture

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

wmostrey’s picture

Status: Needs review » Needs work

I'm afraid so yes.

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.

tstoeckler’s picture

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?

wmostrey’s picture

As far as I can see this still doesn't allow us to delete the item, not with ->delete() or ->clear()->save()

(I'm available at #drupal-contribute during the #SprintWeekend to work on this.)

tstoeckler’s picture

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

Version: 8.2.x-dev » 8.3.x-dev

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

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

CatsFromStonehenge’s picture

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 :)

CatsFromStonehenge’s picture

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 :)

wmostrey’s picture

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’s picture

Rerolled the patch and change short array

akashkrishnan’s picture

Status: Needs work » Needs review
akashkrishnan’s picture

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.

wmostrey’s picture

@akashkrishnan It's a reroll of my patch. You need to run update.php after applying it. Do note we still have the issues described in #34 and the open bug report in #35.

dawehner’s picture

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

wmostrey’s picture

@dawehner The menu item can not be renamed, that's one of the things we're trying to solve here. We do take the item's weight and enabled state into account.

dawehner’s picture

It could have been moved to a different place though.

diqidoq’s picture

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>
akashkrishnan’s picture

Version: 8.3.x-dev » 8.4.x-dev

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

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mlncn’s picture

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.

romreactor’s picture

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.

diqidoq’s picture

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

mlncn’s picture

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.

Version: 8.4.x-dev » 8.5.x-dev

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

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.