WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#32522 closed enhancement (fixed)

Embed WordPress Posts in WordPress Posts

Reported by: melchoyce Owned by: pento
Milestone: 4.4 Priority: normal
Severity: normal Version:
Component: Embeds Keywords: has-patch commit
Focuses: Cc:
PR Number:

Description

I keep finding myself pasting WordPress URLs into my posts, expecting them to embed like every other thing I paste into my posts, but alas, I cannot embed a WordPress post in another WordPress post. Wouldn't that be cool, though?

Attachments (16)

WP-Embed-1.png (161.4 KB) - added by melchoyce 4 years ago.
WP-Embed-2.png (154.2 KB) - added by melchoyce 4 years ago.
WP-Embed-3-%22Typographic%22.png (96.1 KB) - added by folletto 4 years ago.
WP Embed 3 "Typographic"
wp-embed-folletto.jpg (136.0 KB) - added by melchoyce 4 years ago.
wp-embed.jpg (355.6 KB) - added by melchoyce 4 years ago.
embed-test-1.jpg (617.1 KB) - added by melchoyce 4 years ago.
embed-test-1-noquote.jpg (615.1 KB) - added by melchoyce 4 years ago.
embed-test-2.jpg (872.0 KB) - added by melchoyce 4 years ago.
link-preview-not-oembed.png (21.1 KB) - added by ramiy 4 years ago.
32522.diff (105.8 KB) - added by swissspidy 4 years ago.
First patch for merging the oEmbed API plugin
32522.2.diff (110.1 KB) - added by pento 4 years ago.
32522.3.diff (109.4 KB) - added by jeremyfelt 4 years ago.
32522.4.diff (109.5 KB) - added by pento 4 years ago.
32522.5.diff (85.8 KB) - added by wonderboymusic 4 years ago.
32522.6.diff (87.6 KB) - added by pento 4 years ago.
32522.7.diff (88.1 KB) - added by pento 4 years ago.

Change History (99)

#1 @swissspidy
5 years ago

Definitely! And easily possible with the upcoming REST API. I even wrote a plugin for that. I might update it over the weekend to be compatible with the recent API version. After that it could become a feature plugin maybe?

The biggest question probably is how embedded content should look like. Simple HTML with header and excerpt? Or something more advanced?

#2 @ocean90
5 years ago

Related: #32359

#3 @markhowellsmead
5 years ago

+1 for that idea. Would be fantastic. Perhaps the best solution would be to pull whatever would be provided to the RSS feed? That would allow those of us who - for example - add thumbnails to the RSS feed via hooks to hook this REST response too.

Last edited 5 years ago by markhowellsmead (previous) (diff)

#5 follow-up: @ramiy
5 years ago

I don't think it a good idea.

When I paste WordPress URLs into my posts, I want to show simple links, I don't want to embed the content from the URL.

#6 in reply to: ↑ 5 ; follow-up: @swissspidy
5 years ago

Replying to ramiy:

I don't think it a good idea.

When I paste WordPress URLs into my posts, I want to show simple links, I don't want to embed the content from the URL.

Well, this wouldn't change at all. You could still add links as usual. A post would only get embedded if you put it on a new line, just like with other oEmbed providers.

Also, as oEmbed providers are whitelisted, your own posts get embedded automatically. Other sites must be whitelisted.

#7 @swissspidy
5 years ago

I just updated the plugin I mentioned on GitHub to leverage the 2.x branch of the REST API. What it currently does:

  • Register your site as an oEmbed provider
  • Add a new route with the oembed/v1 namespace, e.g. http://example.com/wp-json/oembed/v1/oembed/
  • Add a oEmbed discovery in the <head> of single posts/pages

The output is very simple at the moment as it just returns the post content and associated image data if available. The preview in the editor already works: https://cloudup.com/cQL2DD87bPm

#8 in reply to: ↑ 6 ; follow-ups: @ramiy
5 years ago

Replying to swissspidy:

Replying to ramiy:

I don't think it a good idea.

When I paste WordPress URLs into my posts, I want to show simple links, I don't want to embed the content from the URL.

Well, this wouldn't change at all. You could still add links as usual. A post would only get embedded if you put it on a new line, just like with other oEmbed providers.

Also, as oEmbed providers are whitelisted, your own posts get embedded automatically. Other sites must be whitelisted.

First, What if I want to show my link in a new line?

Second, you can whitelist your own blog post using a plugin. It should not be a core feature.

