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

[fabiankaegy]

In 61517:

Administration: Register wp-base-styles handle for admin color scheme variables.

Introduce the wp-base-styles stylesheet handle to provide admin color scheme CSS custom properties across WordPress. This stylesheet is added as a dependency for:

• The wp-admin styles bundle
• The block editor content iframe styles

This is the Core-side implementation of the changes from Gutenberg PRs #69128 and #69130, which consolidate the admin color scheme CSS custom properties into a single reusable stylesheet instead of duplicating them across multiple packages.

See #64308.
Props fabiankaegy, wildworks.

[fabiankaegy]

Wanted to post a quick progress update here: We've broken down the visual reskin into focused sub-tickets to enable parallel work and targeted testing:

Sub-tickets created:

• #64546 – Change default admin color scheme from "Fresh" to "Modern"
• #64547 – Update button and input field styling
• #64548 – Update notice styling
• #64549 – Update card and metabox styling

A table styling ticket is planned will be created by me shortly and then added here also.

Additionally at this point we believe that the larger "Frame" is very unlikely to make it into 7.0. I personally still want to create a PR for it so we can at least test the various changes and see the holistic vision. But given we are already 4 weeks away from Beta 1 that seems like a stretch.

@karmatosed and I are currently working on a post to share on the make blog about all this with some more detailed testing instructions :)

[TeemuSuoranta]

Hi!

I came across this ticket in LinkedIn and wanted to give some feedback as it was encouraged. I've worked with WordPress 13 years doing mostly development but always some design on the side.

I do like the effort of modernizing the look and feel so thank you for everybody working on this.

From my visual eye I'd like to point few things and doing that in brutal honesty:

• Light gray backgrounds do have their function in options and dashboard views as it brings contrast between widgets or form fields. Be mindful that if we remove that background color it may be harder to distinguish between widgets and pages might be harder to read.
• Admin footer should not be fixed to the bottom of the screen as it does not provide that valuable information to users. The users do see the WordPress logo at all times so they won't forget which CMS they are using but all fixed elements take screen real estate and they add up fast in laptop screens.
• Resizable admin menu does seem like a good idea. I guess the proposed default width is in line with Site Editor. Just looking at it in the context of dashboard it does look a bit too wide there. Maybe it's the fact that default items only fill small part of it and it makes sense in the bigger context but I just can't shake the initial feeling that it's too wide.

I'll keep on following this ticket and giving feedback on designs!

[sj_o]

IMO the radii scaling in overall editor design is broken. That's why wrapper radii vs components radii don't match with this.

This is a very hard task and wishing you all the luck with it! :)

Btw we've done this last year with one of sites, and still using WP Admin this way, but mind you, the editor design language is completely ignored, but radii is respected only

​https://fluxrunner.com/wpdm.png

[poena]

Hi,
is the Playground link in the first post, under Initial Exploration up to date with the individual PR's?
I mean can it be used to test the PR's from the sub-tickets together?

[jorbin]

Replying to fabiankaegy:

@karmatosed and I are currently working on a post to share on the make blog about all this with some more detailed testing instructions :)

There isn't :alot: of time left until Beta 1. When should we expect this post?

[heinperu]

I would like to test the impact of these updates on our plugin.
When can I test this in a nightly build?

I download the WordPress Beta tester plugin, but I couldn't see any of these changes yet.

## Summary

• Adds 7 new visual regression snapshot tests covering admin pages most impacted by the CSS reskin in #10910 that previously had no automated visual coverage
• Combined with the 22 existing tests, this brings total coverage to 29 admin pages
• The admin reskin is a CSS-only change touching 27 files — visual regression tests directly test what changed

## New tests

Test	Page	Notes
Dashboard	/index.php	First page every admin sees
Themes	/themes.php	Masks theme screenshot images
General Settings	/options-general.php	Primary settings form
Writing Settings	/options-writing.php	Form fields, checkboxes, dropdowns
Permalink Settings	/options-permalink.php	Radio buttons, text inputs
Add New Post	/post-new.php	Masks editor content area
Edit Post	/post.php?post=<id>&action=edit	Creates post via REST API, masks editor

