Add oEmbed support for WordPress.com

[johnbillion]

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

[danielbachhuber]

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.

[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.

[danielbachhuber]

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.

[stephdau]

@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.

[stephdau]

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

[kraftbj]

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.

[kraftbj]

Documentation: ​https://developer.wordpress.com/docs/oembed-provider-api/

[johnbillion]

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]

Functional patch to add WordPress.com as a provider.

[stephdau]

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

[stephdau]

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.

[stephdau]

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:

• ​https://tellyworthless.wordpress.com/2015/05/29/jetpag-swag-at-wcbne/
• ​https://public-api.wordpress.com/oembed/1.0?for=WP&maxwidth=660&maxheight=990&url=https%3A%2F%2Ftellyworthless.wordpress.com%2F2015%2F05%2F29%2Fjetpag-swag-at-wcbne%2F&format=json
• {"version":"1.0","provider_name":"Snapshots","provider_url":"http:\/\/tellyworthless.wordpress.com","author_name":"Alex","author_url":"https:\/\/tellyworthless.wordpress.com\/author\/tellyworth\/","title":"Jetpack swag at&nbsp;#wcbne","type":"link","html":"<p>&nbsp;<a href=\"https:\/\/tellyworthless.files.wordpress.com\/2015\/05\/img_4007.jpg\"><img src=\"https:\/\/tellyworthless.files.wordpress.com\/2015\/05\/img_4007.jpg\" alt=\"\"><\/a>&nbsp;<\/p>\n","thumbnail_url":"https:\/\/i0.wp.com\/tellyworthless.files.wordpress.com\/2015\/05\/img_4007-0.jpg?fit=660%2C990","thumbnail_height":494,"thumbnail_width":660}

[stephdau]

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.

[johnbillion]

Thanks Stephane

[georgestephanis]

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.

[obenland]

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

[wonderboymusic]

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

[johnbillion]

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

[pento]

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.

[johnbillion]

Closing in favour of #32522.