Admin Materials and Surfaces

As we further develop the primitives that make up the overall admin system (#53322) it seems important to map out the main elements that compose it. This issue focuses largely on how things might work and how things are structured, not how they look.

We'll start, for the sake of the presentation, with defining Materials, Concepts, and Screens. Materials are the places where Concepts are rendered; Concepts are the interfaces for the various items a site needs to represent; and Screens are the dedicated routes that bring them all together and construct the various user flows.

The terminology is just an instrument to help us break things down. The main thing to capture here is that the admin is composed out of a few shared pieces to account for the needs of extensibility, personalization, flexibility, and consistency.

The Materials

The overall Admin user interface is composed of a few core materials, grouped into Base, Surfaces, and Overlays.

Base

This is the base layer of the interface. It can change colors between light, dark, or user defined color palettes. The base layer contains the following items:

Surfaces

We define three main element that build up the various layouts of the admin screens.

Canvas
The primary area for previewing and editing content (e.g., block editors).
Stage
Harbors either a Library of items (posts, pages, media, products, orders, patterns, fonts, etc) or Settings. This is also the main area for plugins to develop more customized interfaces.
Inspector
Is meant to be a narrow (possibly fixed) width element for quick edit panels, style panel, editor inspector, plugin sidebars, etc.

Overlays

Includes modals, preferences, dialogs, and interfaces like command palette.

The Concepts

Each surface can bring together a set of reusable, high-level concepts. These are primitives that define structure and functionality. Most of these already exist in code and have been the main focus of development as they tie in with the component and design system in encapsulating functionality, user interaction, accessibility affordances, etc. These are not meant to be exhaustive, just a high level grouping of the most common elements.

Navigation
Menus (dropdowns, drilldowns), drawer, tabs, item groups.
Collection
Lists, grids, tables, and alternate layout representations of DataViews.
Forms & Settings
Structured fields, validation, form layout (e.g., DataForm, ToolPanel). (Fields API meets component system.)
Block Editor
Context-specific editors for entities like posts, templates, and patterns.
Widget
Small units laid out in a grid that connect with various functional components to create a personalized dashboard experiences.
Inserter
UI for adding new blocks, new post types, new templates, etc.

The Screens

With these building blocks in place, every Admin screen can be declared as a layout incorporating these surfaces and concepts. This modular approach helps us ensure consistency, flexibility, scalability, and clarity across the entire admin and plugin experience. The layouts themselves are not fixed but starting points, since they can be reconfigured by plugins or by the user through data view configuration.

Illustrative example: Pages...

These are a few wireframes of how it comes together for a specific screen like "Pages" and all the ways in which it can be configured.

List view with canvas showing full template preview.

List view with canvas showing abstracted template preview (template is hidden, it only renders title and content like the default editor).

Table view

Table view with quick edit / bulk edit open.

Grid view with quick edit / bulk edit open.

And the way we would describe this as a layout is something like the following:

Pages:
    Stage: Lists + Inserter + Tabs
        Default: List, [Table, Grid]
    Inspector: quick-edit
        Default fields: [ Title, Slug, Parent, [...] ]
    Canvas: block-editor
        Default view: Template, [Abstracted View]

Important

This is meant to be an ongoing working draft as we refine these elements.

Thank you for posting this high-level view of admin area work. From the view of a small business site builder, the admin UX is critical to WP’s future adoption. My "regular people" clients need a flexible, useful, efficient, and beautiful UI or they just won't use it. I assume the same is true of DIY people on both .org and .com.

You said:

Stage
Harbors either a Library of items (posts, pages, media, products, orders, patterns, fonts, etc) or Settings. This is also the main area for plugins to develop more customized interfaces.
Inspector
Is meant to be a narrow (possibly fixed) width element for quick edit panels, style panel, editor inspector, plugin sidebars, etc.

Please, I beg you, do not make the sidebars fixed - on either side. Unlike us, many who use WP's admin do not have multiple, large screens available when they work. Not being able to adjust the width of the sidebars in the admin now is a real frustration I hear about WP’s admin interface now. They want to be able to make the List View wider or narrower by dragging it - and I have to agree. Dragging the width of an element on your screen is expected behavior.

Also, please address the lack of support for right-click or cmd/ctrl+click to open new tabs within the newer admin screens. This forces users into a single-window workflow, which is frustratingly inefficient for many users. And again, this is expected behavior on the web. While this may be a complex challenge, addressing it would significantly improve the user experience.

These suggestions might seem trivial to you, but I promise, they matter to new adopters. If "regular users" don't feel like WP is a pleasant, flexible, efficient, and user-focused experience for them . . . they will fade away to other platforms.

How does this affect those of us who want to disable Gutenberg and use WordPress for the PHP functionality it can add to a HTML site?

I appreciate the systematic approach here and look forward to how it can combine with potentially an API, or more extensible menus for the side panels and other pieces. That way truly any interface can be created, all from the same system, which creates a better experience for everyone.

They want to be able to make the List View wider or narrower by dragging it - and I have to agree. Dragging the width of an element on your screen is expected behavior.

I think this is a discussion to be had in the side panel issue, but I would consider debating this for the sake of a consistent experience and collapsible panels. Often we think people need more customisation than they do and it frequently is a case of being able to transition, close and easily navigate back. This is why many interfaces today are removing adjustable panels and opting for collapsing.

This all said, there is a lot of discussion to be had section by section reviewing the experience, it starts with the materials and surfaces, though and refines down.

Please can we seriously consider how this aligns with existing APIs, such as the Settings API, when rendering options pages. Given the extensive plugin ecosystem, if help vs requiring plugin authors to redo all their code in JavaScript as we currently have with the block editor.

This layout seems to be based on a block theme framework.
What about the majority of WordPress users who aren't using a block theme?
Is WordPress just ignoring the majority of users and developers in future development efforts ?

This layout seems to be based on a block theme framework. What about the majority of WordPress users who aren't using a block theme? Is WordPress just ignoring the majority of users and developers in future development efforts ?

Continuity is important, but let's face it.. the "majority" of WP users are older people like yourself who are fiercely resistant to change. You could fork, but then you need the minority to slave away in providing critical security and performance updates to an increasingly outdated system. The technical debt to keep everything like text: static and the same, is quite unsustainable. A more sustainable metric would be realtime traffic, rather than the number of websites people no longer visit. Ignore the Abstract Majority you mentioned.

Based on the aggravatingly fixed page/block sidebar in the current Block Editor I have to agree with others here that more flexibility would be extremely welcome. It's objectively the most-used UI element when creating or editing content. For anything more complex than a simple page, or core paragraph block, users already have to do quite a lot of scrolling and accordion-opening. Increasing flexibility in that sidebar would be particularly welcome.

I like it 🔥

I can see some issues for UX later on but I think we can refine those UI UX stuff really faster later on.

I think this is a really bad idea.

The first push was the block editor. I am managing 400+ websites, and all of them use either a classic/regular theme, or a hybrid one.

The second push was the draggable metabox drawer, which was quickly removed after lots of protests, but it might come back in a future release.

Is this the third push?

How many of you are regular users, or how many of you are small business owners who need to manage their website in a comfortable, familiar way? I bet none. WordPress should be a familiar CMS (like it's been for decades). Don't bring this JavaScript nonsense. Improve, or simplify, the current UI. Better (SVG) icons, improved typography, updated code (PHP 8+), vanilla JavaScript for minor interactions (where CSS is not applicable).

Intro: Corporate (Gutenberg, Page Builder and Classic Sites) and also small business like / private WP Dev/Admin here.

I am managing 400+ websites, and all of them use either a classic/regular theme, or a hybrid one.

WP 5.0 with the new (Gutenberg) editor has been released in December 2018 - that is nearly 7 years ago.
In the company I work for we also have some "classic" sites left, but Gutenberg is here to stay - and I'm glad it is.
In this 7 years it has matured a lot - of course not like 20+ years of WordPress.
But to stay relevant WP has to evolve - hopefully with less drama than the editor release this time.

I like this new admin approach so far - which can be kind of tested already in the site editor. Great work.

who need to manage their website in a comfortable, familiar way

The current admin is a mess! Mostly triggered by missing unified solutions and flexibility, that the new admin is (hopefully) trying to tackle.

Most plugin authors showcasing their menu item on the top level in the sidebar, even when it is just some settings you don't change regularly.
Also a lot of plugins are implementing their own settings page style and therefor different plugins have completely different settings pages. Neither comfortable, nor familiar.
And as dev who wants maybe shared settings between sites you have to hope that the plugin author supports this or you have to figure out how the plugin works - manually for every plugin.
And not to speak about admin notices which too often get misused as marketing banner.

So my hope is for more and easy to use standards (and the reuse or something similar to the Settings API).

It is easy to just complain, but don't forget that you have the opportunity to participate.

Please, I beg you, do not make the sidebars fixed - on either side.

I will mention that last year I built a plugin that allows for declarative custom meta fields as JSON rendered with core WP components (as a sort of lightweight alternative to ACF). They default to the post settings sidebar and even nicely sectioning them out into panels, the number one request I got from users was to "move as many fields to the left (out of the sidebar) so we have more room" 😭. I am sure it would be more substantially more complex to style components to support that full flexibility but Container Queries are here and can really help if everything is resizable.

Speaking of "declarative custom meta fields as JSON",

Fields API meets component system.

I am quite interested to see where this goes.

Overall this looks like a good direction, I'm excited to see more of what's next for building in the admin. I've built out several admin pages for standalone plugins with react and all the premade components, wp-scripts, hooks, are really fun to work with but I do find myself wishing for some standard layouts. I have based my custom settings pages off of the Site Health section which feels just right for the amount of tabs and controls I have. I suppose that would fit in to the "canvas" category outlined here. It might be nice to integrate with the Settings API somehow (as mentioned above) and allow for some pre-made bits to be added automatically.

WP 5.0 with the new (Gutenberg) editor has been released in December 2018 - that is nearly 7 years ago.
In the company I work for we also have some "classic" sites left, but Gutenberg is here to stay - and I'm glad it is.

This doesn't make it less a mistake. You only need to look around you: how many websites are using the Classic Editor plugin, the amount of 1-star reviews for Gutenberg (before they are being removed by the plugin review team), and, and... everywhere else, to be fair.

That's why everybody is here, to steer it back to the right path.

There is no place for ReactJS in the admin area. PHP/HTML and CSS is enough. Vanilla JS for minor interactions.

There is no place for ReactJS in the admin area. PHP/HTML and CSS is enough. Vanilla JS for minor interactions.

That's the perfect way to make sure WP stays in the past.

I love this from a conceptual perspective. The materials and surface composition are easy enough abstractions to grasp, and more importantly, they are useful ones. It's genuinely a unique take on what modern site editing and publishing should be. Although it's unique, I do also see some influence from Squarespace's admin experience, which is a world-class experience, so I'm not mad at that.

Again, conceptually, I love all of this! I, for one, am over the current WP admin.

That being said, my concern is how this will be implemented. Let's get into that.

Rewriting the entire WordPress admin in React is a flat-out bad idea... For WordPress.

Here are several reasons why:

React’s long-lived, but no longer leading status: The JavaScript ecosystem evolves rapidly. React, now over a decade old, remains widely used, but newer frameworks like Solid, Svelte, or Qwik are leaner and often more performant. Committing WordPress’s admin to React risks locking us into a technology that may feel outdated midway through a major migration.
Poor React adoption in the WordPress ecosystem: Gutenberg was meant to attract large numbers of React developers. Instead, adoption has lagged. Most plugin and theme developers stick with PHP, jQuery, or lightweight JS. If React couldn’t gain traction merely with block development, a full-blown React admin rewrite is unlikely to succeed in talent adoption.
PHP is enjoying a renaissance: With PHP 8+, features like JIT, strong typing, enums, and attributes, plus modern frameworks like Laravel and Symfony, deliver powerful, developer-friendly PHP experiences. Ignoring this momentum in favor of a React-first admin diverges from broader PHP ecosystem trends and developer skills.
Multi-Page Apps (MPAs) can deliver rich interactivity: A lot of the rationale for React in 2015 was about SPAs being the only way to get a “modern app-like feel.” That’s just not true anymore. Laravel’s Livewire, Rails’ Turbo/Hotwire, and libraries like htmx or Alpine.js show us we can deliver rich, reactive user experiences while keeping the traditional server-rendered MPA model. This keeps things simpler, more accessible, and most importantly-closer to the PHP-based developer base that WordPress already has.
WordPress’s superpower is backwards compatibility: Thousands of plugins and extensions rely on the current admin architecture. A wholesale rewrite in React would be catastrophic for compatibility, fragmenting the ecosystem and forcing plugin authors to rebuild massive swaths of functionality. We would risk breaking trust with the developer community who rely on “the WordPress way” being stable and dependable.
Maintenance cost and contributor fragmentation: WordPress thrives because thousands of contributors can jump in and meaningfully contribute, whether they’re PHP developers, front-end builders, or plugin makers. A React-only admin narrows that funnel to a more specialized, more JavaScript-heavy, framework-specific skill set, potentially shrinking the contributor base. That’s not a recipe for longevity.
The user experience can be modernized without a nuclear option: Improving the design language, unifying patterns, and layering in progressive enhancements with modern JS where it makes sense is a far more sustainable path. We can ship a “modern admin” without burning the house down and without cutting off vast portions of our developer community.
Modern CSS now packs a serious punch: Features like CSS Grid, enhanced layout systems, custom properties (variables), scrollbars, blur effects, and more add flexibility and visual polish to interfaces all without heavy JavaScript or frameworks. The CSS View Transition API (via document.startViewTransition() and the @view‑transition rule) allows smooth, built-in transitions between page states even across page navigations without JavaScript animation frameworks. It’s supported in Chrome, Edge (same), Safari, though Firefox remains the last holdout.

A Better Proposal

Focus on an incremental modernization strategy using:

Modern PHP-driven architecture (Keep the “the WordPress way”)
Interactivity via the WordPress Interactivity API (introduced in WP 6.5)
A fresh, unified design system (Already in the works)

Why the Interactivity API fits the bill

Native WP integration: Built in since WordPress 6.5, with no need for external frameworks
Declarative and hypermedia-aligned approach: Uses HTML directives (e.g., data-wp-on--click, data-wp-bind--value, etc.) for interactivity conceptually similar to HTMX, but purpose-built for WordPress
Optimized performance: Ships only minimal JS (via Preact as fallback only when necessary), keeping page weight low
Backward‑compatible design: Works with existing server-rendered blocks, themes, and plugins without breaking the admin flow
State & interaction out of the box: Offers stores, state, actions, and callback patterns helping build interactive components like accordions, live search, filters, lightboxes without React complexity

How this could look in practice

Adopt a new UI/UX design system - modular, accessible, and themeable.
Incrementally refactor admin UI components into modern PHP-rendered templates, styled via the design system.
Layer interactivity gradually -where richer interactions improve usability using the Interactivity API’s declarative directives.
Maintain plugin compatibility -existing hooks, filters, and structures remain intact.
Engage the dev community - encourage contributions using familiar PHP flows rather than demanding React expertise.

This hybrid approach respects both the core strengths of WordPress (backward compatibility, PHP-centric workflows) and the given need to modernize admin UX. It also aligns with the ethos of hypermedia-driven enhancements without overhauling the entire stack.

In summary: A full React rewrite may look cutting-edge, but it threatens the broad community, the ecosystem, and WordPress’s future sustainability. Instead, modernizing via PHP + Interactivity API + modern CSS (including View Transitions) preserves backward compatibility, performance, and accessibility while delivering a polished, modern admin experience.

I made these assumptions with the understanding that React is the framework of choice for driving the admin redesign, given that Gutenberg is built on React. These things may already be being considered; if so, then I said all of this for nothing, lol.

Either way, it needs to be said, especially as someone who has been on the bleeding edge of building things for Gutenberg. It's been an umm, unpleasant experience.

To say the least.

@GlentonCo

Kind of totally agree with @GlentonCo. I do cheer for an admin revamp, getting the admin ready for the next miles. Though hope sincerely we will not repeat mistakes made with GB.

While I do see the editor is/was a special use case (with theme builders already overriding it for over a decade with their own custom-built flows), the admin is not. It needs to be as backwards compatible as possible, for as many as possible, with as little overhead in doing so while building.

And, please do not forget while choosing the 'how' to build the new admin: the JS simply needs to be as unobtrusive as possible for any main admin task.

Any single stupid JS error will stop the browser rendering/responding. And we do know a lot of sites have a lot of plugins running on them. Not all having the same JS quality. Being able to update a plugin without JS has actually saved me a lot of times, even recently. When JS breaks, we'd still need the admin to function.

(Sidenote, though may be core in the discussion of how to build the revamp: guarding backwards compatibility in the backbone the admin is, is simply respecting the Free. Do think one can feel this freedom being taken away when breaking changes occur unexpected or too often, as you can not have the freedom to modify/build on any software when you know/start to suspect it will break soon-ish rather than later.)

A full React rewrite may look cutting-edge, but it threatens the broad community, the ecosystem, and WordPress’s future sustainability. Instead, modernizing via PHP + Interactivity API + modern CSS (including View Transitions) preserves backward compatibility, performance, and accessibility while delivering a polished, modern admin experience.

100% all of this. The block editor being built in React has already driven away a large number of existing WordPress developers and exponentially increased the barriers to entry for new ones. Let's please recognise that this was a mistake and do better with the admin, rather than double down on what is clearly a broken approach.

In support of a modern Admin — without leaving PHP devs behind

I’m fully behind the Admin redesign and the Block Editor direction. The legacy Admin is objectively dated and pushes users away. A standardized, extensible Admin (Materials → Surfaces → Overlays; Canvas/Stage/Inspector) is the right foundation. Let’s pair that with a PHP-first developer experience and progressive enhancement so we don’t lose the ecosystem that made WordPress thrive.

Why this matters

End users first. Cohesive layouts, predictable settings, and consistent patterns are how we deliver a “pleasant, flexible, efficient” UI. The current Admin can’t get us there.
Developers are also users. After 20+ years leading teams and shipping WP at scale: React developers rarely pick WordPress; the natural contributor base is still PHP developers. If we ignore that, we shrink the tent.

A practical path that meets both worlds

1. Keep PHP at the core, enhance progressively

Server-rendered screens + Interactivity API for rich UX. Use React where it’s the best tool, but don’t require it for every screen.

2. Ship a declarative “Admin Schema”

A small, well-documented schema that describes a screen’s structure (Stage/Canvas/Inspector, Collections, Forms, DataViews, etc.). Think of it as the contract between PHP and UI.

// functions.php or a plugin
register_admin_screen('pages', [
  'stage' => [
    'collections' => ['list', 'table', 'grid'],
    'inserter'    => true,
    'tabs'        => ['All', 'Drafts', 'Published'],
  ],
  'inspector' => [
    'panel'  => 'quick-edit',
    'fields' => ['title', 'slug', 'parent'],
  ],
  'canvas' => [
    'type'  => 'block-editor',
    'view'  => 'template', // or 'abstract'
  ],
  'behaviors' => [
    'resizableInspector' => true,
    'allowCmdClick'      => true,
  ],
]);

Or JSON if you prefer config-as-data:

{
  "id": "pages",
  "stage": { "collections": ["list","table","grid"], "inserter": true, "tabs": ["All","Drafts","Published"] },
  "inspector": { "panel": "quick-edit", "fields": ["title","slug","parent"] },
  "canvas": { "type": "block-editor", "view": "template" },
  "behaviors": { "resizableInspector": true, "allowCmdClick": true }
}

3. Provide a PHP wrapper/configurator à la Redux-style DX

Not to copy Redux, but to emulate the packaging and mental model: clear APIs, great docs, guardrails, presets, and instant results. Examples:

register_admin_screen(), register_admin_form(), register_admin_collection()
Opinionated presets for common screens (Posts, Pages, Media, Products)
Auto-wiring of validation, capability checks, and accessibility

4. First-class migration adapters

Settings API ↔ Fields API mapping layer so existing options pages can render with the new concepts.
ACF/Redux/Meta Box adapters that read existing field groups and emit Admin Schema.
DataViews adapter for custom list tables → Collections, including bulk/quick edit.

5. Tooling that respects how WP devs work

WP-CLI scaffolds:

wp admin screen scaffold --schema=pages.json

Codegen & AI assistant: Feed schema, get PHP/JS templates, WP-components wiring, and test stubs.
No-JS fallback: Core tasks (activate/deactivate/update) must remain operable if JS fails.

6. UX details that came up in this thread

Resizable sidebars/inspector and right-click / cmd-click to open in new tabs.
Consistent keyboard shortcuts and sticky submit for long forms.
Collapsible panels with sensible defaults for simplicity and consistency.

Why this balances risk and progress

Backward compatibility: PHP remains the backbone; React is additive, not mandatory.
Lower barrier to entry: PHP devs can be productive on day one using the Schema and wrappers.
Future-proofing: If/when UI tech shifts, the Schema contract stays stable.

Bottom line

Let’s modernize the Admin and embrace the Materials/Surfaces/Overlays model—and give developers a PHP-first, declarative, Redux-quality DX plus codegen/AI helpers to make building screens fast, consistent, and fun. That’s how we keep users happy and the ecosystem vibrant.

Thank you so much to those contributing ways to modernize without forcing more classic users out.

I've used WordPress since 2007. I loved it so much that I started the WP Builds podcast with Nathan Wrigley. After 8 years I had to quit as I was in the same position as the W3C. Gutenberg was not personally needed and it appeared we would have to convert at some point.

I moved to another open source project 11ty which was perfect as I wanted to focus on learning "modern" HTML and CSS.

But having WordPress sites, friends and a strong emotional connection I would still dearly love it if my present video, podcast and sharable content could again feature WordPress.

Perhaps I am making my own purgatory holding out hope I can stay with WordPress?

I can see the points being made here, and some are quite strong and compelling. For me, a big everyday UX pain point with the current state of affairs is that switching from the classic Admin to the Site Editor means switching to a totally different app, which is not only jarring, but also slow.

If we follow these proposals, wouldn't we end up doubling down on UX inconsistencies and arbitrary separation points in the admin area?

Does this mean more react bloat?

Anyway, as a PM, I strongly believe the real problem with Wordpress is with its UX, not UI.
As a team, you should try one of the actually popular builders and count your interactions (literally), and note your visual feedback, while building a typical Wordpress website.
Then try to do the same in Gutenberg and decrypt why it's behind. The same is true with not just Gutenberg, but many other facets of Wordpress.

Reduce unnecessary interactions, facilitate an easier workflow for the majority, stop collapsing options into different menus and bars, etc.
Making a prettier material theme will not impress the majority that are frustrated with the UX.
Bandaid fixes like this won't be enough. There needs to be some UX soul-searching.

I think we are getting a little ahead of ourselves here. The proposal is about the structure of the new Admin. By itself it's a good proposal. Well done! These are great foundations!

However, the big ~~problem~~ concern, and here's why everyone is mentioning the programming language intended to be used for building it, is the fear of how this will be implemented.

With Gutenberg this was implemented backwards. First the app was created, then compatibility was figured out, through several years (and it's still kind of disconnected). Resulting in throwing away years of consistent, and widely used APIs, and breaking a lot of things or even removing some from usage without a clear alternative path, while also significantly increasing the complexity for ~~using~~ integrating with the new Editor and associated components.

While breaking things is inevitable (and I would argue necessary from time to time), what I really want to see, and hope for, is one day updating WordPress and being presented with a new interface WITHOUT ANYTHING BREAKING (only possibly a few minor layout or style issues, but no functionality loss or fatal errors).

This is what made Gutenberg adoption so slow and dreaded by many in the first place. Not being able to use the hooks, filters, or existing plugins from the get go was really frustrating. Having to wait long periods of time for an alternative or implementation of an existing functionality, or even having to drop some functionality that was never reintegrated, and worse, having to go through several changes in methods as the project evolved, with such a huge increase in complexity, was the Achilles heel of Gutenberg.

What does it mean from a development perspective:

The new interface ~~needs to~~ should be capable of integrating seamlessly with all (not a few), existing APIs from the get go, and then offer a path for modernization through a better, modern, performant, and more flexible set of APIs, giving devs plenty of time to migrate without their plugins and themes breaking or without being able to use existing hooks and filters anymore.

The new interface should completely support all existing methods and render them without any issues, only perhaps in a limited (but not broken) capability to avoid conflicts (e.g.: no mutations and client-side actions if not using the new APIs).

If you make the switch without giving devs a clear and easy path to migrate without breaking their plugins, extensions, and themes, you'll create the same fragmentation we are having now with the slow adoption of Gutenberg and FSE. Nobody likes that.

If the new Admin isn't able to do this from the get go, then it'll fail miserably.

This means, building the foundation, creating a seamless interface between the two worlds, and offering an easy path to migrate.

Forget about React. It doesn't matter what programming language will be used to build the new UI. What matters and needs to happen is full backward compatibility without compromises. I want to be able to use the same hooks and filters, the same plugins that customize the Admin Menu, Admin Bar, Notices, etc., without losing the advantages of the new UI, nor jumping around between old and new interface.

I would have adopted Gutenberg from day one if it was built with backward compatibility, and a clear path for migration, and adoption in mind.

I hope the same mistake doesn't happen again.

@mtias

@mtias would be great if we could figure out a codename for this project.
Will help tag things related to this topic a lot.
Currently I'm working on the maintainership of the Posts component, and there are a bunch of ideas that no one will be happy to invest time in the current admin interface, knowing that the new admin is being planned. Having a common, timeless tag to group this kind of topics will help a lot more than just referring to “the new wp admin”

But having WordPress sites, friends and a strong emotional connection I would still dearly love it if my present video, podcast and sharable content could again feature WordPress.

Hi David. You were an important resource for me when I got back to freelancing in 2017. Back then I picked Beaver Builder to help, and you had some great info. I did see that you had moved away from BB and WP...or hadn't seen many videos after.

I too, held off on the block editor...but gave it a full chance about 2-3 years ago. I just couldn't go back to the classic editor now. Just recently I decided to give full-site editing another go. I'm now in the process of migrating all my sites away from BB to WP. I can still do custom HTML, CSS and add in code to the functions file (yes I still do child themes)

The point here, and with other replies, is that yes...change is difficult, but the productivity increase I've experienced has been amazing. There's no way I could go back to classic. And so...with the switch to editor and FSE...my main gripe is the admin section. It's a major gripe to my clients. What's more important in the end? Developers or the end users? Because if it's the former, I guarantee other platforms aren't caring about staying in the past.

Also...I'm not saying who cares about the developers. There's still a strong developer community for Wordpress. ACF is a prime example. They were right there from Gutenberg's day one....and I still use them.

I really appreciate all the work being done here, and enjoyed reading everyone's concerns, and I hope those concerns are taken seriously.

I wanted to chime in with some thoughts about approach...

I'm not sure if there's a technical term for it. But I'm concerned about this "foundations-first" approach. It's similar to the "implementing a design system too early" concern.

I suspect it's already too late because of path dependence - I understand people are already committed, so it's hard to do things differently at this point. Also, there's something about pretty primitives that feels reassuring, and the chaos of a "use case-first" approach (which I advocate for below) can feel unwieldy in comparison.

But regardless, I think it's worth mentioning that instead of approaching the redesign "foundations first", we should approach it "use case-first".

What is a use case-first approach?

The key point is to identify use cases and design for them.

Instead of designing abstract primitives, take some time to identify the 5-10 most common WordPress admins ("most common" can be replaced with whatever is the key criteria) and create mock ups of what the modern admin can look like for these people.

There are other ways of doing this of course, but this is what comes to mind for me.

Why adopt a use case-first approach?

If you've ever seen the square hole video meme, you'll know how the best intentions with a good foundation can quickly lead to disappointment. (Worth caveating for the nitpickers that the reddit thread I linked to says "devs watching qa test the product" but it's the same mentality for "devs watching users use the product")

The problem with the foundations-first approach is that anything makes sense in abstractions, it sounds very well thought out and looks very pretty. But it suffers from the "no plan survives first contact" problem.

In contrast, a use case-first approach skips straight to first contact. We see what is currently being done, and then seek to improve it.

Many startups have to build first (and even then they are told by mentors not to build too much before getting user feedback) and then fight tooth and nail to get user feedback, and change things along the way.

We don't have to do that.

We're in the enviable position of already having millions of users. I think figuring out what their daily use cases are and building with those things in mind is a much better approach.

What a use case-first approach could look like in practice

Caveat: This section is just an idea of how it could look like in practice. There might be better ways of doing it. The main thing I'm advocating for is a use case-first approach, not dogmatic adherence to the suggestions below.

We could start by showing screenshots of common WP admins - some with 10 admin notices and at least 20 plugins installed. We want to see different languages. We want to see different industries - lawyers, government agencies, hairdressers, food bloggers, local news, design agencies, and so on, sorted into buckets. We'd also make sure to consider the top 50-100 plugins and themes.

Then we would show before and after mock ups of how those same admins would look like with the redesign.

This sounds like a lot, but you really don't have to show 100 different mock ups. After doing the research, it'll become clear what the most common 5-10 WP admins look like.

I think getting support technicians and agency devs involved will be key, because those are the folks who are looking at different WP admins all day.

Then instead of having people argue about a completely rebuilt WP admin from the ground up, which understandably makes everyone nervous...

Have them argue about what they want and don't want based on those Before and Afters. Have them argue about how their common use case was not represented and have them screenshot/screen record their own WP admins as an example.

This might sound more chaotic (having to see 100s of WP admins), but it gives a much better idea of how people are actually using WordPress in their daily lives. And what all those people actually need.

And once we have a clear idea of what we actually need to build, we can go back to step 1 and figure out the basic elements and components we need on day one to get us there. And, in the case of the Square Hole meme, we would be able to know with some certainty that we didn't actually need multiple different holes, we just needed one square hole.

As an example, to me, the most valuable comment in this entire thread is this one. Because it advocates for "regular people" and talks about specifics like the WP admin needing to work on a small screen.

Maybe the proposed solution of resizeable panels might not be built, but it highlights the important reality that regular users are using WordPress on their small screens and might be something that needs to be considered right from the start.

I’m excited about the new admin design, I think it’s necessary.

However, I wasn’t convinced by the navigation approach presented in the initial proposals: #53322, Admin Design Kickoff.

This proposal makes navigation much slower, requiring many more clicks to move back and forth. The same issue exists with the Customizer, which results in a very frustrating navigation experience.

The admin area does need some problems to be addressed, such as giving us the ability to reorganize menus instead of letting plugins decide where they should appear and clutter the interface. It also needs a visual refresh. But what it doesn’t need is a completely new navigation experience, because as it stands, it is fast and excellent.

In terms of design, I think GitLab could serve as inspiration. Its sidebar panel and navigation are very similar to the WordPress admin, but with a better visual design. Below are some screenshots comparing GitLab and WordPress, where we can see a similar navigation system with a more polished design in GitLab:

@ricjcs

@ricjcs is the primary thing you're trying to point out with the GitLab screenshots is that they've got additional level of nested menus possible off the left hand menu? It's otherwise not immediately clear what you're trying to highlight if that's not it, so some additional clarity would be helpful, thanks!

@jeffpaul

Precisely, @jeffpaul. "They've got additional level of nested menus possible off the left hand menu", this makes navigating between menus faster, which wasn't the case in the initial admin redesign proposals. The navigation in GitLab is essentially the same as the current wp admin (it even allows the sidebar to be collapsed), but with a much sleeker design. That’s why I suggested it could serve as inspiration, the admin could be made more visually appealing and other issues could be resolved while keeping the same navigation structure.

Navigation Menu

Repository navigation

Admin Materials and Surfaces #70913

The Materials

Base

Surfaces

Overlays

The Concepts

The Screens

8 remaining items

Here are several reasons why:

A Better Proposal

How this could look in practice

In support of a modern Admin — without leaving PHP devs behind

Why this matters

A practical path that meets both worlds

1. Keep PHP at the core, enhance progressively

2. Ship a declarative “Admin Schema”

3. Provide a PHP wrapper/configurator à la Redux-style DX

4. First-class migration adapters

5. Tooling that respects how WP devs work

6. UX details that came up in this thread

Why this balances risk and progress

Bottom line

What does it mean from a development perspective:

What is a use case-first approach?

Why adopt a use case-first approach?

What a use case-first approach could look like in practice

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Admin Materials and Surfaces #70913

Description

The Materials

Base

Surfaces

Overlays

The Concepts

The Screens

Activity

cleo3 commented on Jul 25, 2025

DavidWaumsley commented on Jul 27, 2025

karmatosed commented on Jul 27, 2025

ajaydsouza commented on Jul 28, 2025

techmagick commented on Jul 29, 2025

Sirjazzfeetz commented on Jul 29, 2025

davidinnes commented on Jul 30, 2025

sinanisler commented on Aug 4, 2025

wolffe commented on Aug 11, 2025

michakrapp commented on Aug 12, 2025

kurtrank commented on Aug 12, 2025

wolffe commented on Aug 12, 2025

ResponsiveFlow commented on Aug 12, 2025

8 remaining items

GlentonCo commented on Aug 27, 2025

Here are several reasons why:

A Better Proposal

How this could look in practice

verlev commented on Sep 1, 2025

verlev commented on Sep 1, 2025

markparnell commented on Sep 2, 2025

blackandcode commented on Sep 2, 2025

In support of a modern Admin — without leaving PHP devs behind

Why this matters

A practical path that meets both worlds

1. Keep PHP at the core, enhance progressively

2. Ship a declarative “Admin Schema”

3. Provide a PHP wrapper/configurator à la Redux-style DX

4. First-class migration adapters

5. Tooling that respects how WP devs work

6. UX details that came up in this thread

Why this balances risk and progress

Bottom line

DavidWaumsley commented on Sep 2, 2025

sunyatasattva commented on Sep 2, 2025

MorrowShore commented on Sep 2, 2025

nicholaszein commented on Sep 4, 2025

What does it mean from a development perspective:

SirLouen commented on Sep 25, 2025

jaycanuck74 commented on Oct 12, 2025

lesley-pizza commented on Nov 18, 2025

What is a use case-first approach?

Why adopt a use case-first approach?

What a use case-first approach could look like in practice

ricjcs commented on Feb 16, 2026

jeffpaul commented on Feb 17, 2026

ricjcs commented on Feb 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions