I’m not sure if this happened with the recent update to 6.9 or something else, but YouTube embeds are no longer working for any of my sites. Also, all previous embeds have been turned into plain text on every post.
I’ve tried disabling all plugins and switching to the Twenty Twenty Five theme, no luck.
Disabling Cloudflare also didn’t help. Not sure what the issue is.
I tried to replicate the issue but was unable to reproduce it on a fresh WordPress installation. Could you please create a new website and try again to reproduce the issue? Also, ensure your server configuration matches the recommendations provided in the following link.
I tried to recreate this on my end and couldn’t find any problems. However, I’m also unsure what exactly you did.
I used the YouTube Embed Block on a new page in a fresh WordPress 6.9 installation with TwentyTwentyFive as the theme and no plugins activated, and entered the URL of a public YouTube video there. Immediately after clicking “Embed,” the video was already visible in the editor and online when I saved it.
What did you do differently?
Are the websites affected by this issue hosted on the same server, where security tools may be in use? Or perhaps a CSP header?
Are the websites affected by this issue hosted on the same server, where security tools may be in use? Or perhaps a CSP header?
Both websites are hosted on different servers. Similar stacks but one uses NGINX while the other uses Apache with NGINX as a reverse proxy.
Only one uses a CSP header which was set to allow content from YouTube. It worked before and the policy hasn’t been changed. No CORS, and all other security headers worked with YouTube embeds previously.
No, WordPress itself doesn’t know anything about that. The plugin you mentioned is also six years old. It’s possible that it is no longer compatible with WordPress and the necessary server components. I would recommend not using it.
I decided to go ahead and drop Memcached in place of Redis, was long overdue anyways. The embeds still fail on both servers/sites with the currently maintained plugin/drop-in.
So, it was looking like the X-Content-Type-Options: nosniff header which is implemented on both sites was causing oEmbed to fail and that the object cache was not the real culprit. After disabling the header, I got the videos to embed, but they stopped working again.
Browser console shows that proxied oEmbed requests are failing and returning a 404.
UPDATE: Been pulling my hair out trying to figure out how to fix this since I have nearly a thousand articles written and quite a lot of them now have dysfunctional YouTube embeds.
Steps taken
Disabling all plugins
Switching to default Twenty Twenty Five theme
Disabling DNS (Cloudflare)
Removing security headers
Disabling all caching plugins
Disabling object cache and backend (Memcached/Redis)
I was able to reproduce the issue with my old Memcached drop-in on a test environment but not with Redis, although the issue persists on the production environment with Redis.
For some reason, the embeds were restored for a moment when removing the X-Content-Type header but then they failed again and I haven’t been able to reproduce the results again either. This issue does not occur on the test environment.
The web console/developer tools show that the oEmbed API is failing to retrieve proxied content for the embeds from YouTube and removing proxy from the URL does allow it to show up, but this can’t be implemented sitewide or at the very least, I don’t know how as the proxy seems to be ingrained in WordPress’s core.
Search engines pull up some similar events of this happening with older WordPress versions which were resolved with updates or figuring out where a conflict was, although there’s not much else to go on.
If you want to report this as a bug, a reproducible scenario is required that a developer can use to investigate the issue. This is relatively difficult due to the individual system you seem to have. However, if you are able to reproduce the problem in a completely new WordPress environment, possibly even on a different host without any caching headers, that would be a start.
It would be even easier if the problem could be reproduced in the playground: https://playground.wordpress.net – but my tests there always work without any problems.
By the way, these are the HTTP headers from one of my test systems where it works without any problems. “x-content-type-options” is also included here.
Although not sure it is still relevant or applicable to my setup.
I will try my best to reproduce it, although, as you said, the playground doesn’t let me alter web server/DNS/headers/etc. which could certainly be the reason.
Sorry, you are not allowed to make proxied oEmbed requests.
only appears if the currently logged-in user does not have permission for “edit_posts”. So either your permissions are set incorrectly (in which case you should not be able to edit any posts) or your user’s session is not opened at all when the request is made. The latter can also happen if the wrong protocol (http instead of https) is used or the security token for the request cannot be processed. There may be several reasons, but it definitely has to do with the session.
So, apparently, even on a valid request, that response is sent. The test site has the same output but embed is successful. It’s the admin account and both have full permissions to edit posts. Not sure if there is some other kind of misconfiguration.
The only difference I can see is that the failed request results with a 404. The proxied URL is still processed over https however isn’t covered by the SSL certificate.
The webpage at https://domain.com/wp-json/oembed/1.0/proxy?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DZJ4DLIuxjvw&_locale=user might be temporarily down or it may have moved permanently to a new web address.
The proxied URL is still processed over https however isn’t covered by the SSL certificate.
Why not? That could be precisely why it fails. It may be related to the browser, which does not allow the session for security reasons because it is an unsecure connection.