If it become a core feature, all the wordpress sites around the world with internal links in new line will become embedded content, although it wasn't the intention. Sorry, It doesn't make sense, it's a plugin territory.

#9 in reply to: ↑ 8 @melchoyce
5 years ago

Replying to ramiy:

First, What if I want to show my link in a new line?

You create a link. :)

#10 in reply to: ↑ 8 @knutsp
5 years ago

Replying to ramiy:

If it become a core feature, all the wordpress sites around the world with internal links in new line will become embedded content, although it wasn't the intention.

Will not happen. You don't create a link by pasting a URL on a new line. A URL is not the same as a link. A link is created by the html a element, using the Link button in the editor.

An embed is created by just pasting a an URL on a new line, without creating a link.

#11 @pento
4 years ago

@melchoyce - Do you have thoughts on what an embedded post might look like? (On the front end and in the editor.)

Combining @swissspidy's plugin with oEmbed auto-discovery and a nice way of displaying content would make an interesting feature plugin.

@melchoyce
4 years ago

@melchoyce
4 years ago

#12 @melchoyce
4 years ago

Just attached two wireframe ideas for embeds. We should determine what information we want to show in an embed before doing anything more high fidelity.

In these wireframes, I've added:

  • Site icon (w/ a fallback to the WP logo if there is none)
  • Site title
  • Site tagline (optional)
  • Featured image (optional)
  • Post (or page) title
  • Excerpt (optional)
  • View post (or page) link
  • Comment count
  • Share (would need to determine how this would work & design additional screen)

Is there any information that seems superfluous? Is there any information missing?

#13 @melchoyce
4 years ago

For reference, I've put together a gallery of other embed designs: https://cloudup.com/cGpHVksX4WB

#14 follow-up: @folletto
4 years ago

I'm wondering if it would be possible to have a look that while "separates" itself from the page, would embrace more the fact it's likely a quote or a reference to something else (maybe even quoting a piece of the article in some way, that's probably challenging but would be perfect). Not necessarily looking like a "blockquote" itself, but maybe something that typographically hints at that use? :)

@folletto
4 years ago

WP Embed 3 "Typographic"

#15 in reply to: ↑ 14 @melchoyce
4 years ago

Replying to folletto:

I'm wondering if it would be possible to have a look that while "separates" itself from the page, would embrace more the fact it's likely a quote or a reference to something else (maybe even quoting a piece of the article in some way, that's probably challenging but would be perfect). Not necessarily looking like a "blockquote" itself, but maybe something that typographically hints at that use? :)

Were you thinking something as simple as wp-embed-folletto.jpg?

@melchoyce
4 years ago

#16 @melchoyce
4 years ago

Since I'd already gotten started, I tried out wireframe v1 as a mockup as well in wp-embed.jpg.

#17 @markhowellsmead
4 years ago

I like that the most recent screenshot aligns itself to other embeds. But the embed should be easily customisable for devs who want to customise the design on their own blog.

#18 follow-up: @folletto
4 years ago

@markhowellsmead Do you mean customizable at the source or at the embed location? — I agree in terms of source. ;)

@melchoyce Yeah. Something in that direction I feel works well. I just think it should "flow" well when added inside a post, as well as working standalone (so maybe shouldn't be so much a blockquote as my wireframes explored?). So... thinking out loud... we should maybe try to design them inside context, starting maybe with a long-ish TwentyFifteen post and see how it looks there and if it fits well?

#19 @melchoyce
4 years ago

Added a couple explorations of embeds in a Twenty Fifteen post. The quote-style works well because it can comfortably expand and contract based on post width. The more elaborate embed doesn't work as much... which isn't atypical for embeds, since most of the "service" embeds (facebook, google +) seem to have a max-width as well. For the quote-style, I tried with and without the quote icon.

#20 @pento
4 years ago

These are some shiny options, I like the direction this is headed. :-) Thanks @melchoyce and @folletto!

In embed-test-2.jpg, is there any reason why it couldn't be the width of the post? Presumably we can ask the source site for an appropriately sized feature image.

A problem that I'd like to consider - most oEmbeds work by inserting an iframe pointing back at the source site. Do we want to go that route (allowing source sites complete control over their content), or do we want to cache the embed data on the host site (allowing styling of the embed, and making sure the embed is still available if the source site does down).

I'm not wild about the YouTube route of allowing some styling through iframe URL parameters, as a compromise.

#21 follow-up: @melchoyce
4 years ago

In embed-test-2.jpg​, is there any reason why it couldn't be the width of the post? Presumably we can ask the source site for an appropriately sized feature image.

It wouldn't handle edge-cases well — if someone has a super wide post area, the featured image could get really big.

The full width of Twenty Fifteen is very reasonable, but even that's starting to reach the upper level of what's comfortable: https://cloudup.com/cWecCJ5pB4z

(At a nice post width it does look pretty good, though)

A problem that I'd like to consider - most oEmbeds work by inserting an iframe pointing back at the source site. Do we want to go that route (allowing source sites complete control over their content), or do we want to cache the embed data on the host site (allowing styling of the embed, and making sure the embed is still available if the source site does down).

I'm not sure I have an opinion on this, since I can see the argument for either. Is there a best practice?

#22 in reply to: ↑ 21 @pento
4 years ago

Replying to melchoyce:

It wouldn't handle edge-cases well — if someone has a super wide post area, the featured image could get really big.

Good point. Even if we tried to limit the height of the image (assuming we could magically make an image cropper that isn't terrible), I suspect it'd still look weird stretched to super wide.

(At a nice post width it does look pretty good, though)

Perhaps we could do width: 100%; max-width: something-sane?

I'm not sure I have an opinion on this, since I can see the argument for either. Is there a best practice?

Here's a quick rundown of what some folks do:

Instagram: iframe
Meetup: Embedded content and CSS, no JS
Soundcloud: iframe
Tumblr: Empty placeholder div, post loaded by JS
Twitter: Placeholder blockquote with content, JS to load styling
YouTube: iframe
Vimeo: iframe
Vine: iframe and JS

Facebook and G+ don't support oEmbed, but both of their standard embed code is an empty placeholder, with JS to load the post.

For security, we wouldn't allow JS or CSS from the remote site to be embedded in the page - it can too easily be used as an attack vector.

Unless there's a particularly good reason for the host site to be able to apply their own styling, I'm leaning towards the iframe method. We can provide a nice default style for embeds, then a source can customise any bits that they want to. The host will still maintain control of embed size, so a malicious source can't take over the page. The source doesn't get as many customisation options, but that's not really the point of oEmbeds.

#23 @swissspidy
4 years ago

Awesome to see so much progress here. I really like these mockups!

For security, we wouldn't allow JS or CSS from the remote site to be embedded in the page - it can too easily be used as an attack vector.

I think this is enough reason to not use JS. As I have previously built an oEmbed plugin, I support using iframes with a defined max-width.

Regarding the different styling options: The only difference between embed-test-1-noquote.jpg and embed-test-2.jpg is the featured image, while embed-test-1.jpg looks like a quote post format. And post formats are usually theme territory.

We should definitely propose this as a feature plugin for tomorrow's chat. Afterwards I can implement the ideas so far in the oEmbed-API plugin, which we all could collaborate on on GitHub.

#24 @folletto
4 years ago

The only difference between embed-test-1-noquote.jpg​ and embed-test-2.jpg​ is the featured image

Uh not really the only difference. :D
The whole layout changes. ;)

That said, I agree that seen in context we shouldn't make it a "blockquote" look. I'd go for embed-test-1-noquote. :)

I support using iframes with a defined max-width.

+1

#25 @pento
4 years ago

Sounds like we have a good starting point!

@swissspidy, @melchoyce: Due to timezone differences, I'm not online for feature plugin chat. Would either/both of you be able to present it as a candidate?

I'm happy to contribute to the plugin, be around for plugin chats, and shepherd it into Core when it's ready, of course. :-)

#26 in reply to: ↑ 18 @markhowellsmead
4 years ago

Replying to folletto:

@markhowellsmead Do you mean customizable at the source or at the embed location? — I agree in terms of source. ;)

Both! The content provider should be able to define which information is included in the embeds of her/his content on other blogs, e.g. no images.

The person sharing it on her/his blog should be able to make the same decision; either through parameters passed by the oEmbed call, or via CSS.

The handling of how wide/narrow the embed is by default should be at the control of the receiving blog, not the creator blog. e.g. via $content_width, in the same way that it works for e.g. YouTube embeds now.

Just anything except a non-customizable iframe!

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

#27 follow-up: @folletto
4 years ago

I feel that if a user wants more control they can just normally quote with a reference. That gives complete control, and it's already doable quickly with Press This. Embeds should be straightforward and in a sense standardized. I'm sure then we can allow filters and plugins if someone wants to process them further, once the standard implementation is built. So it's not like we lock them out entirely going for the default route.

I agree however that there should be some degree of flexibility for the embed (like disabling the banner image or defining the max-width), I'd look into these. :)

#28 follow-up: @swissspidy
4 years ago

@swissspidy, @melchoyce: Due to timezone differences, I'm not online for feature plugin chat. Would either/both of you be able to present it as a candidate?

Yeah I'm around to tomorrow and able to present it (together with @melchoyce?).

The handling of how wide/narrow the embed is by default should be at the control of the receiving blog, not the creator blog. e.g. via $content_width, in the same way that it works for e.g. YouTube embeds now.

WordPress sends the preferred width for oEmbeds by default, so no worries here :)

#29 in reply to: ↑ 27 @markhowellsmead
4 years ago

Embeds should be straightforward and in a sense standardized. I'm sure then we can allow filters and plugins if someone wants to process them further, once the standard implementation is built.

That makes sense. A staged process, with the basis at first and improvements later, is the way to go for me, too. Filters around the output are essential, but if I understand the current oEmbed tech. correctly, this is already possible.

#30 in reply to: ↑ 28 @melchoyce
4 years ago

Replying to swissspidy:

@swissspidy, @melchoyce: Due to timezone differences, I'm not online for feature plugin chat. Would either/both of you be able to present it as a candidate?

Yeah I'm around to tomorrow and able to present it (together with @melchoyce?).

I have a meeting during that time, so I won't be able to make it.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


4 years ago

#32 follow-up: @Viper007Bond
4 years ago

As cool as this would be, I'm not sure how feasible it is. oEmbed requires too much trust. If we do this, it's going to require some very major rethinking of the whole embeds process in WordPress. It's a much, much larger discussion than just "let's embed WordPress posts".

oEmbed discovery is currently disabled within WordPress. That means if the URL doesn't match the oEmbed whitelist, then it's ignored and becomes a regular clickable link.

Allowing you to embed a post from any WordPress-powered website would require turning oEmbed discovery on. That means for a URL that isn't on the whitelist, we would connect to the URL and inspect the <head> looking for oEmbed tags. If we found one, we'd connect to the endpoint and be given HTML that would then be inserted right into the post.

That works only if we trust the remote site to provide us with safe HTML. It's why we have the whitelist and only add sites that we are confident aren't going to start returning malicious HTML. If YouTube wanted to, they could inject bad HTML into millions of WordPress sites pretty easily.

So for any site that's not on the whitelist, we would need to apply some type of sanitization to the response, such as ignoring any response that isn't the rich type. We then run the HTML through kses to strip it down to safe HTML (formatting and links, maybe even less). We'd then build the embed HTML locally and inject the safe, remote text (title, content, etc.) into it.

iframes aren't a solution either for a number of reasons. What if a post from my tiny little website gets embedded into a popular website? First off, my server is then being hammered with traffic. Secondly, I could then abuse that and have my website serve different content such as advertisements or even disgusting images. The content that the popular website expected to be displayed is not longer being displayed. Everything needs to be local.

We also need to make sure we aren't ever expiring caches of the local content. If the remote post is edited, we need to not be pulling down an updated copy because again, the other site could edit their post to contain lots of explicit content.

Images need to be mirrored locally for the exact same reason. I don't want to embed your image on my site only to have you replace the image with something else.

The list goes on from there on things to think about in order to make this safe.

It's not as straightforward as it seems.

#33 @WraithKenny
4 years ago

I'm thinking that if the technology is there, the decisions would be up to the users (opt in, site by site basis). The user of Site A would make the choice to enable oembed (off by default), considering for herself whether her server could handle the load (if iframes are used) and the user of Site B would make the informed decision of whether to trust Site A's embed content, and if so, add it to their own locally extended whitelist. This frees us from those concerns that you've outlined (even sanitation concerns: we don't sanitize YouTube do we?).

In other words, don't enable the oembed provider by default, and don't add any sites to the whitelist. Let the admins enable those.

Our concerns would be for the opt in processes on both ends (UI, filters/actions) and the type of embed format (iframe, other, or both).

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

#34 @dmchale
4 years ago

As much as I like this idea - i really do - I think Viper007Bond makes a very strong argument.

WraithKenny, you're correct that oEmbed discovery could be disabled by default, but I would then have to ask... if it's disabled by default, why are we including it in core? I guess it would allow you to certainly embed content from your own sites that you control, but at that point doesn't that smell strongly like plugin territory?

I think the safest way to accomplish something like this would be what is suggested in #32955 and do this WITHOUT oEmbed. If we allow WordPress to generate an embed similar to how Facebook does it, we can still draw data from ANY other website on the internet to create a preview. No, it's not a full embed but this is a compromise. If we implemented something like that inside core, we could even rely on the existing OpenGraph meta tags that Facebook uses - website owners are already providing that information anyway.

$total += 0.02;

#35 in reply to: ↑ 32 ; follow-up: @pento
4 years ago

Replying to Viper007Bond:

iframes aren't a solution either for a number of reasons.

I disagree, I think iframes are absolutely the correct solution. They easily solve all of the security issues you mentioned.

What if a post from my tiny little website gets embedded into a popular website? First off, my server is then being hammered with traffic.

This is exactly the same as what happens if your site hits the front page of HN or Reddit - we don't provide a core solution for that, either.

Secondly, I could then abuse that and have my website serve different content such as advertisements or even disgusting images. The content that the popular website expected to be displayed is not longer being displayed. Everything needs to be local.

You can do the same thing with tumblr embeds. I don't think this is an issue we need to be concerned about.

Replying to WraithKenny:

In other words, don't enable the oembed provider by default, and don't add any sites to the whitelist. Let the admins enable those.

There's no point in doing this if it isn't enabled by default. The same as we've done for most new core features, there should be no UI to disable it, either - there'll be plugins that will disable it if you really want to opt out.

#36 in reply to: ↑ 35 @Ipstenu
4 years ago

I love/hate this idea.

Replying to pento:

Replying to Viper007Bond:

What if a post from my tiny little website gets embedded into a popular website? First off, my server is then being hammered with traffic.

This is exactly the same as what happens if your site hits the front page of HN or Reddit - we don't provide a core solution for that, either.

This would probably cause an uptick in people coding ways to break iframes (X-FRAME-OPTIONS or JS at this point).

The difference here between YouTube and Instagram and Tumblr is they all agreed to let other people embed their content. That's why they have the API endpoint. Each individual user of WordPress did not. It's a consent issue. Just as you can set your YouTube videos to be embeddable, it's a check box on each post (or on your channel, I forget which).

FWIW, there's also the concern of monetization. I don't know what happens when my ads show up on your site. I'd hate to find out I broke Google's AdSense rules just because someone else embedded me on their porn site.

#37 @dmchale
4 years ago

I think it's also the matter of trust, as was mentioned above. The current process for being whitelisted as an oEmbed provider gets thrown out the window if we suddenly start trusting the content of every link that comes from a site built on WordPress, aka almost a quarter of the internet. And if we're blindly looking for an endpoint without using the domain as a means of trust, what's to stop someone from simply building a similar-looking endpoint on a site that isn't even running WordPress, and sending back whatever potentially-malicious content they please?

If I were a Bad Guy(tm), you can bet that the first thing I would do is start figuring out how to get my code injecting into other people's sites via oEmbed (*especially* if core implemented this as an enabled-by-default feature and not just an option). Then you just wait for people to link/embed to a site you control - by legitimate means or otherwise.

If anyone has a counter-point, I'd love to be proved wrong. I'm not seeing it myself though.

#38 @WraithKenny
4 years ago

Correct me if I'm wrong, but isn't whether it's an iframe or not up to the oembed provider? Also, enabling oembed providing, and enabling oembed consuming, are two different things with completely different concerns.

I agree with @Ipstenu's point about consent of sharing content (should be opt in) and the idea of a checkbox on each post page (like enable comments) is a good one. I think that a site that is an oembed provider is implicitly granting permission to share (i.e. use on 3rd party sites) any content that is available through the oembed feature, and I think that'd be an inappropriate thing to do globally by default, but a UI similar to enable comments would solve that.

As for the Google's AdSense point, I think that simply not including that content in the embed output would avoid that issue. I think that even intentionally including Google's code would require lots of hoops to jump threw anyway and wouldn't 'accidentally' happen (AdSense Ads aren't JS-free markup compatible with, and inserted into, the post editor by default right?).

#39 @pento
4 years ago

This would probably cause an uptick in people coding ways to break iframes (X-FRAME-OPTIONS or JS at this point).

I don't think we'd try to prevent X-FRAME-OPTIONS, that's a good way for someone to forcibly prevent their site from being embedded.

Because we don't really want to allow frame-busting, we could combine the sandbox attribute for modern browsers, and the security attribute for IE6+, to prevent JS from running in the iframe. (This would also prevent someone from showing their AdSense on a site they've been embedded on).

Of course, there's almost always a technical solution to every technical problem. This doesn't solve the issues of consent and trust, I absolutely agree that we should be discussing these.

The first feature chat will be on Monday (21:00UTC, 17:00EDT), there'll be a make/core post going up before then. If everyone is amenable to this, we should take a few days to think about these bigger issues, leave any comments on the make/core post that you'd like, then we can discuss it during the chat.

#40 @markhowellsmead
4 years ago

The arguments and security concerns are all very valid and certainly need to be considered as part of this onward development. Opening up oEmbed to include third-party WordPress sites is more of a risk than, say, embedding Flickr images or YouTube videos, as one can never tell what a random website author will do with his or her site.

My argument against using iFrames, whilst still valid, is perhaps less important than avoiding the possible security issues which have been raised here. An iframe is used by Twitter and probably by other services too, so it's not a completely unusable or awkward solution.

Allowing a third-party content provider to allow or disallow embeds of their content is a valid and correct solution to the concerns raised by those who fear too much traffic, or by those who are concerned about issues like AdWords. I would recommend that the whitelisting issue is covered by requiring the third-party provider to manually allow content to be embedded. In much the same way that, when a new site is set up, the option to allow search engine indexing is prominently visible.

As to what the endpoint delivers to embed requests, I would suggest that the logic of what is usually provided via an RSS feed be considered: that by default, an oEmbed request delivers (for example) the post/page title, excerpt, date and link. One can hook the RSS feed to also include the post thumbnail (e.g. http://permanenttourist.ch/feed) and this could work in the same way.

This solution dovetails with the mockups posted by @melchoyce and would closely match the oEmbeds currently coming from Twitter.

#41 @dshanske
4 years ago

As the one who suggested the link preview alternative, I have to point out that if you are engaging in the level of work to sanitize input from WordPress sites because of trust issues, then you are already doing the parsing work.

oEmbed requires that any site support it support another URL (the oEmbed endpoint) to provide information that is otherwise available in the page itself.

Twitter, which someone used as an example, supports oembed, but note that for their own implementation...Twitter Cards, they use a variant of OpenGraph.

OpenGraph is also Facebook, and G+ use...although it isn't their only source. You can add a filter/hook to process the retrieved data from the URL in other ways(microdata, microformats, what have you) as a plugin. Microformats, for example, are widely, if inconsistenty used in WordPress themes(hentry anyone?).

You can add the same caching you have for oembed so it isn't pulling the URL every time.

You could probably make a case for Link Preview functionality replacing oembed entirely, but that is a bit radical an idea I think at this point.

#42 @webdevmattcrom
4 years ago

Absolutely awesome idea. As many others have said, I'd say it has to be predicated on a couple things:

1) No iFrames. Because @Ipstenu is right. Embedding that way runs the risk of embedding stuff you don't want, like Ads or other things.
2) Needs to be generated from WP-API. Yes, FB and others use meta tags, and any WP Admin who's paying attention uses a theme or plugin to manage that for them. But that's not handled natively in Core, so this feature needs to be fully functional just on Core code, which the WP-API would allow for.
3) Totally agree that they need to be easily CSS-able for theme compatibility.

If all those things are handled well, this could really help "Democratize Publishing" much further. Of course there's the risk that it goes the way of the 90's animated Gif and get easily abused, but that shouldn't prevent a good idea from seeing the light of day IMHO.

#43 @ramiy
4 years ago

It should be called a "Link Preview" feature, not "oEmbed" extension or any other embed related names.

Because oEmbed needs to be supported by the other site with an endpoint URL, and this feature needs only the URL.

#44 @scottwyden
4 years ago

I think this is a really neat idea. What if the linked content is only the featured image and the manually set excerpt? And if no excerpt it set then the linked content either automatically makes a short excerpt from the first 2 sentences or can be denied by the site owner/author.

#45 @melchoyce
4 years ago

  • Summary changed from oEmbed WordPress Posts in WordPress Posts to Embed WordPress Posts in WordPress Posts

#46 @melchoyce
4 years ago

Updated the ticket title to separate out the intent from the specific implementation.

#47 follow-ups: @LChief
4 years ago

@melchoyce could you please send the HTML and the css files of the test-2 mockup to my way? (daniel.v8[ @ ]windowslive.com)
We will see if I could crank up a plugin with iframe.

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

#48 in reply to: ↑ 47 ; follow-up: @swissspidy
4 years ago

