And a wget from the server, if it helps?
Strange, no?
That the wget takes you to the consent page, but the onebox’ing doesn’t?
EDIT/UPDATE:
I’m not a python developer, but does this help?
I noticed that the ‘embed’ URLs for YouTube videos don’t (currently!) redirect to the consent page. I’ve created a couple of PRs so that we’ll attempt to fetch embed URLs and parse the JSON contained within the response body.
It’s not the most elegant solution, but it might be a reasonable way forward for now.
That’s great news, appreciate you taking the time to look in to this for us all
A possible fix for this has been merged in. Can those affected please update if possible, and let us know if the problem with Oneboxing videos has been resolved?
This is 100% a YouTube issue, not a Discourse issue.
@techAPJ went over and above to solve a similar issue with Instagram oneboxes last year, again when it was an Instagram issue and not a Discourse issue.
@jamie.wilson and anyone else who worked on this YouTube issue over the last week or so, I can’t thank you enough.
The level of support you all provide when it’s not even your problem is simply second to none.
I thank you all for your time and dedication
I can update our Discourse tomorrow morning. Will report back.
It’s looking good on my staging server - I’ll upgrade the production site this morning and will update my report.
Edit: our YouTube embeds are working properly again Thanks for your help @jamie.wilson!
Also confirmed!
I can even click “Rebuild HTML” on previously failed ones and the video appears in under a second
Great job @jamie.wilson - Thank you
Have you tried embedding via the youtube-nocookie.com domain?
Embed videos and playlists - YouTube Help → “Turn on privacy enhanced mode”
Can also confirm this works, server is in Germany. Thanks a lot!
Any chance this could be merged into the stable branch as well to be included in its next release?
When a stable release is cut (next one happens next month) all commits will be included!
Sorry, perhaps I’m not using the right terms here. I didn’t mean version 2.7, but what is likely to become 2.6.5.
Our policy is to only backport critical security fixes to old stable releases, so I’m afraid you will have to move to our standard release channel or wait for next stable.
Unless @jamie.wilson says it’s a clean backport, but at this point in the release cycle it may be too risky.
Fair enough — that’s a reasonable policy and I respect that.
Just though asking anyway as this is a quite annoying thing to live with for some weeks for those who opted for this channel for the stability.
That’s the thing right? The stable
channel is not our default release channel, and not what we ship to our many paying customers for a reason.
Because while it provides a “stable” source code for the product, the internet it interacts with is much more dynamic, and we go for great lengths to quickly adapt Discourse to the changing environment in the internet, be it changing behaviors on the browsers who are updated every other week, in the thousands of sites we onebox, etc.
It’s stable, but it’s actually less well tested, because many fewer people use it. If this issue had come up 10 months before the next stable release, it likely wouldn’t be back ported. In the English sense of the word stable you’re better off with tests passed.
I run Ubuntu only in long term release versions. I don’t recommend stable (or even beta) with discourse.
This topic was automatically closed after 16 hours. New replies are no longer allowed.