Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Social Links Block: Icon Storage/Extension Architecture #19041

0aveRyan opened this issue Dec 10, 2019 · 1 comment

Social Links Block: Icon Storage/Extension Architecture #19041

0aveRyan opened this issue Dec 10, 2019 · 1 comment


Copy link

@0aveRyan 0aveRyan commented Dec 10, 2019

Per discussion on #18651, the current approach to storing Icons for the Social Links block has quite a bit of duplication of SVGs and associated label data between the JavaScript and PHP file, nor is there a great way to add or override logos (#17277).

We definitely need a way for logos to be added or overridden, and ideally an approach to storing the data in a way both JavaScript/PHP can share, without adding performance burden/blocking requests to site visitors.

For Extension

For extending, ideally we could use a single PHP-based apply_filters() to allow developers to inject, remove or override icons from the list. By using the PHP filter, we could make a single extension point as opposed to having to filter both PHP and JS hooks.

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...

  • Leave implementation as-is, add filter hooks in JS & PHP for extension and enhance with clearer inline documentation that any changes must happen to both objects -- still duplicated but extensible and clearer.
  • Add a socialData.json file with icons base64 encoded and filter hooks in JS & PHP to allow extension -- adds filesystem read in PHP and base64 strings would be about 1/3 larger.
  • Use a socialData.json file to inject the objects into JS & PHP during webpack build, base64 decode icons and add filter hooks -- somewhat obfuscates what's happening and some complexity, but reduces client burden.
  • Separate icons into a SVG sprite approach or one-off SVG files, use a socialData.json to point to the proper icon and add filter hooks -- makes a larger payload to transmit to client/increases client requests, but makes using a data file easier.

Describe the solution you'd like
From the approaches I mentioned above, I think the lowest lift approach is simply to add some better inline documentation 😇. This isn't data likely to change with enough frequency to demand a significantly more complex architecture, unless it isn't a huge time investment. Any other ideas of course welcome.

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.


This comment has been minimized.

Copy link

@mkaz mkaz commented Dec 10, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.