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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @mkaz, @KoiKoneessa, @mkkeck, @YogieAnamCara, @aksthelion, @bshuchter, @davidallenlewis, @chs-kasvu, @hundkurserforalla, @thekamilpro, @aut0poietic.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: mkaz, KoiKoneessa, mkkeck, YogieAnamCara, aksthelion, bshuchter, davidallenlewis, chs-kasvu, hundkurserforalla, thekamilpro, aut0poietic.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: bph <bph@git.wordpress.org>
Co-authored-by: costasovo <costasovo@git.wordpress.org>
Co-authored-by: strarsis <strarsis@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: apmeyer <apmeyer@git.wordpress.org>
Co-authored-by: Drivingralle <drivingralle@git.wordpress.org>
Co-authored-by: phil-sola <philsola@git.wordpress.org>
Co-authored-by: nurianadal <sedmikrasky@git.wordpress.org>
Co-authored-by: daveguitaruno <daveguitaruno@git.wordpress.org>
Co-authored-by: 0aveRyan <dryanpress@git.wordpress.org>

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

Size Change: +84 B (0%)

Total Size: 1.85 MB

_{compressed-size-action}

@WordPress/outreach Hi folks! If you have a few minutes, can you help test this, please?

This is a great proposal. It will also allow plugin authors to change the existing icons and use different formats when necessary.

Thanks for the fantastic work! I have a question about the custom link block variations in the editor. It may sound unusual, so I'd like to add a bit of context.

Our team builds an email editor using Gutenberg packages. We support the social links blocks, but because even some popular email clients can't handle SVGs we replace those with PNGs when we generate email for sending. This PR may help us simplify our code and use PNG directly. That's great.

The thing is that we currently operate with a limited list of supported icons we provide PNGs for. As this PR enables adding new services we might run into an issue that the newly registered service by a plugin will not work properly in our email editor and rendered email HTML.

So the strange question is: Is there a way to disable or filter these custom link block variations?

Thanks for the feedback, @costasovo!

You should be able to filter out the unsupported Social Link service. I assume you'll already have a list of services where you're replacing SVGs with PNGs. If the service isn't in that list, you can unset it using the block_core_social_link_get_services filter.

In the editor, you could do the same by using unregisterBlockVariation method.

@Mamaduka Thanks for the super-fast answer! I just want to confirm we are able to handle that using the way you suggested.

Thank you, everyone, for your feedback. I'm going to merge this.

I was thinking further about the extensibility on the editor side. Currently, the list of variations is static so it's difficult to change it. It's probably doable at the blocks store level, but that should be tested to confirm whether the same changes as applied on the server are possible to replicate in the editor.

I was thinking further about the extensibility on the editor side. Currently, the list of variations is static, so it's difficult to change it.

What do you mean by static? The Social Links are registered as block variations; you can register the new variations or remove the old ones.

It looks like you addressed it by introducing getSocialService, which takes an active variation as a parameter. I was looking at trunk before this PR landed 🙈

All good!