Problem/Motivation

Adding content is a critical function in Drupal. While we have added a tools block and a default shortcut for this EVERY OTHER MAJOR CMS puts an add or create content link in the MAIN toolbar. This is marked critical because it is a critical usability problem in Drupal that a new user has to hunt around just to find where to do the most fundamental thing that a CMS does; create content.

Content can not only be nodes, but also media items or custom entities

Proposed resolution

(a) The optimal solution would be to make "Add content" a primary toolbar item using hook_toolbar() with a tray for the available types.

(b) Alternatively, we can add another menu that is linked to "Add" and displayed in the tray. Node, Media and other modules can then add menu items to it, and sitebuilders can customize it per site.

Remaining tasks

Write new patch.

For (b)

  • Create a menu in the system module (together with other menus).
  • Display the menu in the toolbar, themed similar to the admin menu
  • Configure Node module to add menu items for the default Add content and/or the default Add article and Add pages.
  • In case the Media module provides default media types: add them as well.
  • Remove the Add content short cut to avoid too much duplication.
  • Change the hook_help text of the Toolbar and possibly of the Shortcut module.
  • Fix the tests.

User interface changes

The item 'add content' would appear in the top toolbar.

This is a UI change and therefore the hook_help text and other documentation needs to be changed.

API changes

?

Data model changes

CommentFileSizeAuthor
#72 Selection_037.png13.22 KBBerdir
#68 interdiff-2377543-58-68.txt4.41 MBifrik
#68 2377543-toolbar-add-content-menu-68.patch14.29 KBifrik
#62 interdiff-2377543-58-62.txt484 bytesmohit_aghera
#62 2377543-toolbar-add-content-menu-62.patch14.59 KBmohit_aghera
#58 interdiff-2377543-53-58.txt7.78 KBifrik
#58 2377543-toolbar-add-content-menu-58.patch14.46 KBifrik
#56 interdiff-23377543-53-54.txt5.25 KBifrik
#56 2377543-toolbar-add-content-menu-54.patch12.62 KBifrik
#53 2377543-toolbar-add-content-menu-53.patch7.97 KBkatzilla
#51 2377543-toolbar-add-content-menu-51.patch.txt7.97 KBkatzilla
#48 2377543-toolbar-add-content-menu-48.patch.txt8.1 KBkatzilla
#35 Add-content-customized.png46.61 KBifrik
#35 Add-content-default.png18.9 KBifrik
#35 2377543-toolbar-add-content-menu-35.patch5.52 KBifrik
#31 add-content-list.png20.66 KBifrik
#29 toolbar-add-content-mobile.png31.45 KBVic Luijkx
#29 toolbar-add-content-desktop.png82.78 KBVic Luijkx
#24 add-content-in-toolbar.png56.29 KByoroy
#11 2377543-navbar-add-content-11.patch652 bytesElijah Lynn
#10 2377543-navbar-add-content-10.patch2.2 KBElijah Lynn
#1 navbar_add-content-submenu_2377543_1.patch2.1 KBbreathingrock
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch navbar_add-content-submenu_2377543_1.patch. Unable to apply patch. See the log in the details link for more information. View
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

breathingrock’s picture

FileSize
2.1 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch navbar_add-content-submenu_2377543_1.patch. Unable to apply patch. See the log in the details link for more information. View
hass’s picture

Version: 7.x-1.4 » 7.x-1.x-dev
eshta’s picture

Status: Active » Postponed

This isn't the functionality in Drupal 8 that I'm aware of. Navbar functions as a backport of the Drupal 8 toolbar. You should open up an issue there to determine whether this should be added.

cweagans’s picture

Leaving a note for myself, as I might come back to this: at a minimum, the drupal_alter() should go in so that we can do this in our own module if we want to. If that alter is not available upstream, I'll submit a patch to add it and then do the backport here.

hass’s picture

Project: Navbar » Drupal core
Version: 7.x-1.x-dev » 8.0.x-dev
Component: Code » toolbar.module
Issue tags: +Needs backport to 7.x

