WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#32359 closed enhancement (wontfix)

Add oEmbed support for WordPress.com

Reported by: johnbillion Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Embeds Keywords: has-patch
Focuses: Cc:

Description

WordPress.com provides an oEmbed endpoint for all of its sites. This is discoverable via link elements in the header at each article permalink.

While WordPress.com itself is a more than appropriate candidate for oEmbed support in WordPress core, we need to assess its oEmbed endpoint, its documentation, and its stability.

cc-ing @stephdau because I know he's worked on this. Steph, can you provide some details? Is the endpoint stable?

oEmbed provider consideration points: https://make.wordpress.org/core/handbook/design-decisions/#whitelisting-oembed-providers

Example endpoint: https://public-api.wordpress.com/oembed/1.0/?format=json&url=https%3A%2F%2Fmatt.wordpress.com%2F2015%2F04%2F30%2F7574%2F&for=wpcom-auto-discovery

Attachments (5)

32359.diff (1.2 KB) - added by stephdau 4 years ago.
Functional patch to add WordPress.com as a provider.
32359.1.diff (18.6 KB) - added by stephdau 4 years ago.
Same as 32359.diff, but with required whitespace reformatting.
Screenshot from 2015-06-04 11:53:55.png (165.2 KB) - added by stephdau 4 years ago.
Screenshot from 2015-06-04 11:54:07.png (159.2 KB) - added by stephdau 4 years ago.
Screenshot from 2015-06-04 11:54:26.png (115.7 KB) - added by stephdau 4 years ago.

Download all attachments as: .zip

Change History (24)

#1 @danielbachhuber
4 years ago

Something to consider: WordPress.com adds oEmbed to the header for WordPress.com VIP sites, which is annoying because it's often an inaccurate representation of the content.

I realize this is more of an issue for WordPress.com than core, but I've gotten the silent treatment from VIP about giving clients ability to modify or disable the endpoint, and can see problems arising if suddenly our content was inaccurately auto-embedding across the web.

If Jetpack tries to pull this automagical behavior too, same consideration applies.

#2 follow-up: @georgestephanis
4 years ago

I'm not expecting it in Jetpack, and honestly I'd love to see a way to customize the return data for VIP sites. I'm not sure why they can't -- do you have any documentation links? Happy to do a quick look into it.

#3 in reply to: ↑ 2 @danielbachhuber
4 years ago

Replying to georgestephanis:

I'm not expecting it in Jetpack, and honestly I'd love to see a way to customize the return data for VIP sites. I'm not sure why they can't -- do you have any documentation links? Happy to do a quick look into it.

I've private-messaged you our existing ZD ticket.

#4 @stephdau
4 years ago

@johnbillion: The full docs for the endpoint are at https://developer.wordpress.com/docs/oembed-provider-api/ . It is considered stable. It was first brought online to cater to Twitter, when powered their in-tweet preview feature with oEmbed (which they now use Twitter Cards and Open Graph to instead).

@danielbachhuber: unless you specifically request the content as_article (in which case it is excerpted, was a Twitter requirement/mode), the_content filter is applied on the content, as anywhere, and can be hooked on. VIPs have their env loaded, so their shortcodes/etc work too.

Last edited 4 years ago by stephdau (previous) (diff)

#5 @stephdau
4 years ago

Dan: checked, couldn't see any other valuable filter/actions at the moment. I'll leave @georgestephanis to it.

#6 follow-up: @kraftbj
4 years ago

While George and Daniel chat privately about the WP.com/VIP side of this:

Whitelisting oembed providers is by domain, so for this, I would assume *.wordpress.com. VIPs wouldn't be included in this, out of the box, unless add_filter( 'embed_oembed_discover', '__return_true' ); is set or the VIP is on a WordPress.com subdomain.

#8 in reply to: ↑ 6 @johnbillion
4 years ago

Replying to kraftbj:

Whitelisting oembed providers is by domain, so for this, I would assume *.wordpress.com. VIPs wouldn't be included in this, out of the box, unless add_filter( 'embed_oembed_discover', '__return_true' ); is set or the VIP is on a WordPress.com subdomain.

Correct, this would only cover *.wordpress.com domains. We have the same issue for custom domains on Tumblr: #31975

@stephdau
4 years ago

Functional patch to add WordPress.com as a provider.

@stephdau
4 years ago

Same as 32359.diff, but with required whitespace reformatting.

#9 @stephdau
4 years ago

I've added 2 patches, as a mean to maybe kickstart this happening.

  • 32359.diff is the suggested functional change
  • 32359.1.diff is the same, coupled with the required whitespace reformatting required because WordPress.com's name adds an extra space. :)

The change adds #https?://[^/]+\.wordpress\.com/[\d/]+/.+#i as a provider, which checks for:

  • https?://[^/]+\.: WPCOM subdomain (caret-slash to avoid URL based trickery)
  • /[\d/]+/.+: WPCOM doesn't allow users to modif the URL structure, so digit or slash (/2015/06/04/), then slug

The API URL passes the basic for identifier (set as WP), as required by WPCOM.

This only results in basic support (links), for now,and until a proper view handler is also written, which would be the next step. I've never written one of those, help appreciated. :)

See attached screenshots.

Last edited 4 years ago by stephdau (previous) (diff)

#10 @stephdau
4 years ago

Note: the oEmbed payload received from the API allows for more than just the links showcased in the screenshots. That's just core's most basic handling. It returns HTML, a thumbnail_url, etc.

EG:

This ticket was mentioned in Slack in #design by stephdau. View the logs.


4 years ago

#12 follow-up: @stephdau
4 years ago

After playing with the API and code, I found out that the fact that the output as link is due to the WPCOM API return type:link, instead of type:rich.

We should put this on pause until WPCOM figures out a better output for posts, as the current one isn't that great.

#13 @johnbillion
4 years ago

Thanks Stephane

#14 @georgestephanis
4 years ago

I'd object to that regex, it feels overly broad when specifying the subdomains.

#https?://[^/]+\.wordpress\.com/[\d/]+/.+#i

I'd far sooner see the subdomain logic done as [a-z\d]{4,50} -- alphanumeric, and between four and fifty characters, inclusive. WPCOM subdomains also cannot contain dashes or underscores, so that regex should be much more accurate, unless you intended to also include things like en.blog.wordpress.com or the like.

If you did want to include en.blog I'd suggest changing it to [a-z\d\.]{4,50} to include double subdomains.

Last edited 4 years ago by georgestephanis (previous) (diff)

#15 @obenland
4 years ago

We have two more weeks before beta, what needs to be done to get this over the finish line until then?

#16 in reply to: ↑ 12 @wonderboymusic
4 years ago

  • Milestone changed from 4.3 to Future Release

Replying to stephdau:

We should put this on pause until WPCOM figures out a better output for posts, as the current one isn't that great.

Indeed

#17 @johnbillion
4 years ago

  • Keywords has-patch added; needs-patch 2nd-opinion removed

@stephdau Think you might be able to take a look at the WP.com oEmbed format in time for 4.4?

#18 @pento
4 years ago

I'm inclined to wait until the oEmbed feature plugin lands, as (ideally) we should be deprecating WP.com's current oEmbed format, and that'll give us WP.com oEmbed for free.

#19 @johnbillion
4 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing in favour of #32522.

Note: See TracTickets for help on using tickets.