Explore a "Coat-of-Paint" Visual Reskin of the WordPress Admin for WordPress 7.0

[fabiankaegy]

During a recent Core Committer meeting, there was interest voiced for pursuing a "coat-of-paint" visual reskin of the WordPress admin for the WordPress 7.0 release cycle. This ticket proposes formally initiating that effort.

The goal is to modernize the admin's appearance, reduce inconsistencies between old screens and the newer block editor / site editor screens, and better align it with the WordPress design system as a whole:
​https://www.figma.com/design/804HN2REV2iap2ytjRQ055/WordPress-Design-System?node-id=551-29619&t=fgacEMH0dvBqKwXF-1

Why Now

The admin's visual language has fallen out of alignment with Gutenberg and newer interfaces. Prior attempts became unmanageably broad; this effort is intentionally constrained to a reskin only. And with the 7.0 release being right around the corner, this feels like a good time to address some of these discrepancies.

Proposed Scope

This is a visual-only refresh with no functional or architectural changes. The focus is on core components that appear across all admin screens:

• Buttons: Consistent styling for primary, secondary, and link buttons
• Input Fields: Unified appearance for text inputs, selects, checkboxes, and radio buttons
• Admin Tables: Light refresh of admin tables styles to align with DataViews
• Cards: Dashboard widgets and metaboxes with modern styling
• Notices: Clear, accessible info/warning/success/error messages
• Typography: Consistent font sizes, weights, and line heights
• Spacing: Unified spacing scale across the admin
• View Transitions: Apply global view transitions for cross document navigations within the admin (#64470)
• Global Background: Updated background color aligned with the design system
• Admin Frame: Explore a sidebar navigation pattern similar to the Site Editor (if time and resources permit)

Key Principles

• CSS-Only Changes: No markup or JavaScript modifications
• Backward Compatibility: All existing CSS class names and admin color schemes preserved
• Design System Alignment: Built on the WordPress Design System foundation: ​https://www.figma.com/design/804HN2REV2iap2ytjRQ055/WordPress-Design-System?node-id=551-29619&t=fgacEMH0dvBqKwXF-1

What This Is NOT

• This is not a React-based admin rebuild
• This is not an information architecture restructure
• This is not a DataViews adoption (functional changes)
• This is not removing or changing existing functionality

Timeline Approach

Given that any visual refresh always comes with feedback and potential compatibility issues, the aim here is to get this into trunk as early as possible to allow for a longer feedback cycle.

My proposal is a phased approach here:

• Get the foundational color variables in place so they can be used across the all the admin screens (https://core.trac.wordpress.org/ticket/49930)
• Update the buttons, input fields, notices, cards, and tables to align with the new design system (partially handled by https://core.trac.wordpress.org/ticket/62864)
• Update the typography to align with the new design system
• Update the spacing to align with the new design system
• Update the admin frame to align with the new design system
• Update the global background color to align with the design system

Initial Exploration

I've started some initial explorations here:
​https://github.com/fabiankaegy/wp-admin-redesign-exploration

They can be tested in a playground environment:
​https://playground.wordpress.net/?blueprint-url=https://raw.githubusercontent.com/fabiankaegy/wp-admin-redesign-exploration/main/_playground/blueprint.json

Questions for Discussion

• Scope Agreement: Does the proposed scope feel appropriate for the 7.0 timeline?
• Feature Plugin: Should we create this all as a feature plugin (MP7) before merging into trunk?
• Design Direction: Are there specific visual patterns from the Block/Site Editor we should prioritize?
• Color Schemes: How do we ensure all existing admin color schemes work well with the refresh?
• Plugin Compatibility: What level of plugin testing is needed before merge?
• Admin Frame: Is the admin frame sidebar navigation worth exploring, or should we defer it?

Related Tickets

• #49930 – Replace wp-admin color schemes with CSS custom properties
• #62831 – Admin Design Refresh / Global Styles (lessons learned)
• #62864 – Rethinking WP Admin Styles (incorporated concerns)

---

Note: This is intentionally a high-level proposal to start the conversation. Detailed implementation specifications, CSS examples, etc can follow if we agree this is a good direction to go in.

[fabiankaegy]

What do I mean by “Admin Frame”

In the proposal, you have heard me say “Admin Frame” a few times. What I mean by that is the visual appearance of the main sidebar & admin bar.

Lets start by looking at the admin today.

The first update would be to simply update the spacing/size, etc of components without making any changes to the “frame”. To my personal taste, this feels like an odd interim step that doesn’t really solve the discrepancy between the modern screens and the older screens.

If we compare this with the site editor there is a harch discrepancy between the two.

This third screenshot shows what this same screen shown in the first image looks with with a more modern take on the admin frame which is inspired by the work already done in the site editor.

[fabiankaegy]

Feature Plugin vs. building in Core

Whilst I was working on the exploration of this re-skin in my plugin I noticed that basically all the styles I’ve needed to write differed greatly from how I world need to tacke this same update in Core itself. This was because the majority of the styles I ended up writing were there to overwrite / fight styles of core.

I say this because it effectively means that even though we can use a feature plugin to explore design ideas and collect feedback, it won’t really help us with actually getting any of this merged into core, because the code we have to write in core is widely different to the code we’d have to write in a plugin.

Because of this, my personal preference would be to skip the feature plugin and directly iterate in trunk as early as possible in the 7.0 release cycle so we have time to collect feedback etc.

[SirLouen]

@fabiankaegy wouldn't be better to replicate also the nav formatting? with the right chevron and the light grey for the items? Maybe even the interaction could be improved with vanilla js.

This could facilitate a better transitioning.

There is a thing that could be somewhat controversial, but despite not transitioning yet to a full react view with dataviews, I believe that backwards compatibility should be broken now for the most part, this means, a full revamp on how the interactions are being executed in the navbar.

Also, it should be a foundational step, so extenders can start adding their own data views in their listings looking good.

Still, it's important to know when 7.0 is approximately planned to be released. I assume this was discussed in yesterday's meeting. It won't be the same if 7.0 has a release cycle like 6.9 did, or if it's going to have a cycle like 6.8. In case of the latter, then an iteration like this without improving the interactions is more than enough.

PS: the view transitions are great idea :)

[desrosj]

Connecting this ticket back to the meeting summary: ​https://make.wordpress.org/core/2025/11/26/core-committers-check-in-november-2025/

[westonruter]

I've opened #64470 to specifically track implementing View Transitions in the admin.

Trac ticket: https://core.trac.wordpress.org/ticket/64308