Embed blocks have all the same description text

[karmatosed]

Every embed has the following text:

Ideally it should say what the block is.

[gziolo]

By the way. Do we really need to maintain all those embed blocks? 😃
Can you link me to the issue where it was discussed to have its own block per service? Speaking myself, it seems similar to having its own version of Code block per language (PHP, CSS, HTML, etc.). It could also work as a single block which has combo box to select this type or even better with having this type autodetected based on url patterns.

[karmatosed]

@gziolo I'm not sure about that issue and I am totally not against having less embed blocks. I think though whatever ones we have we need to have better descriptions.

[gziolo]

Including @mtias @jasmussen in the discussion. Have we considered having only one Embed block which can be discovered in the inserter using all keywords we use at the moment and add a UI element which reflects embed’s type instead? To give an example, when I search for Twitter I find Embed block, we pass this keyword back to the block and it can use it to preselect Twitter as the type of embed. It would work in a similar way. We would have only one block in the inserter, we could reuse embeds tab to show the featured category (there are some requests to do it anyway), everything else should work basically the same.

I think we have this limitation to have 3 keywords per block type, but we can always relax it for core blocks 😎

[jasmussen]

By the way. Do we really need to maintain all those embed blocks? 😃

Well, we already do, and this is part of the point of having these embed aliases blocks in the first place. To recap:

• there is a single embed block that takes all the embeds
• there are multiple aliases, one alias for each WordPress upstream registered oembed handler

The 2nd part is key, because WordPress already maintains a whitelist of oembed handlers in the code. These are "paste and hope" in the current editor, in that you can't know which embeds are oembed supported until you try. By making explicit aliases for each already registered oembed, we surface them as officially WordPress supported embeds, that show up in search results in the inserter, and even visually if you're just exploring.

So yes, we do support them, and since we do, I can understand why it would make sense to have better descriptions for each. Though in order to not have to write oceans of prose that might have to change at the whim of the the embed service in question (like when Instagram changes their logo), perhaps we can look at some more computational descriptions. such as "This embed block embeds content from [embed block alias name]". I would hate to have to get creative with a description for the "funny or die" block.

Whether or not WordPress should officially support these blocks is a different matter. I wasn't personally part of the conversation when Oembed was implemented. But I do strongly feel that so long as a oembed whitelist handle exists, a block should exist for it. In other words, if we wanted to remove embed aliases in favor of just the generic one, I feel it would only be fair if that discussion included removing the entry from the oembed whitelist, so we no longer officially support that embed.

[karmatosed]

Though in order to not have to write oceans of prose that might have to change at the whim of the the embed service in question (like when Instagram changes their logo), perhaps we can look at some more computational descriptions. such as "This embed block embeds content from [embed block alias name]". I would hate to have to get creative with a description for the "funny or die" block.

I like that as a way forward.

[gziolo]

The 2nd part is key, because WordPress already maintains a whitelist of oembed handlers in the code. These are "paste and hope" in the current editor, in that you can't know which embeds are oembed supported until you try. By making explicit aliases for each already registered oembed, we surface them as officially WordPress supported embeds, that show up in search results in the inserter, and even visually if you're just exploring.

@jasmussen, it makes a lot of sense when you put it this way. Thanks for a very detailed answer. I like your proposal, it should be Good First Issue 👍

[ajitbohra]

@jasmussen
"This embed block embeds content from [embed block alias name]"
This looks perfect 💯