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
#94 add-stuff.png277.09 KBbnjmnm
#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 KBAnonymous (not verified)
#29 toolbar-add-content-desktop.png82.78 KBAnonymous (not verified)
#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

Issue fork drupal-2377543

Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

breathingrock’s picture

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

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.

Anonymous’s picture

Priority: Critical » Major

Sorry for this friday's post, but for me this issue has status between Normal and Minor. #2634854: Add dropdowns to horizontal toolbar menu (as with 'admin toolbar' in contrib) 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
Anonymous’s picture

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

toolbar-add-content-mobile toolbar-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

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

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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

One of the issues we ran into was that new menu items need to be created automatically when a new entity type is created, for example a new content or media type.
I've talked with Joachim who is currently working on #2976861: add an entity Links handler, to provide menu links/tasks/actions for entity types which could solve this.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

webchick’s picture

Acquia just did some UX testing of Umami + Layout Builder + etc. and came across this same issue (working out whether I can make parts of this public). So just reaffirming that this continues to be a big UX regression in Drupal 8.

webchick’s picture

Issue tags: +AcquiaUXTest

Tagging.

AaronMcHale’s picture

This sounds like a good idea.

I like the idea of this just being “Add”.

I agree using the path /add could create too many conflicts with existing sites. /admin/add makes sense because:
- as mentioned the admin theme would automatically be used,
- anything under /admin is much less likely to conflict with existing sites
- /admin is kind of like the “\Drupal” namespace when it comes to paths so it’s a safe place for us to mess with
- Adding Content is generally an administrative task, in the sense of the user is not just viewing the site, they are modifying it, or in other words administering it.

My gut is telling me it’s better to take the approach of each [Node] Content Type having a Add link there, because:
- this is less likely to confuse new and novice users who don’t yet understand the concept of “Content Types” or “Entity Bundles”
- the UX would automatically be much nicer for sites who just have content editors where the primary purpose is just adding content. For these sites the editors probably only have access to add a limited set of Content Types along with Media so this seems like the best approach for those sites.

For other Core Entity Types such as Media, they should just have a single link to the Add page where they can select the type. This is because when adding something like Media or Taxonomy you only do this if your intention is to add one of these things, you know you’re adding a price of media; For Nodes the user doesn’t need to know they are adding a new Node they know that if they click “Add article” or “Add basic page” they are creating a page.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

saschaeggi’s picture

Is there any progress on this? :)

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

bnjmnm’s picture

Issue tags: +Needs followup

This was discussed at #3206957: Drupal Usability Meeting 2021-04-09 (everyone in attendance contributed to the discussion and should be credited it this lands).

The purpose of this discussion was to figure out a way to scope this issue so it can move forward.

There is UX signoff on this approach

  • Add an "Add Content" primary item to toolbar, that goes to node/add: We agreed "add content" is ambiguous and don't necessarily mean nodes. We also acknowledged that there is a frequently-used "Add content" button in admin/content, and users are already accustomed to it going to node/add. We agreed that there are UX benefits to simply adding a version of this button to the toolbar as
  • Add a message (that doesn't necessarily have to use the Drupal message area) that provides links to the other types of content that can be created): This issue makes some valid points that a user hoping to "add content" may not be intending to add node content. This would also benefit users clicking "Add Content" from admin/content. The message could be something like
    This page is for adding nodes. Click here to add media[add media link] Click here to add files[add files link]
  • Create a Drupal 10.0.x followup regarding a new destination for "Add content" One of the possibilities discussed was adding secondary tabs with every available entity type, similar to that in admin/content

Why it was agreed this approach was fine

  • Acquia UX testing has confirmed this continuing to be a major UX pain point. Getting something in will benefit users.
  • Users are already accustomed to "Add content" going to node/add, and it also covers the majority of use cases, so it's not critical to rethink the "Add content" destination in this issue
  • While it is possible that the expectations for the "Add content" destination might be different when clicked via toolbar instead of a page displaying a list of nodes. The message linking to other types of content to add mitigates this confusion.
  • This approach does not preclude later improvements. With Drupal, sometimes perfect has to be the enemy of good due to backwards compatibility concerns. Fortunately, this approach allows us to add some major good while keeping the door open for perfect.
saschaeggi’s picture

Berdir’s picture

> Add a message (that doesn't necessarily have to use the Drupal message area) that provides links to the other types of content that can be created): This issue makes some valid points that a user hoping to "add content" may not be intending to add node content. This would also benefit users clicking "Add Content" from admin/content.

Sorry to always be the person with the annoying technical remarks, but not quite sure how that would work. media is an optional module (and ignoring that core does not provide a way to add a "file", I understand it's just an example), and with some other contrib modules, you might want to create a poll or something. So I guess that would need to be extensible somehow?

At the same time, I'm the first person to agree on an approach with incremental improvements, so maybe even skip that part and make that a follow-up?

If we add such a top-level thing, should standard.module then stop adding its add content shortcut? that does seem to serve little purpose then?

ifrik’s picture

Assigned: ifrik » Unassigned

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

bnjmnm’s picture

Issue tags: +Field UX

bnjmnm’s picture

Status: Needs work » Needs review
FileSize
277.09 KB

The MR is better categorized "needs architectural review" - it should get some eyes on it to help shape it into a good addition to core. This is the UX meeting approved approach from #84, but there are still choices to be made within that approach. I'm sure there are ways to make it more appealing, but it's doing what it is supposed to do and at a good spot to pick up the baton.

Berdir’s picture

I'm really conflicted about this :)

I feel like I've shut this down on the last iteration and I feel bad about that. I actually like the idea of having this kind of overview, but at the same time, I also feel quite strongly that we have to get this right and and it needs to be the right kind of extensible and live in a sensible place.

Having node branch out to other entity types and the tricks with the node list preprocess and $type suddenly no longer being a node type entity is strange, but I guess the current MR is in a proof of concept phase. Like the links all pointing to node/add/$bundle ;)

For fun, I tried to add it on our project which has a lot of extra contrib modules, just to see what happens. Interestingly, it dies already on shortcut if you have assertions enabled:

AssertionError: Cannot load the "shortcut_set" entity with NULL ID. in assert() (line 261 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

You can't call createAccess() with bundle NULL on an entity type with bundle, that doesn't actually equal a check to see if you can create an entity of any bundle. I think that extra check can be dropped, instead we need to check at the end if we ended up with any accessible bundle for a given type, a bit like \Drupal\Core\Entity\EntityCreateAnyAccessCheck.

When I do disable that bit, then I end up with the ability to create things like a Shortcuts, Crop, Paragraphs and Webform submissions. I think that shows nicely that this really needs to be an opt-in process. When adding entity reference fields, we have the concept of "common_reference_target = TRUE" on the entity type annotation. We could add a content_add_overview = TRUE annotation to entity types and add it to terms, media and custom blocks as a start.

In regards to bundles, instead of limiting it to entity types with bundles and bundles as config entities, this should use \Drupal\Core\Entity\EntityTypeBundleInfo::getBundleInfo() and while not common in core/contrib, we should maybe find a way to support entity types without bundles too. We don't have too much many of those in core, menu links is one example, but that's tricky to add here anyway. We don't have a standardized way for bundle descriptions nor add links I suppose.

As an alternative to that declarative approach, we could just consider a hook and let other modules add their own sections here "by hand", might not even need to be content entities, could be anything sites consider to be things their editors typically add.

AaronMcHale’s picture

I really like the concept screenshot in #94, I'm not sure how I feel though about the "Other entity types" but I think that's on a really good track. One of the challenges of this issue is fitting everything into the toolbar, but if the "Add" toolbar link simply takes you to this page then I think that's a really good path forward!

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work

Tried testing but didn't get too far

Clicking the "Add content" link throws a fatal error

AssertionError: Cannot load the "shortcut_set" entity with NULL ID. in assert() (line 261 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

cleared cache multiple times but no luck.

But to echo #96 like the idea of going to a single page. Think it's a very clean approach and addresses the goal.

Thought about cleaning some of the tags but didn't know what was needed for this initiative.

yoroy’s picture

What I think I'm reading here:

A single url/page as the location for presenting "things you might want to create" would provide a good "UI-infra" basis to build from.

On which items to get there and how to get them there: #2377543-96: Add "Add" item to toolbar., I like the thinking in the last paragraph:

we could just consider a hook and let other modules add their own sections here "by hand", might not even need to be content entities, could be anything sites consider to be things their editors typically add.

This sounds like a nice approach that leaves things open for contrib to experiment with, which would be a plus I think. Leaving it to the architectural experts to come up with the right technical implementation for this :)

The mockup in #2377543-94: Add "Add" item to toolbar. would already be a good ux improvement as is. I'm thinking about additional features to star/promote items so that they show up as a select list under the "add" in the toolbar etc. But we would still want to introduce this basic page first. Lets focus on that.

tim.plunkett’s picture

Issue tags: -Field UX

Removing tag for now