Problem/Motivation
Providing a Single Link Navigation Block type could be useful for situations where a single item needs to be added to navigation and creating a new menu just for this purpose would be overkill and complex for editors.
A good example of this is the Help link in the current navigation. This is a single link and it was hardcoded in the NavigationUserBlock to avoid creating an extra menu.
If we add this new item, we could migrate Help link to be an usage of this block type and significantly simplify logic in NavigationUserBlock.
Related issues where complexity could be reduced:
#3441576: Add a new "Navigation user links" menu in favor of hardcoded links in NavigationUserBlock
#3441118: Add the user image to the user menu when available
Steps to reproduce
Current process to add a single link to page Foo in navigation:
- Go to Add Menu Page and create and arbitrary menu called Bar
- Edit the Bar menu and add menu item to Foo and its title
- Go to Navigation Layout page and add a new Bar Menu block
- Configure the Bar Menu Block to use 1st level and depth of 1
- Link to Foo is added to Navigation
Proposed resolution
Create a new Block plugin for use in the navigation, which allows for configuring a navigation block with a single link, rather than having to place a single link with the overhead of creating a menu, setting a link within it, then setting up a navigation block. This would alleviate the present hardcoding of the Help link as noted above, simplifying NavigationUserBlock, and potentially other user cases, also noted above.
Due to UX concerns with this approach, e.g. the potential proliferation of many single link blocks, this new block type will not be available to be added via UI. But created to make the work on the related issues smoother.
Remaining tasks
Update proposed resolution
Update change record
User interface changes
None. While we added a new Link block here, it is presently hidden from the general Block layout page as well as the Navigation layout page.
API changes
A new block with machine name navigation_link was added.
Data model changes
None.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3445993
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
plopescPostponing due to necessary implementation discussion.
Comment #3
plopescComment #4
plopescWorking on it!
Comment #6
plopescAs discussed with @ckrina in Portland, this new block will be hidden by now, but used for the Help Navigation item for testing purposes and simplify the footer logic.
Added functional tests to ensure link access rules are preserved.
Attaching screenshot to ensure that there are no visual regressions.

Comment #7
m4oliveiComment #8
plopescComment #9
m4oliveiLove the thought here. One thing I noticed is that the spacing in the footer has some regressions.
Will also go through a static review shortly.
Comment #10
skaughtcore
contrib, quick list..
Comment #12
gauravvvv commentedComment #13
m4oliveiThis is looking great. RTBC for me.
Comment #14
catchI think this needs an issue summary update and a change record.
Comment #15
m4oliveiComment #16
m4oliveiI'll take a crack at writing a change record here.
Comment #17
m4oliveiUpdated the issue summary as well as drafted a change record. First time drafting a change record, so let me know if I missed the mark in any way.
Comment #18
m4oliveiI'm also unclear if I could have put it back to RTBC in this instance? Would be curious to learn process there too. Thanks!
Comment #19
catchYes fine to put it back to RTBC if you added a change record or similarly fixed issue metadata.
The last question I have is whether the icon class in config is consistent with the current plans for icons?
Comment #20
plopescIcon config is consistent with the current icon approach.
There's no clear direction for final icons yet.
Comment #21
finnsky commentedI think that CSS can be simplified. But i don't want to block this feature.
Comment #22
finnsky commentedLet's fix CSS here:
https://www.drupal.org/project/drupal/issues/3450103
Comment #23
larowlanLeft some comments/questions on the MR
There's also some existing open threads that I'm not sure have been addressed.
Love this, much cleaner than how we were doing 🙌
Comment #24
plopescThank you for your comments in the MR.
Worked on them and I think this is ready for another round of reviews.
Adding reference to follow-up created: #3450518: Add a generic trait for logic to convert references into Urls in LinkWidget
Comment #25
plopesc@larowlan After searching through the issue queue, I have seen that #3379725: Make Block config entities fully validatable already exists and is the key to unlock validation in blocks. There would be no need to create a new issue.
Comment #26
plopescAll the MR comments have been addressed, follow up issue for validation referenced, code updated to latest 11.x and conflicts solved.
This is ready for a final round of reviews.
Comment #27
m4oliveiCan confirm that all comments have been addressed. Everything is working well from a functional perspective.
Comment #28
quietone commentedI read the issue summary, comments and the MR (not a code review). I didn't spot unanswered questions.
@m4olivei, thanks for updating the issue summary, creating the change record and confirming the change is working as expected. Very nice. Just two things need to be updated.
The proposed resolution should state what is being added in this issue. Currently, it lists steps to create this new block type from the UI but then says that the UI is not being added. This should be updated to explain what is being done in this issue onlly. Refer to https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-...
I also read the CR which is clear and easy to read, so that is good. I do think it needs work to explain to developers how and why they would use this.
Also, In a comment it was stated that "this new block will be hidden by now, but used for the Help Navigation item for testing purposes and simplify the footer logic". Is that testing added in this issue? Is that in a followup? Apologies if I missed the answer to these questions.
Tagging and setting to needs work for the above and a question in the MR.
Comment #29
m4oliveiComment #30
m4oliveiThanks @quietone. I've updated the change recode and issue summery per your suggestions.
Back to RTBC🤞.
Comment #31
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #32
plopescBack to RTBC once the suggestions in #28 were addressed and MR is ready to be merged.
Comment #33
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #34
andypostNeeds phpcs fixes
Comment #35
plopescCode updated to the last version and PHPCS issues addressed. Back to RTBC.
Comment #36
m4oliveiAdding Navigation stable blocker tag, as this is blocking #3443452: [PP-1] User menu block render array is cached per user.
Comment #37
quietone commentedI added return type hints to new methods and updated a few docblocks. I am leaving at RTBC to not delay a blocker to Navigation becoming stable.
Comment #38
nod_couple of questions
Comment #39
m4oliveiTiny nitpick found to change
t()to$this->t(). Otherwise looking great to me. +1 RTBC.Comment #41
larowlanCommitted to 11.x and published the CR
Thanks folks
Comment #43
amateescu commentedShouldn't this be backported all the way to 10.3.x?
Comment #44
larowlanBackport rules for maintenance minors are here:
https://www.drupal.org/about/core/policies/core-change-policies/allowed-...
I don't think this meets those - maybe
Critical API compatibility backports?Comment #45
amateescu commented@larowlan, the Navigation module is experimental and this is a stable blocker, that's why I thought it needs to be backported :)
Comment #46
larowlanI've asked RMs
Comment #48
larowlanBackported to 10.4.x after discussing with RMs