Embeds not working

Hi James,

The Comodo site is a client’s site and I haven’t got permission to go live with it. It’s hosted on the same server but with a different cPanel account and its own IP address.

Here is a link to my father’s site which is not running HTTPS. That link is to a dummy page I just created for testing.

It should be noted that WordPress wouldn’t let me run the Update Network for my multisite install (on which shanegowland.com, gowland.me and a few others are running) without first disabling SSL – so I don’t know if it should be entirely discounted as related to the underlying cause.

It seems the CloudFlare plugin causes a bit of issues

I just tried disabling that plugin and putting CloudFlare into “Development Mode” (which essentially turns it off) for all my sites. No dice, even when trying new uncached links. But thanks for the suggestion.

Hey, this is something!

The Broken Link Checker plugin is now reporting every single link between my websites as broken with an “unknown error.” Screenshot.

I also just fixed an issue with an older plugin (AP Extended Mime Types) that started throwing errors because it was using ‘plugins_url’ instead of ‘plugin_dir_path.’ In other words, it was trying to read a file over HTTP instead of read it from disk – the former for some reason no longer working.

Possibly connected?

To me, this sounds like a PHP/Apache issue; not a WordPress issue. I have no idea where to start to troubleshoot it. Will pop my host an email to see if they have any insights and shall update accordingly.

The issue with the site that isn’t public is just that. If the site can’t be reached, then the embeddable data can’t be collected.

For the issue where you can’t update anything without disabling SSL, make sure your server is running the latest version of openssl, 1.0.2e. In fact, that might fix this whole thing.

The issue with the site that isn’t public is just that. If the site can’t be reached, then the embeddable data can’t be collected.

I temporarily removed the restriction when testing.

For the issue where you can’t update anything without disabling SSL, make sure your server is running the latest version of openssl, 1.0.2e. In fact, that might fix this whole thing.

I’ll look into upgrading OpenSSL and report back.

Thanks for your continued help.

You’re welcome! I’m hoping that’s all it is. ??

Fixed!

Turns out there were two issues.
1: The most recent Apache update shipped by WHM/cPanel was causing issues. Had the host revert it and all the issues surrounding HTTP access went away.

2: The CloudFlare plugin. Disabling it after the Apache reversion made the oEmbeds start working. Huzzah!

Thank you to everyone who chimed in with their advice.

Awesome, thanks for letting us know!

Suggestion to try with the CloudFlare plugin: Disable the “Protocol rewriting” option.

It appears that this option causes CloudFlare to rewrite all URLs in the page content to remove the http: or https: bits from the link. The problem is that this is not really valid behavior for the link tags in the head of the document. These link tags define the oEmbed endpoint for WordPress to look at, and I think that without a valid protocol being specified, the WordPress functions won’t be able to make the oEmbed request.

CloudFlare should change their rewrite system to actually convert to http: or https: as appropriate instead of simply rewriting everything to a protocol-less URL.