## How to use

Generate baseline snapshots on trunk, switch to the reskin branch, and re-run. Any visual differences produce pixel-level diff images in artifacts/.

# 1. Start the Docker environment
npm run env:start

# 2. Check out trunk and generate baseline snapshots
git checkout trunk
npm run test:visual

# 3. Check out the reskin branch and compare
git checkout pr/10910
npm run test:visual

# 4. If any tests fail, check artifacts/ for diff images

Snapshots are gitignored — no storage overhead in the repo.

## Trac ticket

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

[isabel_brison]

The button on the login screen is now invisible on trunk, looks like the new admin scheme styles aren't being enqueued on that screen?

[peterwilsoncc]

@isabel_brison There's a followup ticket and PR in progress on #64640.

[lumpysimon]

Completely agree that a CSS refresh without changing markup / JS has the potential to be a very good move.

However, as it stands at the moment the design proposal feels more old-fashioned to me, rather than achieving the aim of a more modern look.

I think the main reason is the very high contrast between the black background of the menu / header / footer and the white background of the main page area, it's quite jarring on the eyes. Very few colour palettes incorporate both white and black as background colours for this reason. I'd argue that there needs to be lower contrast between these two areas, of course without negatively impacting accessibility.

The primary buttons having the same background colour as the page makes them very unclear (and maybe less accessible?) - they don't stand out at all when you visually scan the page.

I also agree with @TeemuSuoranta there is no need for the footer to be sticky as it contains no critical information.

The corner radius also looks too large (but this may be due to the black/white contrast), adding to the old-fashioned feel.

[sj_o]

The main problem is the styles/colors are hardcoded in current WP Admin, without following any design system like Gutenberg.

That's why even if this'd be a successful merge, it'd be a transitionary/patched one because as I've mentioned previously, the admin styles vs Gutenberg is broken.

I wouldn't suggest working much on this unless we rebuild Admin w react/gutenberg base.

[jorbin]

Noting that the following commits have been made related to this:

[61644], [61645], [61646], [61647], [61652].

[joedolson]

In 61681:

Admin: Apply scheme styles in non-admin admin screens.

Adds the admin-scheme styles as a dependency for the login and install styles. This is to ensure the CSS variables are available to the login, installation, database repair and upgrade screens.

Modifies the display of notices in the login styles to match those in the new default scheme, "modern".

Props peterwilsoncc, wildworks, westonruter, mukesh27, fabiankaegy, audrasjb, huzaifaalmesbah, sabernhardt, presskopp, SirLouen, ellatrix, nendeb55, neo2k23, jsmansart, joedolson.
Fixes #64640, #64548. See #64308.

[jorbin]

Additional Commit: [61682]

[JoeFusco]

Related: #64671 - supporting visual regression tests

[audrasjb]

WP 7.0 pre-beta1 Triage:
Unfortunately this enhancement didn't make it before beta 1 code freeze. Thus, let's move it to milestone 7.1.

[sabernhardt]

Moving back to the 7.0 milestone. This probably should be switched to a task (or else closed).

[audrasjb]

Let's switch it to a blessed task / umbrella ticket, but it would be better if new issues can have their own tickets.

[westonruter]

In 61989:

Login and Registration: Update logo from blue to gray to match new design.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/11026

Props juanfra, westonruter, jeffpaul, mukesh27, audrasjb, joedolson, dd32, davidbaumwald, fabiankaegy, huzaifaalmesbah, Joen, butterflymedia, noruzzaman, karmatosed, ozgursar, fcoveram, tusharaddweb, darshitrajyaguru97.
See #64308.
Fixes #64708.

[ozgursar]

I was testing this using the provided Playground link and found a small bug:
​https://playground.wordpress.net/?blueprint-url=https://raw.githubusercontent.com/fabiankaegy/wp-admin-redesign-exploration/main/_playground/blueprint.json

