Icons: Add a `core-admin` icon collection for the admin interface

[wildworks]

Backports ​https://github.com/WordPress/gutenberg/pull/83261 to core.

The Icons API introduced in [62748] registers the default WordPress icons in the core collection.

#65089 proposes replacing the dashicons in the admin bar and the admin menu with SVG icons rendered through wp_get_icon(). Those icons live in the core collection, so a plugin that unregisters that collection — something it might legitimately do to hide the default WordPress icons from the Icon block — would also wipe out every icon in the dashboard chrome.

The proposal is to add a core-admin icon collection for the icons the admin interface renders. A new admin property in the icons manifest marks those icons: they are registered in core-admin in addition to core, always as non-public icons there, so the collection contributes nothing to the icons REST API or to the Icon block.

The core-admin collection is not protected in any way the other collections are not. Keeping the rules simple was preferred over guarding it.

Backports ​https://github.com/WordPress/gutenberg/pull/83012 to core.

#65089 proposes replacing the dashicons in the admin bar and the admin menu with SVG icons rendered through wp_get_icon(). Those icons live in the core collection, so a plugin that unregisters that collection — something it might legitimately do to hide the default WordPress icons from the Icon block — would also wipe out every icon in the dashboard chrome.

This PR adds a reserved _builtin collection, holding a private copy of the icons that WordPress itself renders. Neither the collection nor its icons can be unregistered, and both are hidden from the icons REST API so the collection is never offered in the icon library. Icons flagged _builtin in the icon library manifest are registered there in addition to their core counterparts.

The core collection keeps its current behaviour, so a plugin can still hide or replace it in the editor without breaking the dashboard.

The manifest itself is generated from gutenberg/packages/icons by grunt copy:icon-library-manifest, so the _builtin flags arrive with the next Gutenberg hash bump. Until then no icon in core carries the flag, and this change is covered by unit tests only.

Testing Instructions

Run the PHP unit tests and confirm they pass:

npm run test:php -- --group icons

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: code generation and testing, with my supervision.

Closing this based on ​https://github.com/WordPress/gutenberg/pull/83012#issuecomment-5748999409

Backports ​https://github.com/WordPress/gutenberg/pull/83261 to core.

#65089 proposes replacing the dashicons in the admin bar and the admin menu with SVG icons rendered through wp_get_icon(). Those icons live in the core collection, so a plugin that unregisters that collection — something it might legitimately do to keep the default icon set out of the Icon block — would also wipe out every icon in the dashboard chrome.

This replaces #13551, which took the reserved _builtin collection approach. Following ​the discussion, a plain second collection was preferred over a protected one.

How?

• A new admin property in the icons manifest marks the icons the admin interface renders. An icon carrying it is registered in a new core-admin collection in addition to core, and is always non-public there. This is the collection the admin bar and the admin menu are meant to use.
• core-admin is not protected in any way the other collections are not. Keeping the rules simple was preferred over guarding it.
• Since every icon in core-admin is non-public, the collection contributes nothing to the icons REST API or to the Icon block. The collection itself is still exposed by the icon collections endpoint.

The manifest is generated from gutenberg/packages/icons by grunt copy:icon-library-manifest, so the admin flags arrive with the next Gutenberg hash bump. Until then no icon in core carries the flag, and the core-admin collection is registered but empty.

Testing Instructions

Run the PHP unit tests and confirm they pass:

npm run test:php -- --group icons

To exercise the registration before the flags land, add 'admin' => true to an entry in src/wp-includes/assets/icon-library-manifest.php and confirm that:

• wp_get_icon( 'core-admin/<icon>' ) returns the SVG markup.
• wp_get_icon( 'core/<icon>' ) still returns it as well.
• await wp.apiFetch( { path: '/wp/v2/icons/core-admin' } ) is empty, while /wp/v2/icon-collections lists core-admin.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: code generation and testing, with my supervision.

[peterwilsoncc]

This is blocked from commit pending the GB hash bump.

@peterwilsoncc There seem to be no merge conflicts locally. I was able to merge trunk into this branch as is.

[wildworks]

In 64224:

Icons: Move public to collections and add core-admin collection.

Visibility is now controlled per icon collection instead of per icon. Icons in a non-public collection are not exposed through the REST API or selectable in the Icon block, but remain available to server-side rendering.

Adds a non-public core-admin collection for the icons used by the admin interface, so that a plugin unregistering the core collection to hide the default icons from the Icon block no longer removes the icons rendered in the dashboard.

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

Follow-up to [63625].

Props mcsf, peterwilsoncc, wildworks.
Fixes #66114.