[wp-trac] [WordPress Trac] #64858: Add Threads as an oEmbed provider

[WordPress Trac]

#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 swissspidy):

 > A quick update from my end. I looked into whether auto-discovery could
 be a fallback here, and I do not think it will work in practice because
 for non-allowlisted providers WordPress sanitizes the returned oEmbed
 HTML, strips the <script> tag, and then rejects the result if no <iframe>
 remains. Since the current Threads response is blockquote + script rather
 than iframe, discovery alone does not appear sufficient.

 Thanks for the update. That makes sense to me.

 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.

 > > Is its oEmbed endpoint clearly established and properly documented?
 (Sometimes, they are just a developer’s pet project that may not be
 supported.)
 > Yes. The initial endpoint was released in December of 2024 and the
 tokenless endpoint used by this proposed change was released in March of
 2026. The endpoint is documented at
 https://developers.facebook.com/docs/threads/tools-and-resources/embed-a
 -threads-post

 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.

 > > Has anyone written a WordPress plugin that leverages the service in
 some way, whether adding it as an oEmbed provider, creating a shortcode,
 or leveraging other APIs of the service? Do these plugins have any
 noticeable adoption or traction that would indicate usage and demand?
 > Yes. There is at least one dedicated WordPress.org plugin, Social Post
 Embed, whose stated purpose is to support Threads embeds until they become
 part of WordPress core. There is also broader ecosystem demand through
 large embedding plugins such as EmbedPress, which has 100,000+ active
 installations and markets support for embedding social content from many
 sources.

 Social Post Embed has 50+ active installs, and Social Post Embed does not
 support Threads specifically. Jetpack also doesn't appear to support it.

 > > Is the provider frequently proposed?
 > I don't have a lot of data points here but given the anecdotal evidence
 that my team has collected, the search results for tickets on this page,
 and the platform growth, I would say yes.

 With various `site:wordpress.org` searches I couldn't find anything.

 > My team and I took the time to argue why that decision was extreme, have
 secured the necessary approvals for Threads, and in fact, we also plan to
 remove the access token requirement from the Facebook and Instagram APIs.
 >
 > I hope that the community can understand that I represent the team that
 has advocated for the importance of having embeds available in platforms
 like WordPress, and that we don't base the decision to support Threads on
 what we are acknowledging as an extreme measure.

 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.

 > Separately, it'd be great to understand what the final process is for
 deciding whether a provider like Threads can be added as a supported
 oEmbed provider in core. It would also be helpful to understand the
 expected timeline for that decision, or whether there are specific
 remaining criteria this proposal needs to satisfy.

 The earliest this could land is in WordPress 7.1, due in August.

 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.

 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64858#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform