Onebox for WordPress 4.4 sites

Onebox used to work great for my site, but last week (I’m pretty sure after I upgraded to 4.4) it stopped working so nicely:

The Iframely previews look ok except for the oEmbed HTML — it looks weird.

This seems relevant: New Embeds Feature in WordPress 4.4 – Make WordPress Core

I guess there’s a plugin to disable the new embed functionality, but I doubt many people are going to think of doing (or want to do) that.

2 Likes

Sure, we should support both earlier WordPress and WordPress 4.4 here @techapj can you add to your list?

3 Likes

The above WordPress onebox looks good on try:

It’s broken here on meta because http://sixprizes.com (WordPress blog) does not have SSL enabled, hence causing this error:

Mixed Content: The page at 'https://meta.discourse.org/t/onebox-broken-for-wordpress-4-4-sites/36765/2' was loaded over HTTPS, but requested an insecure resource 'http://sixprizes.com/2015/12/15/silver-surfer-back-to-back-runner-up-reports-a-fiery-standout-and-some-potential-plays/embed/'. This request has been blocked; the content must be served over HTTPS.

@AdamCapriola If your Discourse instance has SSL enabled than the accompanying WordPress blog should also have SSL enabled for embeds to work properly.

2 Likes

Oh, huh. Maybe they are working. The only other link I’d showed up like this and I assumed something was broken:

I guess the height is just off (the title and except aren’t shown — featured image is too big). Is that a WordPress issue?

Also http://blog.discourse.org is latest WordPress so we can test with that too.

We’re supposed to onebox URLs in the form

http://blog.discourse.org/2015/12/discourse-selected-for-mozilla-open-source-support-program/

Where it is
http://example.com/yyyy/mm/slug/

Because we assume they are WordPress…

Why isn’t that happening, @techapj?

1 Like

Currently we were only oneboxing WordPress links with ../yyyy/mm/dd/.. permalinks, just added support for ../yyyy/mm/.. permalinks too:


Posts from http://blog.discourse.org are still not getting oneboxed because we are not providing oEmbed endpoint, will modify our WordPress theme to include oEmbed endpoint for posts.

2 Likes

Seems like it… Here is the WP iframe source: http://sixprizes.com/2015/12/10/build-a-bat-crafting-crobat-for-competitive-play-meta-updates-and-rogue-highlights/embed/

Notice that there is no max-width CSS property on image, and the iframe height is fixed height="338".

Hmm. Yeah idk why the height is wrong. The image size is actually ok. When I try to embed the post in WordPress it looks fine.

Either way, the blockquoted link above the embed should be hidden, right?

blockquote.wp-embedded-content {
    display: none;
}

Height appears to be 338 for anything (notice the whitespace below this embed):

It resizes inside of WordPress posts though (visit that link and watch the page load). So maybe there’s something going on in Discourse preventing it from resizing correctly?

We absolutely do not want embedded variable height content as it destroys our infinite scrolling – ask @techapj about Twitter embeds for this reason. If it is variable height, it cannot be allowed.

2 Likes

Got it. So I guess for consistency we want to enforce WordPress links as they behaved previously then? (OpenGraph instead of oEmbed)

Is that possible or is this in the hands of the WP install?

It needs to behave like Twitter where we grab the content and render it. We cannot have alien Iframes of varying height ruining all scrolling.

1 Like

Okay, I just fixed this issue via

https://github.com/discourse/onebox/commit/1b8bef8f96a4353cdfa6bc67da87d6750d5d31bf

Now in case of WordPress embeds onebox will use OpenGraph data instead of oEmbed (so as to avoid weird iframes).


Here’s the above WordPress link with OpenGraph data:

3 Likes