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. See the above screenshot for before-after.

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

Thanks for the super detailed review. I really appreciate it.

Let's also make sure that we have a design approval here before we 🚢 .

I believe @lucasmendes-design & @jasmussen have already given their blessings, can you confirm 😄

@tyxla Thanks for the super detailed review. I really appreciate it.

No worries, let's just also make sure all checks pass - there seem to be some failures right now (seem to be one-off infra failures at first glance)

No worries, let's just also make sure all checks pass - there seem to be some failures right now (seem to be one-off infra failures at first glance)

I often have such failures in my other PR(s). I'm pretty sure they are just flaky runs, but I don't have permission to rerun the jobs 😬 usually I just force-push empty commit just to rerun them 😞 not sure what's the best practices here.

I often have such failures in my other PR(s). I'm pretty sure they are just flaky runs, but I don't have permission to rerun the jobs 😬 usually I just force-push empty commit just to rerun them 😞 not sure what's the best practices here.

Got it. Yeah, force-pushing is the easiest thing to do if you can't rerun them. I've re-ran them for you now.

Good to go now? 😄

Thanks Marin for testing!

@joedolson / @t-hamano (as 7.1 tech leads), as noted in the corresponding Trac ticket, this patch complements ​https://github.com/WordPress/gutenberg/pull/79197 (merged). Let us know if this is good to include in 7.1.

Thanks for taking a look.

My only concern is that the white PNG icon disappears when applied as a site icon, but I don't think there's a way to completely avoid this.

Yeah, white icon is a bit problematic here, but it seems to be already an issue in the multisite switcher dropdown on certain color scheme such as Light:

I don't see a clear path for "fixing" this to be honest. It feels it's better for the user to have dark stroke for their icon so that it works anywhere even outside WordPress 🤔

BTW, I am seeing different preview than yours; I uploaded a white ball with transparent background but it seems to load fine in the preview. Compare with yours above:

[scruffian]

In 62592:

Toolbar: Make the user avatar image circular.

Make the user avatar in the admin bar circular, both in the top-level toolbar item and the account dropdown. This aligns with the block editor, where avatars are already circular while site logos are square, and follows a common convention that helps distinguish an avatar from a site icon. The avatar is also enlarged slightly on both the desktop and mobile viewports to offset the area lost to the circular crop and to keep it balanced with the surrounding toolbar icons, as follows:

• Desktop viewport: bump the size from 18px to 20px; add border-radius: 50%
• Mobile viewport: bump the size from 26px to 28px; add border-radius: 50%

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

Props fushar, scruffian, joen, sabernhardt, jeryj.
Fixes #64667. See #65083, #65088.

Noting that if you have this PR applied and the Gutenberg experiment enabled then you end up with two site icons

Ah you're right, thanks, I will delete the Gutenberg experiment after this is committed, as nothing is experimental anymore by then.

[scruffian]

In 62614:

Toolbar: Show the site icon in the admin bar when one is set.

When a site icon is configured, it is displayed in the WordPress admin bar in place of the home/odometer dashicon. The icon is shown at 20×20px with a border-radius of 2px. When no site icon is set, the existing dashicon behavior is preserved.

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

Props fushar, tyxla, joen, wildworks, scruffian, sergeybiryukov, lucasmdo, joedolson.
Fixes #65088. See #46657, #64308.

[sabernhardt]

[62614] undid changes from [62592] and [62543].

I'm not sure if reverting the commit would be best, but the pull request needed a branch update and more polishing first. For example, the function could check if the site icon file is the same at 32 and 64 before adding the srcset attribute, as [62502] does.

[sabernhardt]

The change was reverted:

In r62620

[REVERT] Toolbar: Show the site icon in the admin bar when one is set.

Reverts [62614]. The patch proposes accidentally undid changes from [62592] and [62543].

[scruffian]

In 62625:

Toolbar: Show the site icon in the admin bar when one is set.

When a site icon is configured, it is displayed in the WordPress admin bar in place of the home/odometer dashicon. The icon is shown at 20×20px with a border-radius of 2px. When no site icon is set, the existing dashicon behavior is preserved.

This was originally committed in [62614] but accidentally undid other changes, so it was reverted in [62620].

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

Props fushar, tyxla, joen, wildworks, scruffian, sergeybiryukov, lucasmdo, joedolson.
Fixes #65088. See #46657, #64308.