The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Creating this as postponed on #3318112: [PP1] Move "Block layout" from Structure to Appearance, and this issue will be reviewed at a future usability group meeting.
Problem/Motivation
Once #3318112: [PP1] Move "Block layout" from Structure to Appearance is done, there will be up to four primary local tasks under Appearance (/admin/appearance)
- List
- Block layout
- Update (if you have Update Manager installed)
- Settings
With both Block layout and Settings having additional local tasks under both of them.
Other modules may add additional local tasks.
This issue exists to take a more holistic view and consider whether:
- Does "List" make sense, would "Themes" be a better title? After all it's more than just a list, it's a landing page of sorts for installing, uninstalling and accessing configuration of themes.
- Does "Block layout" make sense? Yes technically you are laying out blocks in regions, but the term "block layout" feels a bit ambiguous, would simply "Layout" be a better tab name? Users who are familiar with Layout Builder know to navigate to the Layout tab to adjust the layout of content or the layout of an entire bundle (content type, etc). If #2924058: Discuss using Layout Builder to control full site layout and replace Block UI is done then that would further strengthen the case for this change. If you're a site builder and you want to move a menu from one region to another, does it matter that the menu is technically a block, probably not, you just want to move your menu to a different position on your site. "Block placement" was suggested in comment #2.
- Is the order of the local tasks appropriate? Why should Updates be before Settings.
- As noted in comment #2, it's worth being aware that the update local task could be removed in favour of a higher level "Update" tab in the toolbar, as a result of #3227564: Automatic Updates UX Designs.
- Other questions?...
This issue should be used to holistically implement any recommendations.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Comments
Comment #2
rkollerin regards of point 1. i agree as long as the top level menu item
appearancewas just about themes, the termlistwasn't perfect but made "sort of" sense. with the move of the block layout page into appearance,themesmight be the clearer pick. or are there other alternatives? but definitely a +1 for renaming the term listIn regards of point 2, i've posted a suggestion in the "rename the block terminology in the administration menu issue": https://www.drupal.org/project/drupal/issues/3318549#comment-14936752 . I would vote on renaming the title from
Block layouttoBlock placementinstead. It is slightly longer but from my point of view clearer what the actual task is that is taking place there. as mentioned in the linked comment the term layout i usually associate with the ability to actually decide about the layout of something and its actual design. but on the block layout page you actually decide where you want to place something. and if you take a look at the help text on the appearance page the first two words already provide the queue what the more suitable term might by leading in with "block placement" imhoin regards point 3. i am not sure. i agree that
updateshouldnt be placed beforesettings. but i wonder with the currently called block layout tab, being nitpicky, what doessettingsactually refers to? what does appearance stands for now and what would its settings be about (an observation just based on the naming - for me personally it wouldnt be clear). i wonder would another order be more logical? 1. themes 2. settings (because those settings are in the context of themes - theme settings would be clearer) 3. block layout (or block placement) 4. updateand in regards of the update tab. the work of the automatic updates initiative has also to be taken into consideration. they have created ux designs #3227564: Automatic Updates UX Designs about potential changes to the admin interface that should also be taken into consideration or at least kept in mind.
Comment #3
aaronmchaleComment #4
aaronmchaleYeah I do like "Block placement" better than "Block layout". Have added that as an option to consider as well.
Yeah "Settings" could also be quite vague, maybe "Theme settings"? If the first tab was "Themes", then the second was "Theme settings", that could make the relationship really clear. "Theme settings" is technically shorter than "Theme configuration" and may be more familiar to users, who are used to seeing the term "Settings" on computers and phones these days. Worth keeping in mind actually for #2534140: Settings vs. Configure for UI text?.
Of course "Settings" is the shortest of them all, and we do follow the philosophy of less is more, but that should never come at the cost of the users ability to understand what the relationship is between items.
That is a great point, if there is a more unified "update" UI then that could remove the update local task and I would fully support that idea!. I have added that as a point to the summary.
Comment #5
aaronmchaleThinking about it more, what if we were to follow the pattern of Field UI and completely flip the navigation pattern. So isntead of having local tasks for items like "Settings" and "Block layout", with tabs for each theme under them. Like how with bundles, you edit a bundle and within the bundle settings you have the "Manage fields", "Manage display", etc. local tasks.
If we followed that pattern here, that would mean that the "Settings" link on each theme would take you to a page that had local tasks for "Settings" and "Block layout" for that specific theme.
So just to quickly mock this up:
Here is the Appearance page, but with no local tasks:
You click the "Settings" link for Olivero, you get to the same theme settings page, but the local tasks now appear and are specific to Olivero, with "Theme settings" and "Block layout". Much like with configuring a bundle or field you stay within the context of Olivero when navigating between the local tasks. Also notice I changed the Breadcrumb to reflect that the next item up is back to the Appearance page.
This could actually be a much better pattern, because let's say when you install a theme, you go into the settings screen, you have access to everything relevant there.
This could also be a good pattern for some more complex themes which try to cram a lot into the Theme Settings form, this opens up the possibility for those themes in the future to add their own local tasks and simplify their theme settings. That would probably require some changes in how themes set up their settings though, but I think it would be a huge win from a UX perspective.
The only thing I'm not sure is what happens to the "Global settings" form, but I feel like we could find a suitable home for that, maybe that has a button in Appearance. Maybe it even moves out of Appearance completely and into Configuration, which is where you usually expect to see "global" settings anyway.
Comment #6
aaronmchaleI hadn't properly closed the
<ul>.Comment #7
gábor hojtsyMoving to 11.x as per https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-.... If this can only be done in a major version, then a [11.x] title prefix should be added and a "Major version only" tag too.
Comment #8
aaronmchaleI actually don't remember why I created this against 11.0.x, it was probably because of the huge potential for BC-breaking URL changes.
But now that we have #3333383: Create a redirect for the new Block types path done which established a pattern for making BC-compatible URL changes in the admin UI, I don't see a clear reason that this can't be done in a minor.
So moving to 10.1.x.
Comment #10
quietone commented