Moving for decision making to D8. Please move back once done or just close if we do not like to implement this at all.

xjm’s picture

Issue tags: -Needs backport to 7.x +needs backport to D7
Elijah Lynn’s picture

Status: Postponed » Needs review

Unpostponing per #3 since the issue was moved to core.

Status: Needs review » Needs work

The last submitted patch, 1: navbar_add-content-submenu_2377543_1.patch, failed testing.

Elijah Lynn’s picture

Status: Needs work » Active

I guess technically this should just be active since the original patch was for Navbar, not toolbar.module and there is nothing to review other than decide if this is functionality that has the chance of getting into core.

Elijah Lynn’s picture

For the interim, we are maintaining this patch (and need somewhere to link to) and here is a reroll for Navbar 7.x-1.6. I am wondering if maybe I should just break it out into a contrib module called navbar_add_content or something like that. Don't want to pollute the namespaces too much though. I do think others could use this so don't want to keep it custom if I don't have to.

7.x-1.5 broke #1 because it changed the menu class to be navbar-menu vs just menu as to not conflict with core.

The interdiff looked like $#!t so I left it out but the only lines that really changed were 551-558.

Elijah Lynn’s picture

Okay, since it is unlikely to get this functionality added to Drupal Core how about adding this a hook_navbar_menu_tree_alter() so we can make a custom or contrib module to do this?

Anyone object if I move this back to Navbar issue queue?

Elijah Lynn’s picture

Whoops, I didn't realize what needs to happen. @cweagans explained it to me. So ignore #11. We need to first roll a patch to bring the alter hook into D8 and only then, once it is committed will it be a candidate for Navbar. Since "add content" was never a thing and Admin Menu just made us feel like it was standard this never was actually in core. Further, since Toolbar is horizontal only (Navbar is horizontal or vertical) it doesn't ever show multiple levels of menu so the "add content" doesn't make sense to bring into core. Only the alter hook is a candidate now.

Elijah Lynn’s picture

I totally mispoke in #12 when I said it is horizontal only, it definitely is vertical as well. Not sure what I was smoking ;).

That being said, if #2395797: Allow defaulting toolbar tray to vertical orientation with configuration gets in then it may make sense to add the "Add content" to core. Is there any reason why this would be a bad idea? I feel like it is one of those things that would have already been there but it isn't because there was an issue with that functionality.

Elijah Lynn’s picture

webchick’s picture

Category: Feature request » Task
Priority: Normal » Major
Issue tags: +UMN 2015
Parent issue: » #2497361: [meta] Fix issues found during UMN Usability Testing 2015
Related issues: +#1852346: Toolbar UI regression: shortcuts and menu not visible at same time

This came up during usability testing. People had a much harder time finding the place to add content than in D7's testing.

webchick’s picture

Also please note that this might not be the way we want to solve this, but it is one possible way.

tkoleary’s picture

Adding content is a critical function in Drupal. While having a sub-menu where "add content" can be accessed is better than nothing, it's not optimal.
The optimal solution would be to make "Add content" a primary toolbar item using hook_toolbar() with a tray for the available types.

Immediate access to the types also cuts out an extra click.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

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

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

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

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

tkoleary’s picture

Version: 8.2.x-dev » 8.3.x-dev
Priority: Major » Critical
Issue tags: +Usability, +sprint
catch’s picture

Priority: Critical » Major

There's no justification in your comment or the issue summary for why this is critical.

tkoleary’s picture

Title: Add "Add Content" submenu to navigation. » Add "Add Content" item to navigation.
Priority: Major » Critical
Issue summary: View changes
tkoleary’s picture

Title: Add "Add Content" item to navigation. » Add "Add Content" item to toolbar.
yoroy’s picture

FileSize
56.29 KB

I think that during analysis of the latest usability test it was decided that even UX criticals would be marked as major but I'm not sure.

So something like this? Not an actual design for the icon (do we have one?) but in this position in the toolbar.

vaplas’s picture

Priority: Critical » Major