Replying to LChief:

@melchoyce could you please send the HTML and the css files of the test-2 mockup to my way? (daniel.v8[ @ ]windowslive.com)
We will see if I could crank up a plugin with iframe.

Note that this feature is already being developed as a plugin. We have a working iframe version right now. You can read all about it here: https://make.wordpress.org/core/2015/07/17/oembed-feature-plugin/
You're more than welcome to jump in and work on open issues.

#49 in reply to: ↑ 48 @LChief
4 years ago

Replying to swissspidy:

Replying to LChief:

@melchoyce could you please send the HTML and the css files of the test-2 mockup to my way? (daniel.v8[ @ ]windowslive.com)
We will see if I could crank up a plugin with iframe.

Note that this feature is already being developed as a plugin. We have a working iframe version right now. You can read all about it here: https://make.wordpress.org/core/2015/07/17/oembed-feature-plugin/
You're more than welcome to jump in and work on open issues.

Thank you for your response! :D
It's great to hear!
I am actually coding something at the moment, which would allow to embed posts (with iframe) using only PHP and would not involve the WP REST API. I will share my code with you guys when it's ready (tomorrow I guess). Where can I find this template?
https://core.trac.wordpress.org/attachment/ticket/32522/embed-test-2.jpg

#50 @pento
4 years ago

We haven't implemented that template, we've gone with embed-test-1-noquote.jpg.

You can find the HTML and CSS here.

#51 in reply to: ↑ 47 @netweb
4 years ago

@LChief Come and join us in our WordPress Slack chat room, #feature-oembed the following instructions will get you up, running, and chatting in no time at all :)

https://chat.wordpress.org

p.s Maybe adding that to the make/core P2 would help others as they discover the project and may not yet have Slack :)

#52 @wonderboymusic
4 years ago

#32955 was marked as a duplicate.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


4 years ago

#54 @swissspidy
4 years ago

  • Focuses administration removed
  • Keywords has-patch dev-feedback needs-testing added
  • Milestone changed from Awaiting Review to 4.4

@swissspidy
4 years ago

First patch for merging the oEmbed API plugin

@pento
4 years ago

#55 @pento
4 years ago

In 32522.2.diff:

  • In get_post_embed_html(): inline the wp-oembed.min.js as part of the grunt build process.
  • In wp_old_slug_redirect(): add a case for is_embed(). As /embed/ is now a query var, it isn't handled as an endpoint.

There are currently a bunch of errors when running the full test suite that don't show up when running phpunit --group oembed, I haven't dug into them very far. :-)

@jeremyfelt
4 years ago

#56 @jeremyfelt
4 years ago

In 32522.3.diff:

  • Add embed to the list of reserved subdirectory names in multisite.
  • The smallest ever spacing alignment in class-wp-editor.php. :)

@pento
4 years ago

#57 @pento
4 years ago

In 32522.4.diff:

  • Fix some of the failing tests
  • Change is_admin_bar_showing() to always return false for is_embed(). We never want to show the admin bar in the embed iframe, even accidentally, it could be used for clickjacking.

#58 @wonderboymusic
4 years ago

In 34850:

oEmbed: add embed to $subdirectory_reserved_names.

Props jeremyfelt.
See #32522.

#59 @wonderboymusic
4 years ago

In 34851:

Embeds: move some functions from media.php to a new file, embed-functions.php, via svn cp

See #32522.

#60 @wonderboymusic
4 years ago

In 34853:

Multisite: in wpmu_validate_blog_signup(), pass embed to the array passed to subdirectory_reserved_names.

See #32522.

This ticket was mentioned in Slack in #core by pento. View the logs.


4 years ago

#62 @pento
4 years ago

As of [34857], all unit tests pass with 32522.5.diff.

#63 @pento
4 years ago

