Reply Block: Embed referenced post when possible

[obenland]

Fixes #1027.

In this first pass the Mastodon embed provider only gets registered when the Reply block gets rendered. I'm open to making it generally available but initially it didn't feel like functionality that this plugin should be responsible for globally.

There's also an action to register additional Fediverse oembed providers beyond Mastodon.social. Not sure if there are others we should or need to consider.

The current implementation supports embedding posts from all supported oembed providers. I wasn't sure whether it should be limited to Mastodon or whether it should be all—please let me know if you have an opinion on that.

Finally, this maintains the anchor, that IndieWeb seems to be looking for.

Proposed changes:

• Adds oEmbed support to the reply block, automatically embedding content from supported platforms.
• Registers Mastodon as an oEmbed provider for better integration with Mastodon posts.

Other information:

• Have you written new tests for your changes?

Testing instructions:

Testing Reply Block with Mastodon Posts:

1. Create a new post.
2. Add a Reply block.
3. Enter a Mastodon post URL (e.g., https://mastodon.social/@obenland/113561729606054851).
4. Verify that:
   • The post is embedded above the reply link.
   • The reply link is still visible and functional.
   • The URL is properly formatted in the link text.

Testing with Non-Embeddable URLs:

1. Create a new post.
2. Add a Reply block.
3. Enter a URL that doesn't support oEmbed.
4. Verify that:
   • Only the reply link is shown (no embed).
   • The link is properly formatted.

Testing with Other oEmbed Providers:

1. Create a new post.
2. Add a Reply block.
3. Try URLs from other oEmbed-enabled platforms.
4. Verify that embeds work as expected while maintaining the reply link functionality.

[jeherve]

This is working really well, nice work!

I've tested it with replies to posts on mastodon.social as well as smaller instances not mentioned in this PR, and non-Mastodon instances (in which case you can get a 401 on the embed request) and it's all displayed nicely.

I had a question about the design.
On Mastodon, loading a reply clearly displays the reply in focus, and the original post above it in a darker color. In WordPress, the original post naturally gets displayed above the reply so it has more emphasis than the reply you're writing.
I wonder if it would be helpful to clearly indicate "in response to" above the embed, or something like that, so it's clearer that the embed is the original post you're responding to?

[pfefferle]

@obenland can you maybe add some example screenshots to the PR?

[jeherve]

@pfefferle You can check some examples on my own site right now:

• Reply to a mastodon.top message: https://herve.bzh/20250102-15328/
• Reply to a mastodon.social (added as embed source in this PR) message: https://herve.bzh/20240820-1963/
• Reply to a non-mastodon post: https://herve.bzh/20250108-15536/

[pfefferle]

Thanks a lot @jeherve !

Should we make this configurable? This is a very big block that we add to each post!?!

[pfefferle]

@obenland I added some microformats to match the https://indieweb.org/reply-context

[jeherve]

Should we make this configurable? This is a very big block that we add to each post!?!

That's a good question. I personally think it makes sense to provide all that context, but I could imagine some folks wanting a more consise display. How about adding a filter so folks could choose between an expanded and a compact view? Later on and if that proves necessary, we could make that a setting in the Reply block itself.

[mattwiebe]

Thanks for braving the branch in prod @jeherve 🫡🫡🫡

Got to bottom of the problem in 22be389 and decided to scratch one last itch that's been bugging me with the previous behaviour of "show nothing from the block when federating" - that's not how most platforms work, they show a @reply link. Why don't we do that too? 08bbd8e took care of that.

We should be good, with that, now. Let me know how things are on the UX front, cc @Automattic/fediverse as well, I think that this is really finally actually done (ducks)

[obenland]

Are we back to preferring the fallback embed handler over the mastodon embeds?

[obenland]

Embeds in the front-end don't get expanded anymore, I tested mastodon and WordPress embeds.

[obenland]

There's no way around the custom API endpoint?

[obenland]

With this function it looks like we can remove embed_get()?
I liked the attempt in embed_get() to get an oembed response first, should we do that here, too?

[mattwiebe]

Yes we can almost certainly get rid of oembed_get but I agree that I like its approach of serving a real oEmbed where we can get one. It's just that the lifecycle is very tricky because we can only use a pre_oembed_get filter, we can't filter on a not found attempt except in the way we're doing it by filtering the endpoint itself. I think there's a way to juggle all of this but it's precarious. But I would like to manage this compexity on the dev side in favour of user simplicity.

[obenland]

Suggested change

	'sanitize_callback' => 'esc_url_raw',
	'format' => 'uri',
	'required' => true,

With these changes most checks in validate() should be possible to remove

[mattwiebe]

Excellent. Nice to have a REST API sleuth on the job to compensate for my Windsurf slop ;)

[obenland]

Suggested change

	'callback' => array( $this, 'validate' ),
	'callback' => array( $this, 'get_items' ),

Let's reuse the format in WP_REST_Controller?

[obenland]

Suggested change

	'permission_callback' => array( $this, 'validate_url_permissions_check' ),
	'permission_callback' => array( $this, 'get_items_permissions_check' ),

[mattwiebe]

There's no way around the custom API endpoint?

We absolutely need it to some degree, it's the only way to give a reliable is_activitypub check. But maybe we can leverage more Core stuff.

[mattwiebe]

Demo'd this internally today. Two notes:

1. The default to optimistically show the embed is not working, at least not in the bookmarklet flow.
2. Our non-oEmbed, ActivityPub embeds (using core/embed) is not currently working in the Editor.

[mattwiebe]

I am going to add some more unit tests but I've fixed the bugs from yesterday's demo and this should be good for a hopefully-final round of testing!

What has improved:

1. Unregistered oEmbed providers will now render, using our ActivityPub template, even in the Core Embed block!
2. The bookmarklet will set embedPost=true so that there's a nice smooth flow there.
3. We stopped using the core/embed block for rendering oEmbeds because it was doubling and even tripling the embed (only inside our block, which means I was probably Doing It Wrong but I couldn't figure it out).