Icons: publicize required icons for admin bar and menu

[fushar]

What?

Related to: WordPress/wordpress-develop#12270

Make the following icons public:

1. brush
2. dashboard
3. grid
4. link
5. media
6. page
7. plugins
8. post
9. tool
10. update
11. wordpress

Why?

The above icons are needed as the replacement for the old dashicons in the admin UI.

How?

This is as intermediate solution as this PR which makes all icons public, is punted:

• Icons: Ship all SVG icons to WordPress core #79102

Testing Instructions

Verify the diff visually that the icons that are made public, match exactly with the needed icons from the linked Core PR above.

Use of AI Tools

I used Claude Opus to generate the changes, then I also double checked it.

[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: fushar <fushar@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>

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

[t-hamano]

Thank you for your PR. However, it is difficult to move forward with this PR at this time.

• It has not yet been thoroughly examined which icons will be shipped to the core and how.
• The published icons will be available in the icon block, but icons for the management menu are not useful for post content.

It seems we need a flag to decide whether to expose icons in the Icon block, regardless of whether we move forward with #79102.

cc @mcsf @tyxla

[github-actions]

Flaky tests detected in 8cf726d.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/28036189826
📝 Reported issues:

• [Flaky Test] three users concurrently edit a large post with diverse blocks #78754 in /test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts

[tyxla]

Commented on the related PRs. I felt like we had an agreement about a public flag already, so if that's true we should be able to move forward with the registration API and respectively with publishing the icons.

[t-hamano]

The issue is that when an icon is published, it simultaneously becomes selectable within the icon block. For instance, few users would want to use icons like 'dashboard' or 'grid' in their post content.

I feel there is a need for a way to register icons in the icon registry without publishing them in the icon block, as I would like to propose here.

[tyxla]

I feel there is a need for a way to register icons in the icon registry without publishing them in the icon block, as I would like to propose here.

Just to be sure I understand: are you saying public: false for such icons isn't sufficient?

[t-hamano]

Just to be sure I understand: are you saying public: false for such icons isn't sufficient?

I see—so, this is what you mean? I believe this approach will allow us to achieve our goals without significantly altering the synchronization method between the core and Gutenberg.

[
	// Not shipped to the core
	{
		"slug": "one",
		"label": "One",
		"filePath": "library/one.svg"
	},
	// Published in the Icon block
	{
		"slug": "two",
		"label": "Two",
		"filePath": "library/two.svg",
		"public": true
	},
	// Not published in the icon block
	{
		"slug": "three",
		"label": "Three",
		"filePath": "library/three.svg",
		"public": false
	}
]

[tyxla]

This sesms reasonable at first glance, but @mcsf had some thoughts previously, so I'd love to pick his brain here

[mcsf]

This seems reasonable to me too. :)