Add Icon APIs: registry and /wp/v2/icons endpoint#10909
Add Icon APIs: registry and /wp/v2/icons endpoint#10909mcsf wants to merge 7 commits intoWordPress:trunkfrom
Conversation
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
| * } | ||
| * @return bool True if the icon was registered with success and false otherwise. | ||
| */ | ||
| private function register( $icon_name, $icon_properties ) { |
There was a problem hiding this comment.
I do not think we should merge in this API without a public method for registering icons.
The icon library we are shipping with Core is the gutenberg icons. Those icons were never meant to be frontend design icons. They are editor interface icons.
From my POV there is very little utility to the icon block in core without the ability to register custom icons.
There was a problem hiding this comment.
I understand where you're coming from, but I'd argue that the Icon block is already useful in its initial form, having access to 321 core icons.
Though @wordpress/icons was developed to support the needs of the editor, IMO it's fair to say that the icon set can accommodate more uses. Folks like @jasmussen, @jameskoster and others have been iterating on those icons and are involved in the making of the Icon block, which I take as a sign that, though imperfect, the icon set has evolved beyond its original purpose.
Keeping the Icons registry closed was a way to conserve some more room for adjustments, as the icon block itself gets adopted. It should be understood as an intermediate step, so that we can confidently expand the scope of the registry in 7.1 (third-party registration, but possibly also categories, etc.).
There was a problem hiding this comment.
Thanks for the ping. As happens more often than I like, I find myself agreeing with both ends of the spectrum.
On the one hand, let's be honest that the utility of this first iteration is limited: there are many inline contexts where I would like to use icons, but can't. There's just that one set, and although there are many nice icons there, the majority of them were designed for blocks, or WordPress specific features.
On the other hand, while this effort is also about adding a block that lets you intiutively create decorative bullets and expanded patterns, it's also a mammoth infrastructure effort, to bring SVG support to WordPress, to wrap it in a UI that we can grow, expand, and iterate. Most of this work may not be quite as exciting and immediately useful, but wait til you see what we can do with it. We're building a mountain, moving dirt to one place, and eventually what we build will be visible on the horison.
In saying that, I'm validating every aspect of Fabian's point. I think this is especially important if we were to land in 7.0 and market this new feature: we should be very honest that this is a small first step, not the end-state. There are shortcomings: SVG support is the big deal. But with that, I'm also validating Miguel's instinct: this ground work is critical, and there's no better test crucible than to ship this in a major release, so we can work out the inevitable issues.
None of this is strongly felt. There's always another release. But it's a soft appeal: I'd rather take 4 deliberate, but small steps, than make one big jump and risk landing in the wrong place.
There was a problem hiding this comment.
After talking with Joen, I also opened WordPress/gutenberg#75526 to distinguish "front-end-ready" icons from internal ones.
There was a problem hiding this comment.
Keeping the Icons registry closed was a way to conserve some more room for adjustments, as the icon block itself gets adopted. It should be understood as an intermediate step, so that we can confidently expand the scope of the registry in 7.1 (third-party registration, but possibly also categories, etc.).
I also agree with this approach. To get attention and move this PR forward, we might want to submit a core ticket first.
4 participants
Companion PR to Gutenberg's WordPress/gutenberg#72215 and WordPress/gutenberg#74943
Builds on #10795
Trac ticket: