Toolbar: Replace home dashicon with site icon in the admin bar

[lucasmdo]

Problem / Current Behavior

The admin bar displays a generic home dashicon next to the site name. This icon is the same for every WordPress site and carries no site-specific meaning. Users typically scan the admin bar rather than reading it, so a generic icon does little to help them quickly identify which site they are viewing, especially when multiple sites are open in different tabs.

The site icon (set via Settings → General or the Customizer) already serves as a unique visual identity for the site in browser tabs and mobile home screens, but it is not surfaced in the admin bar.

Proposed Enhancement

Replace the home dashicon in the admin bar with the site's icon. When no site icon is set, display a default letter icon using the first letter of the site name.

When a site icon is set

• Replace the home dashicon (dashicons-admin-home) with an <img> element using the site icon at 20×20 px.
• Apply border-radius: 2px for subtle rounded corners.
• It should be support it by HiDPI/Retina displays

When no site icon is set (default letter icon)

• Display a 20×20 px square with background-color: #3858E9 and border-radius: 2px.
• Render the first letter of the site name centered inside the square, uppercase.
• This default icon is only used in the admin bar, it does not appear in browser tabs or anywhere else, and it is not related to the Site Icon setting in Settings → General.

Rationale

• Unique visual identity: The site icon is the site's unique mark, already used in browser tabs and mobile bookmarks. Surfacing it in the admin bar reinforces that identity where users interact most.
• Scanability: Users scan but, in general, they don't read the page. A unique, site icon is faster to identify than a monochrome generic house across multiple tabs.
• Consistent experience: Even sites without a custom site icon get a more meaningful visual cue, the first letter of their site name, instead of an identical home icon on every WordPress install.

Backward Compatibility

This change is fully backward compatible:

• No existing settings or options are affected.
• Plugins or themes that modify the admin bar will continue to work.
• No deprecations needed.

Accessibility

• Both the site icon and the letter fallback should have aria-hidden="true" since the site name text is already present next to them, the icon is decorative.
• Ensure the icon does not break the admin bar's existing keyboard navigation or screen reader announcements.

Future Consideration

The default letter icon could also be extended to the browser tab favicon. When users have multiple WordPress sites open without custom site icons, all tabs display an empty space, making them hard to distinguish. Generating a letter-based favicon would solve this. However, that change has a broader scope so it is better suited as a follow-up ticket.

Related Tickets

• #46657 — Show site icon in My Sites admin menu (fixed, WP 5.8)
• #25971 — Changed site-name icon from globe to home dashicon (fixed)
• #64308 — Admin visual reskin exploration for WP 7.0

This PR replaces the home dashicon, with the actual site icon if set, in the admin bar.

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

## Use of AI Tools

I used Codex with GPT-5.5 to help with the CSS implementation, with my supervision.

[fushar]

site-icon-before-after

[fushar]

Hi @lucasmdo let's start with showing site icon when it's set, and keep the original behavior (home/odometer dashicon) if not set. I opened ​https://github.com/WordPress/wordpress-develop/pull/11781 for that.

I think we can tackle the generated one-letter site icon as separate ticket.

Thanks for the PR! I'm less sure about changing the dashboard (odometer) icon, as it's specifically used to get to the dashboard, and it might be confusing if both icons look the same but lead to different places depending on the context.

It also seems that the ticket only suggested changing the home icon.

[joedolson]

I don't think this requires anything special from accessibility; fundamentally, it's just an icon swap, and the new icon shouldn't convey anything different from what it did before, in my opinion.

Removing the accessibility focus.

[lucasmdo]

The thing to notice is that this isn't a single link, it's a contextual entry point. Depending on where you are, the same node can mean "Visit Site" or open a dropdown to the Dashboard, Plugins, and Themes. So the real question isn't "which destination should the icon show," it's "what does this touchpoint represent."

A destination icon over-promises. The odometer says "this goes to the dashboard," and a house says "this goes home," but the node actually does several site-level things depending on context. That mismatch is the real source of confusion, the icon makes a promise the node doesn't always keep.

The site icon removes that. The one constant across every context here is the site itself. everything in this node is site-scoped. So "site icon + site name" sets the right expectation, "things you can do for this site", and the dropdown shows the specifics.

Let me know your thoughts.

Trac comment: https://core.trac.wordpress.org/ticket/65088#comment:6

The thing to notice is that this isn't a single link, it's a contextual entry point. Depending on where you are, the same node can mean "Visit Site" or open a dropdown to the Dashboard, Plugins, and Themes. So the real question isn't "which destination should the icon show," it's "what does this touchpoint represent."

A destination icon over-promises. The odometer says "this goes to the dashboard," and a house says "this goes home," but the node actually does several site-level things depending on context. That mismatch is the real source of confusion, the icon makes a promise the node doesn't always keep.

The site icon removes that. The one constant across every context here is the site itself. everything in this node is site-scoped. So "site icon + site name" sets the right expectation, "things you can do for this site", and the dropdown shows the specifics.

Let me know your thoughts @SergeyBiryukov

it might be confusing if both icons look the same but lead to different places depending on the context.

To me, the current behavior is actually more confusing: the icon changes depending on whether we're on wp-admin or site frontend. It's not immediately clear that the odometer icon actually signifies "the wp-admin Dashboard".

When we update the icon to be the site icon in both cases, it becomes a consistent, fixed-point context of "the current site". It provides an entry for site-specific dropdown actions such as going to wp-admin and going to the site frontend. It when clicked having different destination is just a byproduct of the different first action in the dropdown.

What do you think?

I agree with this very much. The icon changing, but the label not, makes no sense to me, and it feels reasonable as a bandaid to at least unify them. But I would go a step further to suggest that the odometer changing like that reveals a fundamental underlying problem with how it's worked so far. To that end, I support what Lucas is proposing. A more bold alternative is to recast the WordPress icon to always take you to the dashboard (to your WordPress) and the site title always taking you to the frontend, which is what ​the topbar test plugin linked here does, if you'd like to try it.

Key with showing a site logo is also to ensure that, at a glance, you can always see which WordPress site you're on. If you are a power-user with multiple open WordPress tabs, unless you're careful, you might end up uploading private information to the wrong website. So we need clear delineation between sites, which the distinct-per-site site log would help do. I've seen this happen in support issues.

it feels reasonable as a bandaid to at least unify them.

Let's proceed with this, and then we can circle back on different actions for the W logo and Site icon + title. I'm assuming there are some plugins that can use the site name dropdown as well, so I think we need to investigate that a bit more.

[fushar]

@jorbin, @joedolson, @SergeyBiryukov, @sabernhardt et al: now that we're considering #65091 (admin bar in the editor) for 7.1, can we also consider this ticket as well? This complements the feature. Here, we are "restoring" site icon, which is being replaced by an explicit back button in #65091. Thanks!

Post Editor

Before	After

---

Site Editor

Before	After