[wp-trac] [WordPress Trac] #64858: Add Threads as an oEmbed provider
WordPress Trac
noreply at wordpress.org
Wed Mar 18 21:49:52 UTC 2026
#64858: Add Threads as an oEmbed provider
-------------------------------------------------+-------------------------
Reporter: pmestevez | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone: Future
| Release
Component: Embeds | Version:
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests dev- | Focuses:
feedback |
-------------------------------------------------+-------------------------
Comment (by pmestevez):
Replying to [comment:12 swissspidy]:
> While we might potentially make this less strict and allow plain
blockquotes (#61127), the blockquote returned by the API is basically
empty except for a "View on Threads" text, which isn't really useful.
Yeah, the blockquote is just a fallback. The script is the one that
triggers loading the actual HTML. This is something that we could change
to enable auto-discovery. My main concern is how to determine the
dimensions of the iframe, but my team can take a look at this.
> I just tried using the oEmbed endpoint at
`https://graph.threads.net/v1.0/oembed?url=https://www.threads.com/@paul.0key/post/DV_pLGWAugC`
>
> Unfortunately it does not obey the `maxwidth` and `maxheight` request
parameters, as required by the spec (despite the docs saying otherwise).
There is no `height` response field either. Some other fields are absent
too but they're all optional, so that's fine.
The `maxHeight` parameter is documented as not supported; I believe it is
not that uncommon. We'll take a look at the `maxwidth` one, since it
should be respected within the documented supported range.
> Social Post Embed has 50+ active installs, and Social Post Embed does
not support Threads specifically. Jetpack also doesn't appear to support
it.
Not sure if we were looking at the same Social Post Embed plugin. I was
referring to [https://wordpress.com/plugins/social-post-embed this one],
which explicitly mentions support of Threads.
> That's great to hear indeed! I know how fast the wind can change at such
a big company thoigh, so I'm sure you understand there will be still some
reservations about this.
Yes, I do. To be fair, though, WordPress Core supports embeds from other
big companies. My hope is that we don't infer a pattern from a single
instance. You are preaching to the choir; we see the value and understand
the importance and we did our homework.
> The earliest this could land is in WordPress 7.1, due in August.
Understood. We can plan around that timeline and explore the auto-
discovery and plugin routes in the mean time.
> From my perspective, the biggest concerns are oEmbed spec compliance and
lack of trust because of past events. We don't want to have to remove this
again after 3-4 years like we had to with the Facebook embeds.
>
> We're generally more reserved towards adding new providers these days
because of stories like that. There are always some security
considerations as well since this allows inserting arbitrary unfiltered
HTML. That's why plugins are a great way to add new providers and usually
the recommended way before core adds support.
I understand. I believe the size and the relevance of the platform
warrants support in Core.
>
> At the moment my suggestion is as follows:
>
> - Threads to make sure `maxwidth` actually works and that the oEmbed
endpoint generally follows the spec
> - Embeds component maintainers to keep an eye on community adoption and
feedback
> - Maintainers to revisit this in June before 7.1 feature freeze
Sounds good. In addition to these, I will explore the possibility of
returning a properly sized iframe. Thanks!
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64858#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list