Add option to have default setting for providing menu link

There was an issue with the functionality, so fixed that and added tests.

The current MR was created against 9.5x and I don't have permission to edit, so created patch

This seems close but I don't see where we are testing that the menu link is pre-checked on the node add page.

Also will need a change record with appropriate screenshots.

Hi, I updated the tests, I hope this will be enough

Change record - https://www.drupal.org/node/3373587

Think this is better

+++ b/core/modules/menu_ui/config/schema/menu_ui.schema.yml
@@ -21,3 +21,6 @@ node.type.*.third_party.menu_ui:
+    link_by_default:

Given the schema change, wouldn't this need an upgrade path?

Closed #1440694: Add a menu item for each "Basic page" by default (Standard install profile) as a duplicate

Excellent idea, lets do this. Two questions:

- Provide or create? Maybe create is the simpler word? Lets also add 'a': Create a new menu item by default.
- Was this deliberately put at the bottom of this list of settings? I can also imagine it at the top, as the very first consideration and decision to make for this menu settings section.

- Provide or create?

"Provide" is the word used in the Menu settings on the node edit form, so it might be best to keep the words consistent.

"Provide a menu link by default."
-OR-
"Provide a menu link by default when saving new content."
-OR-
"Provide a menu link by default when saving new content of this type." - My vote, fwiw

The "...content of this type" phrase comes from two other places:

"Content of this type can be placed in the selected menus."

"This text will be displayed at the top of the page when creating or editing content of this type."

The word "Add" would also make sense as it is used throughout the UI, but between the 3 proposed options (Provide, Create, Add) I'd personally vote for consistency and stick with "Provide", unless we want to change the word "Provide" to something else on the node edit form.

Note: whichever sentence ends up being used it needs a . (period) at the end of the sentence.

- Was this deliberately put at the bottom of this list of settings?

I think it make most sense either right above or right below the Default parent link select list as the two are related.

The MR looks good overall but I think the testing could be easily extended to check if the link was actually created at admin/structure/menu/manage/main

Seems additional test coverage has been added in commit https://git.drupalcode.org/project/drupal/-/merge_requests/4642/diffs?co...

See the comment on the MR - we need to rewrite the post update.

Hiding all the files to make this easier to review.

+1 for putting it at the top.
I get what Chris Matthews is saying but in natural order I would say something like: "Oh definitely create a menu item by default, these are the menus I would like available, but the default one should be this." That feels right to me.

Closed #3405645: Auto create the menu for node. as a duplicate of this.

Triaging this one

First this needs an issue summary update.

Let me try and get a main branch up for review.

Believe this is ready for review.

I had one question on the MR. The rest looks good to me. I manually tested the new setting as thoroughly as I could and it works correctly.

My feedback was addressed. Thank you for considering it.

I read the CR, which I found somewhat confusing. I started to improve the text and grammar as best I could. I then tested the MR locally and the images in the change record are out of date. The text for the new setting has changed since they were made.

I also don't see that the text hasn't been checked by the usability team. What strike me is the use of 'by default'. This page is exactly for setting various defaults to use. Of all the settings available on the article content type edit page the only use using default is the 'default parent link'. So why is it being added here. I did see that @yoroy suggested it 3 years ago, and at the same time he questioned whether it should be 'create' or 'provide'. There was only one other comment about the wording.

And why not follow the existing pattern. "Promoted to front page" and "Sticky at top of lists" are the same on the content type edit page and the create page. Why can't this just be "Provide a menu link"? To me, it has the same meaning.

We discussed this issue at #3591402: Drupal Usability Meeting 2026-05-29. That issue will have a link to a recording of the meeting.

The attendees at the usability meeting were @kentr, @rkoller, and @the_g_bomb. I am giving them credit on this issue.

Fwiw I’m fine with “Provide Menu link” as suggested by quietone

Usability review

We discussed this issue for the first time at #3591402: Drupal Usability Meeting 2026-05-29. The link to the recording: https://www.youtube.com/watch?v=z8_i1aGRIZE. The attendees at the usability meeting were @kentr, @rkoller, and @the_g_bomb. We discussed the issue for a second time at #3592713: Drupal Usability Meeting 2026-06-05. The link to the recording: https://www.youtube.com/watch?v=-WfaMFyc6bc. The attendees at the second meeting were @benjifisher, @rkoller, and @worldlinemine.
Initially, the base behavior introduced by MR15538 looked like a convenient and useful addition, but on closer look it turned out it introduces a few significant problems, mainly in the context of how things are being communicated, or rather how they are not communicated, which leads to a lack of situational awareness. Below, the points that caught our attention, at first node edit forms:

• The main challenge posed by MR15538 is the question how to distinguish nodes for content types that have the Provide a menu link by default when saving new content of this type. setting enabled, compared to nodes for content types that have that setting disabled. When loading the node edit form page the Menu settings details element in the advanced sidebar has an empty summary. A few different perspectives:
  • Sighted users "might" be able to notice the animation in the advanced sidebar within the Menu settings details element by chance when they are entering content into the Title field in the node edit form. The animation they notice is when the entered title gets synced and added into the Menu link title field within the Menu settings details element, and that Menu link title also gets displayed and updated as the the detail element's summary.
  • But sighted users might also simply ignore/phase out the advanced sidebar, because they are either entirely focused on entering content and they give no additional attention on meta data, technical concepts like meta data contained in the advanced sidebar might even be overwhelming to them, they could be under psychological stress and pressure, and/or they have cognitive issues with focusing in general - in each case the fact that the Provide a menu link setting is enabled for the node at hand could go entirely unnoticed.
  • On mobile the advanced sidebar comes after the node edit form within the DOM order, so the Menu settings detail element could go completely unnoticed beneath the fold - the user might fill out the node edit form and just submit it.
  • For blind screenreader users without any visual context things are even worse, they don't know at all that they are on a node with the Provide a menu link setting enabled. There is also no announcement in the aural interface when the detail summary and Menu link title field are shown or getting updated.

  For a site with, for example, 50 different content types, 14 have the Provide a menu link by default when saving new content of this type. setting enabled while the other 36 have the setting disabled. That leads to a high cognitive load because it is not communicated in a clear, unambiguous, and explicit manner if the setting is being enabled for a node of a particular content type. In consequence, a user has to either memorize which of the content types have the setting enabled, but for people with a small working memory or lacking explicit declarative memory, that becomes a challenging endeavor; the other option people have is to get into the advanced sidebar for reassurance. And when a user is unaware that they are on a node that has the Provide a menu link by default when saving new content of this type. setting enabled, they might end up with menu item labels that are way too long unknowingly because they thought they were writing a title for, for example a blog post, not a title that would also be used as a menu item label - the two have different requirements in regard to character length.

• Directly related but out of scope for this issue, there is the aforementioned behavior to transfer the content entered into the Title field in the node edit form to the Menu link title field in the advanced sidebar. An implicit undocumented behavior that is already part of core, and the outcome for every scenario is not necessarily clear, including fringe edge cases:
  • With the Provide a menu link checkbox checked, content entered into the Title field is getting synced directly to the Menu link title field.
  • As soon as you alter the content of the in-sync Menu link title field, the sync process is getting terminated, and the content of the Menu link title field becomes independent from the content of the Title field.
  • If the Provide a menu link checkbox is now getting unchecked and then rechecked again, the content is getting lost - in the case of the bespoke content in the Menu link title field, that is actual data loss. After rechecking the Provide a menu link checkbox, the current content of the Title field is getting synced again with the Menu link title field until the node edit form is getting submitted.
  • If no title has been entered on the node edit form yet, the Provide a menu link checkbox is then getting checked, and content is getting entered into the Menu link title field; the Title field remains empty - the synchronization is a one-way street from the Title to the Menu link title field.
  • If the title on an already saved node with the Provide a menu link checkbox checked is getting altered, those changes are not getting synced to the Menu link title field anymore.
  • For existing already saved nodes, if you uncheck the Provide a menu link checkbox, change the title, and recheck the checkbox, the sync with the Menu link title field is reenabled until the next submission/save of the node.

  Due to the fact that this helper function is not defined nor explicitly stated how it is supposed to work in every aforementioned scenario, it might create false expectations on the user's end.

• In regard to the overall situational awareness on node edit forms and the question of how to distinguish nodes with the Provide a menu link checkbox enabled by default and those having it disabled, the Menu settings detail element on the node edit form is the sole cue to help with a distinction - but the problem is that attribute is only communicated indirectly. For nodes of content types with the Provide a menu link setting disabled, the summary reads Not in menu, while for nodes of content types with the setting enabled, first you have no summary, and as soon as a title is being added, it is getting synced to the Menu link title field, and the summary for the Menu settings detail element is getting updated accordingly. So at this point, with the setting enabled, only the current Menu link title is shown. In contrast, on other detail elements in the advanced sidebar, more or less all the available information about particular settings is being displayed in the summaries. For example, the summary for Promotion options the detail element displays the exact labels of the checked checkboxes. Only the Menu settings detail element is solely the content of the Menu link title field being displayed in the summary; neither the label of the Provide a menu link checkbox nor the description or the chosen parent link is being displayed. A lot of context is being omitted in this particular case.

The menu settings for a content type have similar problems:

• By default, the Submission form settings vertical tab is active/selected on the Edit local task for a content type. All vertical tabs except the one to Menu settings provide a summary of the active settings. So one additional click is necessary to get into the vertical tab Menu settings and be able to determine if the content type provides a menu link by default or not. The summary also doesn't provide any information about the chosen menus and the selected default parent link. At the moment the summary for the Menu settings vertical tab does not provide any situational awareness at all.
• The label Provide a menu link by default when saving new content of this type. for the checkbox added by MR15538 within the Menu settings vertical tab is quite lengthy and hard to process. We have compared the settings available within the vertical tabs on a content type with the settings available within the advanced sidebar on a node edit form - usually the labels for checkboxes on vertical tabs and the advanced sidebar are identical. Aside from the microcopy, the position differs as well; on the advanced sidebar, the Provide a menu link checkbox is on top of the Menu settings detail element, while in the vertical tab it is at the very end. Aside from those inconsistencies, having a checkbox with a lengthy and hard-to-process label at the bottom right at the end of the form of a vertical tab could lead to it being overlooked and/or omitted from thorough scanning/processing.

We've decided against trying to make any recommendations at this point yet and agreed on revisiting this issue for hopefully one last time in one of the next meetings. We just wanted to document the outcome of the initial two discussions for now.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

I was at the second Usability meeting mentioned in Comment #37. We were well into that meeting before we realized that a lot of the surprises (like when un-checking and re-checking the "Provide a menu link" option) are existing behavior. It would have been helpful if someone who has worked on this issue had been able to attend the meeting.

One of the main points in Comment #37 is that there should be a clear indication that the Title field is being copied to the "Menu link title" field. This is an existing problem; the difference is that, before this issue, the content editor has to enable the checkbox before the text is copied. It may not be hard to fix this problem. One idea is to add some help text under the Title field when the "Provide a menu link" option is selected.