Modifying the admin menu: site building examples

Custom block library
1. I duplicated the Custom block library and placed it as a tab on the content page.
2. Future editors of the site needed to edit individual custom blocks. By default users need access to Structure & Configuration to get to the that page, but that would just have cluttered up their admin menu with lots of additional items. It would have also allowed them to break the site by messing up the block layout page.
3. I wanted to add it as a menu item, but that would have not been visible when users would click on Content.

For a lot of our projects, we tend to create the custom admin screens under an admin menu link for a very simple reason: It's all in one place, so the client has an easy time administering their site.

This tends to look like:

• My awesome company > Site copy
• My awesome company > Notifications
• Etc.

Content of a custom entity type
1. I added a tab on the content page with a view of the content of a custom entity type (similar to that of content type content).
2. It's content and that's where editors of the site would be looking for it.
3. Ideally this would have been a sub-menu item under "Content" but that would then only been visible if the admin toolbar is used vertically, not horizontally, and it wouldn't be visible on the Content page.

We manage our homepage using custom blocks of content. We have 4 major areas of the homepage on palantir.net.

I moved the block lists, creation actions, and a preview view into the Content menu, also using Admin Menu, to make it easier for our content editor to find things.

It's under Admin > Content > Manage Homepage and I just did it through the Menu UI.

Usually we create little blocks where end users can find the "stuff" they need for their role:
Also we add more sub menus under content to manage the order of weight in views.

Here we see all options an admin has in malariaworld.org

I change Admin > Reports > Top 'access denied' errors (and the matching Top 'page not found' errors) to "Top 'access denied'" and "Top 'page not found'" instead. Why? Because of all the menu items that show up in a sidebar, they're one of the few that wrap the most ugily (with "errors" on the next line, compared to every other item in that group being a single line). It is the most common tweak I do, and is so OCD that I've not told anyone until this issue ;)

The admin navigation defaulting to a top/horizontal bar is probably another one I'm always tweaking (to be a sidebar instead). Monitors have gotten wider over the years, and text reads better at shorter line lengths. So defaulting the admin menu to the sidebar, instead of a topbar, a) gives more height to the content, when height is at a premium, b) gives less width to the content, when width is demonstrably harmful for reading, c) saves many clicks, as the sidebar supports hierarchy exploration without page load (i.e., being able to click a parent menu item and see its child menu items).