A couple of notes:

  • I'm not wild about how we're loading the JS via the TinyMCE plugin. @azaozz can check it out when he has time (he's currently AFK for a few days).
  • How much space does minifying the CSS and JS in embed-template.php save us?

I don't think either of these are blockers for commit. We're in a good place. Pending any more feedback from committers who feel like taking a look, we're ready for commit.

#64 @pento
4 years ago

  • Keywords commit added; dev-feedback needs-testing removed
  • Owner set to pento
  • Status changed from new to assigned

#65 @helen
4 years ago

  • The CSS/JS does seem like it would benefit from being minified, but data on that would be good to have.
  • Should the CSS/JS be hooked into oembed_head and embedded on-page that way or is that being *too* flexible?
  • I did a plugins repo search for function is_embed( as due diligence and fortunately did not turn up anything. I did not search for any other functions, as nothing else jumped out at me.
  • Should we have any tests to ensure that passed parameters are sanitized/validated appropriately? maxwidth is one that I too-frequently see left wide open in oEmbed providers.

@pento
4 years ago

#66 @pento
4 years ago

Thanks for the review, @helen!

In 32522.6.diff:

  • wp-oembed.js now passes our jshint rules.
  • Move the JS out of embed-template.php, into wp-oembed-embed.js, fix the jshint errors, and tweak it for optimal minifying. The resulting minifying reduces it from 4709 bytes to 2400 bytes.
  • Moved the CSS out of embed-template.php, into wp-oembed-embed.css`. Because we're including it inline, it has to have both the original and a handful of RTL rules in the same file. The resulting minifying reduces it from 8491 bytes to 7085 bytes.
  • Move both the CSS and JS inclusion to functions that are hooked into oembed_head.

There are a couple of maxwidth tests: test_get_oembed_response_data_maxwidth_too_high and test_get_oembed_response_data_maxwidth_too_low. Was there other tests that you had in mind?

@pento
4 years ago

#67 @pento
4 years ago

32522.7.diff adds the test test_get_oembed_response_data_maxwidth_invalid, for making sure invalid maxwidth parameters are being sanitised.

#68 @pento
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 34903:

Embeds: Add oEmbed provider support.

For the past 6 years, WordPress has operated as an oEmbed consumer, allowing users to easily embed content from other sites. By adding oEmbed provider support, this allows any oEmbed consumer to embed posts from WordPress sites.

In addition to creating an oEmbed provider, WordPress' oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules), and provides a preview from within the post editor.

For security, embeds appear within a sandboxed iframe - the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.

Props swissspidy, pento, melchoyce, netweb, pfefferle, johnbillion, extendwings, davidbinda, danielbachhuber, SergeyBiryukov, afercia

Fixes #32522.

#69 @pento
4 years ago

In 34905:

Tests: Exclude the oembed/headers.php test file, which was marked as PHP >= 5.3.0 in [34904].

See #32522.

#70 @pento
4 years ago

In 34906:

Build: Fix a filename typo in [34903].

Props peterwilsoncc.

See #32522.

#71 @johnbillion
4 years ago

In 34907:

Update the explanatory text which accompanies the list of whitelisted oEmbed providers, following the change to the default value of the discover argument in WP_oEmbed::get_provider().

See #32522

#72 @ocean90
4 years ago

In 34908:

Embeds: Autoprefixer for [34903].

See #32522.

#73 @DrewAPicture
4 years ago

In 34966:

Embeds: If we're adding a boatload of new items to default-filters.php, might as well make them readable.

See #32522.

#74 @DrewAPicture
4 years ago

In 34972:

Embeds: Combine the oembed_minwidth and oembed_maxwidth filters into one, similar to how the existing oembed_defaults works for width and height.

See #32522. See #34227.

#75 @DrewAPicture
4 years ago

In 34974:

Embeds: Rename the $return parameter in wp_filter_oembed_result() to $result to provide better context on what is being filtered.

See #32522.

#76 @johnbillion
4 years ago

In 35084:

Correct the @since doc for WP_Query::is_embed().

See #32522

#77 @johnbillion
4 years ago

In 35085:

Add missing @since docs for the filters in wp-includes/embed-template.php

See #32522, #32246

#78 @johnbillion
4 years ago

In 35086:

Correct two escaping functions used in wp-includes/embed-template.php.

See #32522

#79 @johnbillion
4 years ago

In 35087:

Remove an unnecessary function_exists() call which was included in the oEmbed feature plugin for compatibility with WordPress < 4.3.

See #32522

#80 @johnbillion
4 years ago

In 35089:

Remove another unnecessary function_exists() call.

See [35087]
See #32522

#81 @johnbillion
4 years ago

In 35257:

Add is_embed() to WP_UnitTestCase::assertQueryTrue() and update the relevant embed tests.

See #32522

#82 @pento
4 years ago

In 35429:

Embeds: Tweak the "embed not found" message, based on the Twenty Sixteen 404 template.

See #32522.

#83 @pento
4 years ago

In 35430:

Embeds: Tweak a string added in [35429], and add a translator comment.

See #32522.

Note: See TracTickets for help on using tickets.