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]

If you try to use a non-oembed link, it does lock the preview button.

@pfefferle do you mean when you're trying to embed a non-ActivityPub oEmbed?

[pfefferle]

@mattwiebe if I use a mastodon instance that is not in the allow-list for example.

As far as I understood the PR, the plugin should fall back to use ActivityPub to generate a preview based on that data, but that part does not work properly.

[mattwiebe]

@mattwiebe if I use a mastodon instance that is not in the allow-list for example.

As far as I understood the PR, the plugin should fall back to use ActivityPub to generate a preview based on that data, but that part does not work properly.

In this case it was mastodon.art that was causing the trouble. It fails when fetching an ActivityPub representation with a 401 Unauthorized error and the message {"error":"Request not signed"}. So it appears that it requires AUTHORIZED_FETCH to be enabled.

In cases like this, when it is not enabled, it would be nice to do a retry with authorized fetch. I will restrain myself from bloating this PR further heh.

[pfefferle]

🤔

I thought we always send the signature... also for GET... I will check that and also check the preview with a different (not whitelisted) instance...

[pfefferle]

Ah, I see... This is because of localhost! We send the signature, but it can't be verified, because the remote server can not access localhost!

With a bonn.social site, it works like expected!

[jeherve]

I gave this PR another try, and currently run into this issue when I try to activate embedding for an existing post (with an embed from mastodon.social)

The same error appears on the frontend when I save my changes:
https://herve.bzh/sorvagsvatn-un-lac-aux-iles-feroe/

Interestingly, that error seems to be in response to an embed request using a Friends endpoint:

https://herve.bzh/wp-json/friends/v1/embed?url=https://mastodon.social/@STPo/114182842753572276#?secret=xxxx

This may indicate a conflict with the Friends plugin (cc @akirk )

It doesn't happen with all replies, though. Another one is displayed properly for example (although I still run into the scrollbar issue I mentioned earlier).

The issue with duplicate mentions remains, though:

[mattwiebe]

I think we're done here. I haven't been able to replicate @jeherve's embed failures, even alongside Friends. I moved to a shorter handle in replies to match #1510 .

We already had an approval from @pfefferle and @obenland would you mind one final test?

[pfefferle]

It looks a bit strange if you try to use the URL of a Blog that has ActivityPub enabled:

Neither the Embed-Code nor the ActivityPub representation seems to be used 🤔

[mattwiebe]

Neither the Embed-Code nor the ActivityPub representation seems to be used

Yeah that's not good. The neverending PR continues to never end. :/

[mattwiebe]

Ok, the WP embed has been solved.

Unfortunately notiz.blog will not be embeddable because of x-frame-options:

curl -I https://notiz.blog/2025/03/24/blogtastisch-2-blogs-und-das-fediverse/embed/ 
HTTP/2 200
date: Mon, 31 Mar 2025 23:55:53 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
server: nginx
x-cache: miss
x-pingback: https://notiz.blog/xmlrpc.php
link: <https://notiz.blog/wp-api/webmention/1.0/endpoint>; rel="webmention", <https://notiz.blog/wp-api/webmention/1.0/endpoint>; rel="http://webmention.org/", <https://notiz.blog/wp-api/>; rel="https://api.w.org/", <https://notiz.blog/wp-api/wp/v2/posts/53144>; rel="alternate"; title="JSON"; type="application/json", <https://notiz.blog/b/Ekj>; rel=shortlink
server-timing: wp-total;dur=63.49
cache-control: max-age=0, public
expires: Mon, 31 Mar 2025 23:55:53 GMT
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=31536000
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-clacks-overhead: GNU Terry Pratchett

A perfect solution would then fall back to the ActivityPub representation, but I'm not doing that. :)

[jeherve]

I'm still running into the same embed issues with Friends, but since that seems specific to my setup I'll let others test!

[jeherve]

Do we need the wrapper to be a paragraph? Could it be a span? I'm mostly asking because it feels off to have the mention displayed on its own line before the reply. That's not what we typically see in other Fediverse software ; the @mention is usually immediately followed by the content.

[obenland]

It doesn't look like removing the p makes much of a difference when using the block editor, even if we removed wpautop(), too. The following paragraph will be wrapped in its own paragraph tag and displayed on a new line.

[obenland]

@pfefferle @jeherve I think we've spent enough time on this PR, it's decision-time. Let's either merge it or close it. I'm happy for us to create follow-up PRs once it's in, but at some point we have to call it on this one, and I think this is it.