I often add one or two links to primary content types under the 'Content' section, and I ALWAYS install the Admin toolbar module. It makes the horizontal layout (which doesn't mess with themes too terribly for poor people like me who work on tablet, desktop, small, giant, mobile, etc. screen widths) very easy to use.

+1 for the Admin toolbar module (plus its submodule to get the link for flushing caches). Making it possible to drill down through the submenus is invaluable, and easier access for flushing caches too. A usability problem there though is that we find people want to continue drilling down to the 'leaf' links, when sometimes they need to click a parent link (e.g. to edit a content type, as the leaf links there are for the other local tasks for a content type, not its main Edit tab). That's a common problem, made bigger when we introduce custom listing pages (e.g. 'advanced user search' with extra exposed filters for certain roles, or type-specific content overview screens), as the original listing pages at /admin/content or /admin/people are not leaf links. So I'd sometimes try to add additional links another level down to compensate, but that's not easy.

We often add a bespoke top-level link to contain bespoke settings that will be unique to a client/project too. I realise that's not something that can be done generically, but it is because the current split between Structure/Configuration makes it hard to fit some settings into without losing them into the depths of the IA, whereas the simple approach of a top-level item gets around that for a specific commonly used settings page. No idea how it could be implemented, but maybe there could be a way of showing 'most/recently-accessed admin pages', regardless of which top-level item they were under? (Probably per-role, or even per-user.) So a bit like the Shortcuts tray, but dynamically listing the most useful links rather than requiring users to set them. Just an idea :-)

+1 for using admin_toolbar, though we often disable many if not all elements under the 8 icon from admin_toolbar_tools, since they do not serve an end-user use case and our developers have started using Coffee for admin tasks in the UI. We are considering disabling that menu item entirely.

We want to keep admin_toolbar_tools since it enables the fly-out under 'Add content' and other places. We also use patches to hide all inaccessible main menu points since they are not yet hidden perfectly. What we do not have a solution for is easy access to creating new nodes if you have over a dozen content types, since they don't fit on the screen. You have to use the "Add content" page in that case.

We also often put client-specific views or controllers under Content or under a separate main menu entry, if need be, and try to avoid building role-specific dashboards. In that configuration we then uninstall the shortcut module because it offers no benefit to an optimized fly-out menu.

We also uninstall the help module entirely since it does not contain useful end-user documentation.

Oh and environment indicator for showing the deployed release to the customer.

A good start: #296693: Restrict access to empty top level administration pages

For a content author it is a bit strange having 80% admin pages having You have no admin items.

We swap the main admin menu ("Manage") with a custom menu per user role. See this example:

I created a module to do this, called AMSwap (Admin Menu Swap).

We are currently looking for a lateral sliding menu with something similar to Magento 2 backoffice.
https://www.screenpages.com/wp-content/uploads/2015/07/M2-dashboard.png
I'm not very fan of Magento (in general) but I recognize its menu is really intuitive and well designed.

I don't know if it's already possible to do it, but it should be interesting that based on user's role, we could switch between different admin menus, eg:
- menu for site builder
- menu for editorial contributor
- menu for product manager
- menu for customer care

Hi droces,

thanks for the example and the screenshot. Could you give us a short explanation on why you do that, or what why you don't use the existing admin menu?

rtatoursbd:
Please don't change the priority of an issue; certainly not to "critical": https://www.drupal.org/core/issue-priority#critical
And please don't assign issues to yourself: https://www.drupal.org/node/2172049

@droces I've been searching for a module just like that thanks!

In D7 we always built a custom menu and administrative pages in views for our site editors to make things much easier to use. https://cl.ly/1B0s1t1n001e
We are still looking at what we want to do in D8, thus far we are using the Drupal admin menu and the Admin Menu module and moving menu items around. https://cl.ly/0X0i2v3j0s45

Our main issue is we typically want to give users access to some pages but not everything, either because we don't want them to break it or because they just don't need it and less is more. So we end up moving options up to the top level so they can access them. I will most likely start using the AMSwap module now that I know about it and build custom menus for me site admins and leave the default Drupal as is for me. Every sites needs are different so we like to tailor the admin experience to their needs with any superfluous bloat.

Thanks @droces for the new Admin Menu Swap!
In D7 I depended on Administration Menu Source (which I see you say this is "inspired by"). For D8 I resorted to using relocated shortcuts and no access to the D8 Toolbar for that role.

I have been using a custom menu or the user menu for my clients. Very interested in checking out the Admin Menu Swap! :) I have found over and over that people get very confused with admin menu items that are of no use to them.

@ifrik
I always customise the menu to suit the owners of the site (our clients) that will be using the site. Generally, I make a custom admin menu for each role. I make custom admin views for each content type, then add links to those views to their admin menu, along with a link to Users / People and Menu (generally just the main menu).

For instance, the owner of a law firm would have the links Pages, Articles, Documents, Menu, Users.

I used to do this with Admin Menu Source in Drupal 7, but since there was no version of it in Drupal 8, I decided to make my own. I didn't port the AMS module because of how the code would need to be almost completely re-written for D8 (maybe that's why it hasn't been ported yet), and because I felt I could do it more quickly this way, and could learn more in the process. My AMSwap module is very light-weight and simple (doesn't have any fancy features); it just does one little thing.

Looks like toolbar_menu does something similar and works with the Admin Toolbar module.

@jphelan I've fixed that now, so it plays nicely with Admin Toolbar :)
The (small) benefit of AMSwap is that it replaces the admin menu for the role, instead of adding to it. But you might want that; up to your use case.

Thanks jphelan, BastouBach, droces, echoz,
for bringing the attention to existing contrib modules, however this is not quite what this issue is about.

