Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Social Links Block: Icon Storage/Extension Architecture #19041
For extending, ideally we could use a single PHP-based
For Icon/Data Storage
There's been some discussion about using SVGR, but taking that approach would create invalid imports for the npm packages and without some laborious/extremely-clever build changes.
Some previously discussed ideas on #18651...
Describe the solution you'd like
As much as it'd be great not to have a contribution/maintenance burden with the duplication between PHP/JS files, I'd rather the burden be on developers than adding filesystem reads or additional requests for every visitor.
@0aveRyan, thanks for opening the issue and starting the discussion.
One other issue at hand, that I'm not sure if we should try to solve together with this or not, is the usage of icons in Embeds. There are a half-dozen or so overlapping icons, they are only used in the Editor view so the embed icon usage does not run into the same issue of duplicate JS and PHP.
Social Icons runs into the issue because we need the icons defined in JS to be usable in Gutenberg, for both display in the block in editor view, but also as the block icon for the inserter. The second usage is the icon being shown to the user so needs to be saved in a way to be referenced via the front-end.
And like all SVG being saved in post content, there are KSES issues.