Appearance > Themes section is broken when there is a single Theme installed

Further checking, I found the issue is due to the grid-template-columns misbehaves when there is only one subitem in the CSS grid.

Adding a second theme fixes the issue

[mikejdent]

This is something I've been thinking about for a while and started working on an admin theme to create a more unified appearence. I really like what you've done in the exploration project, although for my two cents my approach was a little different.

My proposal is that given @wordpress/base-styles and @wordpress/components alreday have all the styles we need and may well evolve with time it makes sense to use those. Colors and typography can be imported with scss and then @wordpress/components/build-styles could be run through a postcss plugin like ​https://github.com/fi3ework/postcss-rename-selector to apply the styles to the admin markup.

[sabernhardt]

I'll close this before RC1. Any additional bugs can be reported with the 'admin-reskin' keyword.

[audrasjb]

In 62097:

Menus: Remove floats from custom links section in the Nav Menus screen.

With the new admin design, there were some issues with floating elements in the custom links section of the classic Menu screen. This changeset simplifies the CSS implementation by removing floats and wp-clearfix classes from some elements in favor of a more robust implementation based on flex positionning.

Props audrasjb, huzaifaalmesbah, shailu25, nikunj8866, joedolson, khushi1501, ozgursar.
Fixes #64692.
See #64308.

[audrasjb]

In 62098:

Media: Implement admin UI changes in the "Edit Image" screen and modal.

This changeset fixes some missing implementations of the new Admin UI in buttons and help links located on the "Edit Image" screen and within the related modal.

Props huzaifaalmesbah, hmbashar, audrasjb, mukesh27, wildworks, noruzzaman, shailu25, manhar, amin7, amesplant.
Fixes #64759.
See #64308.

[audrasjb]

In 62145:

Admin: Use admin color scheme variable for bar, highlight, and contextual help styles.

This changeset ensures the styles for bar, highlight and contextual help always take into account the admin color scheme settings.

Reviewed by joedolson.
Props fabiankaegy, audrasjb, ozgursar, noruzzaman, shailu25, sandipsinh007, tusharaddweb, hbhalodia, amesplant, joedolson.
Fixes #64744.
See #64308.

[audrasjb]

In 62163:

Upgrade/Install: Use new default admin color scheme for language dropdown on the setup screen.

This changeset ensures the hover/focus color of the setup screen's language dropdown use the new default admin color scheme.

Reviewed by SergeyBiryukov.
Props huzaifaalmesbah, noruzzaman.
Fixes #64961.
See #64308.

[audrasjb]

In 62164:

Upgrade/Install: Use new default admin color scheme for language dropdown on the setup screen.

This changeset ensures the hover/focus color of the setup screen's language dropdown use the new default admin color scheme.

Reviewed by SergeyBiryukov.
Merges [62163] to the 7.0 branch.

Props huzaifaalmesbah, noruzzaman.
Fixes #64961.
See #64308.

[wildworks]

In 62230:

Upgrade/Install: Use new default admin color scheme for links on the setup screen.

This changeset updates the link colors on the setup screen and the default wp_die() fallback styles to use the new default admin color scheme.

Props audrasjb, darshitrajyaguru97, dhrumilk, hbhalodia, huzaifaalmesbah, ismail0071, mikinc860, pooja-n, shailu25, sumitsingh, vishitshah, wildworks
Fixes #64962. See #64308.

[audrasjb]

In 62236:

Upgrade/Install: Use new default admin color scheme for links on the setup screen.

This changeset updates the link colors on the setup screen and the default wp_die() fallback styles to use the new default admin color scheme.

Reviewed by audrasjb, wildworks.
Merges [62230] to the 7.0 branch.

Props audrasjb, darshitrajyaguru97, dhrumilk, hbhalodia, huzaifaalmesbah, ismail0071, mikinc860, pooja-n, shailu25, sumitsingh, vishitshah, wildworks
Fixes #64962.
See #64308.