We are mainly looking for examples of why sitebuilders and developers change the admin menu for their clients, so that we can figure out better what is wrong with Core itself.

Can you tell us a bit more what your reasons are for not using the core admin menu; what the changes are that you like to do, but are too cumbersome in core; etc?

@ifrik I think the main reason is people need simplicity. In my experience end clients, who most of the time didn't build their website, are overwhelmed by the drupal-jargon, the numerous actions required to add/edit/delete something (even though it's sometimes 2 or 3 clicks away), the clutter of buttons they actually don't need or can't click on (when access is restricted), etc... It's sometimes to much for them and some of them even panic a little bit just seeing it all. Tasks that are easy to us are often very hard or to cumbersome for non-technical people. But it's those non-technical people who often need to pay the bill so we need them to be happy.

Some of them already have a lot on their mind (with their own business or whatever) and they don't want to have to think about how they have to manage their site. Certainly in times like now where they see on their facebook for example they only need to place their cursor in the edit area, type their message and save it. Boem: message is posted. In Drupal, they need to go to "Content", hit "Add content", choose content type and there it is: a textbox and a save button. (3 times more work)

Another small example: A slideshow with slides (content-type slide) who have an image, some text and a button that slides automatically. The usage of contextual links is not possible so an editor who wants to modify the slideshow needs to use the "Content" page to get to it. The site has a lot of content so to find the slide the editor has to use the filters to get to it. I've literally had a client panic over something just like this.

In situations like these it's much easier for them to give them an adminmenu with buttons to overviews for their main content-types (pre-filtered, a step less to worry about), sub buttons to add new content for that content-type (that pop out when you hover over the main button) and if needed some extra buttons to manage their main-menu, a taxonomy (which I rename because they've never heard that word before) and/or users for example.

The thing we need to realize is, those people aren't dumb, they just can't be bothered anymore. Time flies and things need to be/go fast and easy.

@hatznie Perfect answer! I couldn't have said it better myself.

We like to make the websites we build for clients so easy that they can't get it wrong! It's one thing I am proud to say Drupal trumps WordPress; the ability for us to make it a wonderfully-simple experience for clients.

I used to have training sessions with clients before giving them access to their website. These days, with custom admin views and a completely custom admin menu tailored to that client, we don't even need to do training anymore.

Honestly with the exception of #296693: Restrict access to empty top level administration pages, I'm not sure that there's anything "wrong" with core's admin menu. No admin menu is going to be perfect for everyone; like the rest of Drupal, it should be customizable and modular. I think, as @hatznie and @droces said, that a well-built site will include a custom site editor's menu tailored to their specific use case.

Core menu

This issue really is asking for issues with the menu itself, but most responses are related to the underlying menu structure.

Administration menu + fixes to the empty categories are must haves in core imho. This would tick off all of my issues with the menu on nearly all sites :)

But to emphasize the other points above, KIS for content authors. This comes to two main issues

1. Fine grain permissions
2. Role based context

So side issue blurb / ideas...

Fine grain permissions (side issue)

Visible menu items probably needs a future use-cases to try and find the best match of what site administrators/content authors (aka clients) and developers / site builders require. Core is suited to the site builders. SEO content authors are the other important audience.

Then each and every site is likely to require unique customization for the site administrators, particularly bigger clients / sites.

Some examples of Drupal 7 mods that were common

A modification of core permissions that we often make that affects the menu indirectly is to create new permissions and selectively grant these. For example, a new lower level permission, "administer site information", and alter the menu to allow some areas that use to require "administer site configuration" with this new permission. Or to alter menu items to hide items with a higher level permission.

Following that line, custom pages that cater for non-technical site admins, like a way for them to change safe configuration items like the site name, slogan and email without the other site building functions of default front page, etc.

Another two custom permissions that we are using less of as the SEO modules define their own more fine grain permissions "access seo content" and if required "administrate seo configuration", i.e. to alter the permissions to separate the seo content entry and the seo administration pages.

