Icon/Vector registration API #53510
Replies: 6 comments 17 replies
-
Thanks for developing this into a discussion. Thank you for raising this. It's a good suggestion and one that is needed by users and developers.
What is being proposed is actually just an API for registering icons. I assume it could also be used by Core itself as well as the Plugins you mention?
This is very important. Why? Because currently all icons are either custom or from As I previously suggested, the API should allow for the icon markup to be registered as HTML and then it can be consumed via
The use cases for this as many, but in Core there are already scenarios where it would be useful for Plugins to be able to register icons in order that they can be offered as additional options to users. The one I'm thinking about is (unsurprisingly!) the "hamburger" mobile toggle icon for the Navigation block. In this scenario icons could be registered and then added to the block editor settings (as references - by ID?) allowing them to be consumed by the Navigation block which would simply request the appropriate icons and display in the UI controls. ## Other options to consider I have previously received feedback (away from Github) that we could consider using Theme JSON as the place to register the icons. I'm not sure of the implications of that. Perhaps @oandregal can offer his input here? |
Beta Was this translation helpful? Give feedback.
-
I created a demo repo about how this could work https://github.com/draganescu/wp-icon-api/tree/trunk |
Beta Was this translation helpful? Give feedback.
-
I just want to share that I have done a similar exploration here: https://github.com/10up/block-components/tree/develop/components/icon-picker Having something similar in core would be super useful! Also, making it available through theme.json to make a subset of icons available to different blocks would be very nice. Currently, the limited hardcoded set of icons for the navigation block for example could very nicely be swapped out by custom registered icons. |
Beta Was this translation helpful? Give feedback.
-
@draganescu How can I help move this proposal forward? :) Are you currently working on developing this further? |
Beta Was this translation helpful? Give feedback.
-
Sharing some thoughts:
Definitely not all things to be solved right away, starting with the most simple API seems like a good idea, but it could be worth considering those things to make sure the initial API design is flexible enough to achieve them. |
Beta Was this translation helpful? Give feedback.
-
This would be great. There are so many plugins that add icons to things, each in their own way. Older plugins usually use Font Awesome, while newer ones use SVGs, but all load their own icons. Making the default icons in Wordpress available instead, and then adding the option of adding more when needed, would reduce the overall bloat and ensure visual consistency. |
Beta Was this translation helpful? Give feedback.
-
Demo repo
https://github.com/draganescu/wp-icon-api/tree/trunk
Icons!
Icons communicate condensed information and expectations of what happens after an action. Given that the site editor is a design tool, for professionals and enthusiasts alike, there are countless situations that require a good icon: a call to action button that shows some love, a menu item that is special for 15 days, the visual highlight of a blog with well curated quotes, landing page sections that allow better conversions because icons make skimming easier, a quick logo solution, I could go on and on.
Prior art
The 1st path explored was allowing users to upload SVG files which could then be used directly. That did not and still does not work. Starting with the long discussion in Reconsider SVG inclusion to get_allowed_mime_types and up to the recent attempt of a trimmed down option in Performance Lab plugin’s SVG uploads letting normal author users simply uploading, previewing and inserting untrusted SVG content is hard to do in a secure manner. With thousands of security concerns and a format that is too flexible to properly sanitize, allowing low permission users uploading SVG as media is hard to do right.
So how about a 2nd path?
Proposal
Instead of allowing low permission users uploading SVG as media, we allow high permission users to install plugins which provide secure SVG media.
SVG is complex, let’s restrict the discussion here only for using the format for icons.
As suggested before, I propose a system of registering SVG icons one by one in plugins. These plugins register icons just like they register blocks, with some function like:
Or, even better, we could have a more general API like:
The second register method would allow vectors that are more than icons to be used in various ways: decoration, masking, featured content.
Either way, the goal is to make SVGs available from trusted sources.I
Similarly to registering block collections we could also support registering icon collections, just for the same reasons, to visually group these icons where users can browse them.
All icons and collections registered should be available via the REST API in some
wp-json/wp/v2/icons
resource. The resource returns collections by default, supports searching for an icon and listing icons in collections and tags.In the block editor we introduce a new
supports: icon,
.If a block supports using icons, a new control shows up in the design panel allowing a user to browse for icons and search for an icon. The block’s edit and save components can implement how they see fit the icon once the user chooses it, and Ideally they copy the SVG into markup or meta. The icon in the block inherits the default block styling (colors).
If we want to allow users to use standalone icons we can also add an icons block that only displays an icon and allows for styling it. If we implement this then the inserter could as well sport a nice icons tab searching through the same registered icon packs from plugins.
This option allows the ecosystem to provide curated and secure vector graphics, people with accurate permissions to curate these plugins before choosing them, and finally users to use vector graphics - albeit initially just for iconography for now - in their design and content.
What do you think? Is this a terrible idea? Can it be built upon?
Beta Was this translation helpful? Give feedback.
All reactions