Sorry for this friday's post, but for me this issue has status between Normal and Minor. #2634854: Add "Admin Toolbar" module to core toolbar is realy should be Triaged Critical :)

even UX criticals would be marked as major

+1. Do not misunderstand me, please. I love UX and i'm very grateful to @tkoleary and everyone who care about it. But AFIAK, critical - this is a problem that we can not get around. But we can get around UX problem always.

Comeback status to Major based on #21, #24, #25 and on the fact that with the critical issues is working less people :)

tkoleary’s picture

@yoroy

I like that. But should it be a plus icon? Pencil is more edit existing right?

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.

yoroy’s picture

Issue tags: +Needs design
Vic Luijkx’s picture

I came across this issue and started experimenting using the plus icon.

toolbar-add-content-mobiletoolbar-add-content-desktop

ifrik’s picture

I agree that at the moment we don't have any obvious way of adding "content".

But, I think we need to define what the toolbar is for, before starting to add other functionality to it. A few weeks ago another module put a Save button in there. So unless we get some clarity - and some UI standards - this will turn into a free for all and a completely cluttered toolbar.
My understanding is that the different items in the toolbar basically change the "mode" the user is in: whether to manage the site, to do something with your own user account, to switch to a different mode to place blocks, or to go back to the front end of the site. None of that are shortcuts to individual actions.

We also need to take into account that "content" by now is more then what is provided by the node module. With media in core we already have one other content entity in core.
Contrib modules also provide content entities (for example products) and we provide users with the an easy way to create Custom Entities.
So we should rather think of a consistent way that allows users to find where to add any type of content. Currently this is per entity type (nodes on the Content page, media on the Media page). This is apparently not sufficient, and with current structure of the Content menu item, adding a media item is at least 4 clicks away from any front end page. But just adding a link to "/node/add" at some top level would only solve this for node content.

Maybe a better idea is to add a generic "Add content" item that opens a list that contains all links to any of the pages where the user can add a content entity.
This would allow sitebuilders later to configure that list as appropriate (for example instead of "Add content" "Add article", "Add basic page", "Add video").

I'll add a mockup later.

ifrik’s picture

FileSize
20.66 KB

See mockup:

In this case the items "Add content" and "Add media" would be in a new menu, which allows other modules to place pages in it and sitebuilders could customize it. (For example to list the individual content types instead)

It would also allow for adding submenu items - depending on what users want to do with it.

ifrik’s picture

As discussed during UX meeting:
The menu links should be "Add content" and "Add media" on the landing page as well.

I'll make a patch for it to work with for further exploration.

webchick’s picture

Talked about this on today's UX meeting. Looks like we still need some more design exploration, and a patch to prototype the behaviour so we could play around with it in "real life" would be awesome!

Another thing to figure out: Do we want to do this "just" for content, or do we want to apply the pattern to other items in the toolbar (e.g. Users)?

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.

ifrik’s picture

Okay, here is a starting point, mainly re-using what we already got

In the System module, I've added a new module Add content. The Node module adds its menu item "Add content" there. The Media module could do the same, and so could any custom entities.
The toolbar module then adds a tab and places the new menu in the tray. This is basically what for example Devel module also does.

Because it's a menu, users can change these items as needed. For example, to add links directly to the pages for those content types used on a specific site. See screenshots.
The "Add content" menu item links to the same page as the current shortcut link, so there is no regression in design or functionality, but it means that the Shortcuts become really available for personalisation without the fear of loosing required items.

Permissions and so are not set at all for this yet, and the landing page (in case there's no javascript) doesn't work either. There also should be a dropdown button if there are sub-menu items.

Default Add content with only the Node module enabled:

The Add content tray, customized through changing menu items:

ifrik’s picture

Status: Active » Needs review

The last submitted patch, 10: 2377543-navbar-add-content-10.patch, failed testing. View results

The last submitted patch, 11: 2377543-navbar-add-content-11.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 35: 2377543-toolbar-add-content-menu-35.patch, failed testing. View results

ifrik’s picture

The more I think about it: It could simply say "Add" in the toolbar. That would be in line with "Manage" and "Edit", and anybody building a site would still quickly see that there's only "Add content" in that menu by default (or maybe "Add content" and "Add media") - so they would expect to add anything else there. That way we also don't have a duplication of "Add content".

webchick’s picture

Reviewed this in UX meeting today:

  • +1 to the idea of having Add content be a top-level item. Maybe should be the first link?
  • "Add" sounds good, to make it shorter, to match with "Manage."
  • +1 to this menu being configurable per-site.
  • The default configuration should have more things in it; right now Add content > Add content looks kind of like a bug.
  • A general concern expressed by @ckrina that the toolbar is difficult to know what it's going to do (zing you off somewhere, show a list of links, etc.)
droplet’s picture

ifrik’s picture

Title: Add "Add Content" item to toolbar. » Add "Add" item to toolbar.
Issue summary: View changes
ifrik’s picture

Issue summary: View changes
ifrik’s picture

We discussed at the UX meeting that instead of linking to the "Add content" page and from there to each content type, the links to add the different content types (and other entities) should be in the menu directly.
If there are lots of different content types, media types and possibly custom entity types this list might get too long to be displayed properly horizontally - but the default Drupal installation only comes with very few content types (article and page at the moment) so it makes more sense to have these Add [content type] menu items accessible straight away.
Any sitebuilder who creates so many different entity types that they don't fit anymore will also be able to modify the menu - so there's no problem there.

In the initial patch, I just added the Add content page as a menu item via the node.links.menu.yml file, but now I need the node module to provide a menu item for each content type that is created during installation or by the user later.
Any advice on how best to do that?

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

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.

ifrik’s picture

katzilla working on this during sprint weekend

katzilla’s picture

Added the links to the submenu. I would not remove the existing local task for adding content, because if someone does not have access to the toolbar, there would no other way to add content.
I used a dynamic menu-link in favor of hook_toolbar to make it more flexible. Now you can re-sort the items in the menu settings. This might be helpful when other entities (like media e.g.) would add their items, too. We would also need a new hierarchy to separate content from media etc. when other types are added to the menu in a next step.

katzilla’s picture

Status: Needs work » Needs review
webflo’s picture

+++ b/core/modules/node/src/Plugin/Derivative/NodeMenuLinkDeriver.php
@@ -0,0 +1,61 @@
+    $bundles = NodeType::loadMultiple();

We should inject the "node_type" entity storage

+++ b/core/modules/node/src/Plugin/Menu/NodeMenuLink.php
@@ -0,0 +1,11 @@
+class NodeMenuLink extends MenuLinkDefault implements ContainerFactoryPluginInterface {}

Not sure if the NodeMenuLink class is really needed. I think MenuLinkDefault is good enough.

katzilla’s picture

ifrik’s picture

Thanks a lot!

I'll continue to work on this to fix the remaining tasks.

katzilla’s picture

katzilla’s picture

Status: Needs review » Needs work

The last submitted patch, 53: 2377543-toolbar-add-content-menu-53.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

ifrik’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
12.62 KB
5.25 KB

I've removed the "Add content" hardcoded shortcut item to avoid duplication and fixed most tests to account for the changed numbers of menus and shortcut items, but this will probably still fail on Drupal\menu_ui\Tests\MenuTest.

Status: Needs review » Needs work

The last submitted patch, 56: 2377543-toolbar-add-content-menu-54.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

ifrik’s picture

Sorry wrong patch in the previous comment.

timmillwood’s picture

Some initial points, mainly nitpicks:

  1. +++ b/core/modules/node/node.links.menu.yml
    @@ -6,3 +6,7 @@ entity.node_type.collection:
    +  ¶
    

    White space to be removed.

  2. +++ b/core/modules/node/src/Plugin/Derivative/NodeMenuLinkDeriver.php
    @@ -0,0 +1,60 @@
    + * Class NodeMenuDeriver. Provides menu links to add nodes of existing bundles.
    

    The class can be removed from the description.

  3. +++ b/core/modules/node/src/Plugin/Derivative/NodeMenuLinkDeriver.php
    @@ -0,0 +1,60 @@
    + * @package Drupal\node\Plugin\Derivative
    

    I don't believe we usually list the package in a class docblock.

  4. +++ b/core/modules/node/src/Plugin/Derivative/NodeMenuLinkDeriver.php
    @@ -0,0 +1,60 @@
    +class NodeMenuLinkDeriver extends DeriverBase implements ContainerDeriverInterface {
    
    +++ b/core/modules/node/src/Plugin/Menu/NodeMenuLink.php
    @@ -0,0 +1,10 @@
    +class NodeMenuLink extends MenuLinkDefault {}
    

    I'm wondering if it's worth adding in the class name that it's adding a menu link for adding node?

  5. +++ b/core/modules/system/src/Controller/SystemController.php
    @@ -173,6 +173,13 @@ public function systemAdminMenuBlockPage() {
    +   * Provides a single block from the add content menu as a page
    

    Needs a full-stop at the end.

  6. +++ b/core/modules/toolbar/toolbar.module
    @@ -239,6 +274,25 @@ function toolbar_prerender_toolbar_administration_tray(array $element) {
    + * Renders the toolbar's Add content tray
    + * in the same way as the Administration tray
    

    This should be on one line (with a full-stop at the end).

timmillwood’s picture

When testing the patch with JavaScript disabled, or opening the "add" link in a new tab, I just get a page with:

Add any content
You do not have any administrative items.

Then testing with Node module uninstalled (and javascript enabled again) clicking the add link doesn't do anything.

ifrik’s picture

Status: Needs review » Needs work

Thanks, I'll work further on that.

mohit_aghera’s picture

Status: Needs work » Needs review
FileSize
14.59 KB
484 bytes

@timmillwood @ifrik
Does it necessary to have separate URL for menu items ?
Can we use existing menu items "/node/add"
At-least this will prevent issue when JS is disabled.
I am not sure if it is best way to approach issue, needs your inputs regarding it.
See, interdiff for what I am trying to explain. If that works I can fix other comments in another patch.

timmillwood’s picture

I quite like the idea of it being /add because it can possibly be expanded to other entity types later on. Also I don't think we should be hijacking /node/add.

The points in #59 are still to be addressed too.

Status: Needs review » Needs work

The last submitted patch, 62: 2377543-toolbar-add-content-menu-62.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

ifrik’s picture

Assigned: Unassigned » ifrik

We had previously discussed the possible path, and it certainly should not be "node/add" because then the this can't be extended to other entity types, and it will break if the Node module is not enabled.
I'm working on this.

ifrik’s picture

Discussed this at the Amsterdam Drupal user group meeting yesterday, and the proposal was to just render the menu as a page on the path /add. Then the same information would be available without or without javascript, including any customization of the menu done by the sitebuilder.

Berdir’s picture

Seems rather likely that existing sites already have aliases or other kinds of pages on /add, I'd say that /admin/add would be a safer choice and would then also use the admin theme by default?

ifrik’s picture

Status: Needs work » Needs review
FileSize
14.29 KB
4.41 MB

/admin/add would mean that users need permissions to access the admin pages, but /content/add would work. We are stuck with the fact that the nodes are referred to as content, so we might just as well use it.

This will probably still fail on one of the test. Comments from #59 included, with the exception of 4 because I don't quite understand what might need adding there.

Berdir’s picture

> /admin/add would mean that users need permissions to access the admin pages

No, that's not how /admin works. The only special behavior that /admin has is that *if* you have access to use the administration theme, then you get the page in that. Which is IMHO a good thing, because it's much easer to provide a predictable UI in the admin theme than whatever people are using for their frontend. But actually being able to access it *only* depends on the access checks set on your route.

PS: Something went very wrong your interdiff, it is 4MB big :)

  1. +++ b/core/modules/node/src/Plugin/Derivative/NodeMenuLinkDeriver.php
    @@ -0,0 +1,55 @@
    +   */
    +  public function getDerivativeDefinitions($base_plugin_definition) {
    +    $links = [];
    +    $bundles = $this->entityStorage->loadMultiple();
    +
    +    foreach ($bundles as $id => $bundle) {
    +      $links[$id] = [
    +          'title' => $bundle->label(),
    +          'parent' => 'system.add',
    +          'route_name' => 'node.add',
    +          'route_parameters' => ['node_type' => $id],
    +        ] + $base_plugin_definition;
    +    }
    +
    +    return $links;
    +  }
    

    If I understand this correctly then this means that we create a flat list of all node types to create.

    What happens if you create other entity types? Wouldn't your node and media types get mixed up in that list?

    I think we need a second entity type like media in that list so that we can be sure that it actually works for that.

  2. +++ b/core/modules/node/src/Plugin/Menu/NodeMenuLink.php
    @@ -0,0 +1,10 @@
    +
    +/**
    + * Represents a menu link for node add node type.
    + */
    +class NodeMenuLink extends MenuLinkDefault {}
    

    why is this needed if it doesn't do anything special, can't we use the default class?

  3. +++ b/core/modules/system/config/install/system.menu.add.yml
    @@ -0,0 +1,7 @@
    +id: add
    +label: 'Add'
    

    I think we need an update function that creates this for existing sites because we are unconditionally creating menu links for it. Either that or we check that the add menu exists everywhere.

    What about naming conflicts on existing sites that might already have an add menu? Like with the path, should we maybe use something that is less likely to conflict, like system_add?

ifrik’s picture

About the path: at the moment all paths to create content are not under /admin so we shouldn't break that but just like /node/add this page should probably be rendered in the admin theme if users have access to it and if the theme settings aren't set to display the node edit forms in the front end theme. That would keep it consistent.

The idea is indeed to create a flat list of content types to replace the "Add content" in the short cuts.

Other entity types could in future be added in that same flat list: we want a list where the user doesn't need to know whether something is a content type, media, or some custom entity.

Status: Needs review » Needs work

The last submitted patch, 68: 2377543-toolbar-add-content-menu-68.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Berdir’s picture

FileSize
13.22 KB

> About the path: at the moment all paths to create content are not under /admin so we shouldn't break that

Depends on how you define content I guess :) Technically, as an entity system maintainer, terms and users for example are content entities and are created under /admin.

But I see your point, it doesn't matter that much as long as we do use the admin theme. So either we use /admin or we have to explicitly add it to the route.

> Other entity types could in future be added in that same flat list: we want a list where the user doesn't need to know whether something is a content type, media, or some custom entity.

Hm, I doubt that the bundle label alone is enough to be clear if we start to add different entity types in there.

Even with only node types in there, as a default core feature, it needs to be something that can deal with special cases, like a lot of different node types. Tested the patch on an existing site (an installation profile) that has quite a few of them but I guess there are sites out that that have more. Seems to work after I manually added the add menu but it doesn't look exactly pretty :)

Now imagine adding 5-10 media types in there, alphabetically sorted which means everything is mixed up. Not sure what other entity type we would add? Terms probably doesn't make sense for most use cases.

Those are menu links, that means site builders can customize them, disable them and re-order that helps already. One possible solution could be to have a fixed limit of links that we show there directly (fill one row, basically) and if there are more, have a "See all..." link that points to the full page? On that page, we could use hierarchy to have things grouped by type, like on admin/content basically. That would mean that we'd have to flatten the hierarchy for the quick links...

PS: I'm not trying to be annoying or blocking this, I think it is a useful addition and I can also try to help with specific technical issues like failing tests. But like everything else, there are a lot of things to consider.

Berdir’s picture

Another random idea. How many entity types are eligible for this kind of special placement? What if we *do* limit it to node. We could just name the top-level element "Add content", point to /node/add, and create per-node-type menu links below /node/add. If we also want allow to have such a direct access for media (media is usually created while creating nodes/content, so not sure that's even common enough) then we could add a "+ Add media", maybe with a slightly different icon.