i.e. XMLSiteMap, we grant the admin xmlsitemap to site admins allowing access to the content configuration, and then alter the menu items in the admin area to something the clients don't see but site builders do. Each client has different skills so different needs here.

Avoid the need to use it altogether!

Generally it is possible to actually remove the need to use the menu in many cases.

Contextual links
With work, you can get these on all editable items with a bit of effort, use custom view modes instead of fields for sliders, etc. It does get harder with say users listings in D7, entity info alter + adding your own links required.

Local tasks
Alter these to provide add xyx tasks when in xyz context. i.e. on a news listing pages, show an add news item task :)

admin or published
On your views switch out published only for this and clearly indicate that unpublished items are unpublished

Then dashboards, shortcuts, etc could be considered, but chances are, there is not likely to be the need. 90% admin from the content itself and the menu is only likely to have 10-25 items & those for adding the content (terms, content, menus) so it isn't overwhelming.

I've always found it odd that the user entity fields and display settings are under configuration and not people.

jphelan,

are you changing the admin menu to fix those menu items that you find confusing?

I typically don't give clients access add fields to users so no. I think the menu is fine for me or site builders and I want to have the full unaltered menu as is. However, I do find that for my clients, either things are confusing, or they can't access something in structure because some other permission is hiding the menu altogether or things are so much simpler on their side I really just need everything under three categories like Content, Users, and Settings. Which is why I have a simple module like droces' amswap that places a different menu in the menu bar for their admin role.

I like to add a "Content and pages" section to the admin menu. This has list / create sub-items for each content type that the editor is likely to need, grouped by content type.

Despite training, it does seem to me that site editors are either unaware of, or cannot find the Manage > Content list that is in the standard admin menu. If they are looking to add say, a blog post, they naturally scan the top level of admin links looking for something to do with blogs, and none of "Manage", "Shortcuts", or "username", fit the bill.

Assuming they do then click on "Manage", again there's not an obvious option in the sub-menu. Yes, there is a "Content" link - but that's apparently not explicit enough.

@Leo Pitt I totally agree with adding a top-level link to content. That's something I've done as well. And since there are few top-level links it does seem like it's worth considering core putting it up there.

Seems obvious to me that there is work to be done with regards to blocks in general but in this instance the stand-out problem was that editing blocks is a content moderation faculty but the custom blocks edit UI is under Structure which leaves us in a pickle if we need to assign perms to someone to edit block content but not manipulate the layout. As per Clara I've duplicated the blocks edit ui on the content moderation screen. We need more granular permissions for block editing and movement of the UI into content moderation.

We just starting using Drupal a few month ago, and so far we've got only 2 projects fully completed in production. The amount of support requests and the feedback from our customers convinced us not using the admin menu for editors or translators.

Our solution now is astonishingly similar to @droces, comment #18. The reasons why we changed it are mainly the same as those from @hatznie, comment #30.

I think the reason for most negative feedback is that the standard admin menu is focussed around developers and site builders/architects, but neither naming nor structure of the default admin menu is suited for editors/normal users/our customers.

E.g. blocks: We first explained the difference between content on pages (nodes) and global content in header and footer (mostly custom content blocks). But everyone of our trainees became silent when we told them "First go to Structure => Block Layout => Custom block library and then search for [Company address]" to edit the company address in the footer.
We then added a top level link to the custom block library and called it "Global blocks". In the next training the core sentence for the same task was "Click on [Global blocks] and search for [Company address]" and this time they just nodded.

Similar story for adding content: The default actions are "Content > Add content > (Select content type)". We removed the generic content view page, instead created a view page for every content type (e.g. "Articles", "Events" and "Products") and added them as top level links to the admin menu. Even though result is only one click shorter ("Event > Add event"), this and the new naming really worked well for us.

Side note A: We disabled quick editing / frontend editing because a) it interfered too much with our frontend design, and b) quick edit only works really good with the default default node > field structure (but our sites make heavy usage of paragraphs module, all images are media entity references, JS carousels, etc.).

Side note B: Our projects are rather small sites for small business, with rather flat permissions, so most editors are allowed to change menus and blocks too, not just nodes.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!