Feature: [Enhancement] Site Editor Identity: consider live updates for the admin bar site icon and browser favicon after changing the Site Icon

[hbhalodia]

What?

Closes #81483

Why?

• PR aims to resolve the issue when an site icon is updated, it needs reload to see the new icon in admin bar. Since admin bar is in our control, then change to site icon and on save should reflect it in admin bar.

How?

• Added the new hook, useSyncAdminBarSiteIcon in @wordpress/editor which refreshes the stale url and updates in admin bar to load the image with new URL.

Testing Instructions

1. Site Editor → Design → Identity → Site Icon. Replace the icon and save — the admin bar icon (top left) updates without a reload.
2. Repeat with no icon set beforehand: the icon should appear in place of the dashicon.
3. Remove the icon: the dashicon should return.
4. Post editor: add a Site Logo block, enable "Use as site icon", and change the logo and save — the admin bar icon should follow.
5. Confirm the admin bar still renders correctly on a plain page load, with and without an icon set.
6. With add_filter( 'wp_admin_bar_show_site_icons', '__return_false' ); in place, confirm no icon appears at any point.

Testing Instructions for Keyboard

• None

Screenshots or screencast

Before

Screen.Recording.2026-08-13.at.2.00.39.PM.mov

After

Screen.Recording.2026-08-13.at.1.58.45.PM.mov

Use of AI Tools

• Claude Code, Opus 5.
• Used for the draft implementation of the feature. Implementation reviwed by me.
• Note: Needs reviwers feedback on the approach target, since I do not find any such better way.

---

AI Summary

What?

Closes #81483 (admin bar icon only)

Updates the site icon in the admin bar as soon as a new Site Icon is saved, instead of showing the old one until the page is reloaded.

Why?

The admin bar is rendered by PHP before the editor loads, so its icon is plain HTML sitting in the page with nothing to tell it a save happened.

There is also a data problem underneath. Saving writes site_icon — an attachment ID — to the site settings, but the icon's URL lives on a different entity (root/__unstableBase, the REST index), and nothing refetches that entity after a save. So even a fully reactive component would have rendered the old URL.

How?

A new hook, useSyncAdminBarSiteIcon in @wordpress/editor, doing two things:

1. Refreshes the stale URL. It watches the saved icon ID, which only changes once a save completes, and invalidates the base entity so site_icon_url is refetched.
2. Updates the admin bar to match, covering all three cases:
   • icon replaced → point the existing image at the new URL
   • first icon set → create the image and add has-site-icon, which hides the fallback dashicon
   • icon removed → remove the image and the class, restoring the dashicon

It's mounted in two places, because the Site Icon can be changed from two separate apps: the Site Editor layout (Design → Identity, the flow in the issue) and the post editor's EditorInitialization (the Site Logo block's "sync icon" toggle). There's no single component both editors always render.

On the PHP side, gutenberg_admin_bar_site_icon() now adds a supports-site-icon class to the node whether or not an icon is set. This is the one thing the editor can't work out for itself: an unset icon and icons disabled via the wp_admin_bar_show_site_icons filter look identical in the markup. With the class, the hook knows whether it may show an icon at all — and does nothing when the filter is off. The icon markup itself is unchanged, still rendered only when an icon exists.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Editor, [Package] Edit Post, [Package] Edit Site.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: hbhalodia <hbhalodia@git.wordpress.org>
Co-authored-by: jordesign <jordesign@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[hbhalodia]

Have worked on this here, Not sure is it the correct thing to change. As it's punted to 7.2 not sure if we are creating a new directory in compat and add the changes there?