Ivan Paramonau

It’s the standard oEmbed cache behaviour in WordPress implementation. To clean up oEmbed caches, delete _oembed_* keys from wp_postmeta database table.

Hi Svetoslav, what would the use case for it be?

I think such logic goes against the expected behaviour of the shortcodes in WP. Besides, our short URLs now go with the paid plan and we can’t do it for everyone.

Hi Anna,

It is unlikely that Iframely will be able to detect such embed codes any time soon. I went through descriptions and couldn’t even find embed codes to manually copy-paste.

I trust the issue is better addressed on the EDD plugin side, just by asking them to implement the required shortcode.

Ivan.

So I discovered this page that seems to have the issue:
https://www.pmscope.com/marceltj/

The embed code on the page is this:

<div style="max-width: 1566px;">
<div style="left: 0px; width: 100%; height: 0px; position: relative; padding-bottom: 66.4112%;">
<iframe src="//iframe.ly/lTdAPA?summary=true" style="border: none" allowfullscreen="true" webkitallowfullscreen="true" mozallowfullscreen="true" style="top: 0px; left: 0px; width: 100%; height: 100%; position: absolute;"></iframe>
</div></div>

So something added style="border: none" to an iFrame that made our iFrame style be ignored. So the iFrame goes with default browser sizing and that is what ruins it for you.

You need to find what adds “border:none” and disable it to fix our embeds.

This padding is calculated dynamically based on aspect-ratio of the embed content. And it is required to make it responsive. The internal content should be filling the space.

Can you give an example of URL that doesn’t?

I guess there was a caching issue, either in your WP or in our API. Your links now return proper code. Please, try again (in a new post, as WP caches embeds for a day and won’t call API for same URLs in the same post again until tomorrow).

Will need to take a closer look when I get back to my desktop a little later.

Yes, that’s the previews of native FB. WordPress adds them via JavaScript, and FB doesn’t like multiple embeds on the same page, so second and further down wouldn’t show in your editor. They should, however, appear when you publish a post.

If it still persists, let me know the URL to take a look at.

Sorry for delay. WP stopped sending us notifications :\

Indeed, we pushed an API update on Thursday. It added Tumblr embeds and new UI for cards, among others.

For Facebook, the default settings for our open API (what you appear to be using) were changed so that we started wrapping their JS embeds into our code. That probably what broke it for you.

We need to be wrapping FB by default for everyone since it otherwise has problems with multiple embeds on the same page. Plus, we will soon release a FB hack that will make their embeds responsive.

Since aligning embes to center is a common requirement, we’ll try to do it for everyone next week.

In the meantime, to have a quick fix for FB, just get your API key at https://iframely.com, change your API settings to always return native embeds and put this API key in WP options. This should reverse the API to where it was.

Anything else except FB?

We’ve pushed updated design for the cards yesterday. I trust this issue should now be resolved. Let us know if it’s still not OK for you.

Appreciate the compliment, but we are not magicians.

Until Apple has some way to grab galleries’ data via URL, we can’t do much. And they don’t publish anything yet. Let’s see how fast they figure privacy issues etc and make galleries embeddable or at least accessible.

Sorry.

Sorry for delay with response. For some reason WP didn’t send a notification :\

There is no way at the moment to customize cards via CSS. However, we are aware of the problem with small sizes and it is exactly what we are working on right now – to address it in the cards on our side. The sidebar use case was indeed not well covered by us.

Iframely doesn’t detect embed codes in your posts. We work the same way any other WordPress embeds do – we process canonical URLs and try to find embed codes ourselves.

However, as mentioned above – we don’t handle One Drive presentations yet. We do handle images though.

But yours seems to be Share Point site, not One Drive.

You may try to upload your presentation to Google Drive or SlideShare, if it’s public anyway. SlideShare will be supported for sure. Google Drive – depending on your privacy settings.

Hi,

Iframely isn’t working indeed. The embeds for your URLs were prepared by default WP parsers and cached for a day.

To fix it, take a look at suggested steps in the discussion here: https://www.ads-software.com/support/topic/slideshare-embed-is-not-responsive?replies=6

Also, we submitted an enhancement request for WP team to address this problem.
https://core.trac.www.ads-software.com/ticket/30720

Thanks. And yes, I can see how caching may be an issue when you first install/configure the plugin. Once you get rolling, it should be quite smooth.

For the fix, we’ll wait until WP devs introduce “reload” button for their native inline previews. There reason we are reluctant to mess up with the core is that will cause headaches in maintenance and WP updates. For the users that is ??