Reviewed & tested by the community
Project:
Media: Vimeo
Version:
7.x-2.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Nov 2015 at 14:07 UTC
Updated:
3 Jul 2024 at 13:37 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
sdstyles commentedI propose to display a default thumbnail in case video thumbnail can't be obtained. Because Media Vimeo has Media as dependency I reused image file-unknown.png as default thumbnail, see below patch.
Comment #3
vistree commentedHi, I tested your patch - only thing I needed to change was the URL of the default image.
As media provides default icons - I used /images/icons/default/file-unknown.png (instead of /images/file-unknown.png ).
Works really well!!! Can this be commited?
Comment #4
vistree commentedComment #5
loze commentedI know this is an old thread, but I couldn't find this answer anywhere
apparently, if you are using domain-level privacy, you can get the thumbnail using oembed by passing a referrer header in drupal_http_request()
$response = drupal_http_request($oembed_url, ['headers' => ['Referer' => 'https://a-whitelisted-domain' ]]);
Comment #6
tomdearden commentedI'm seeing problems with one of my clients using this, too - in my case it's down to the Vimeo settings being set not only to use domain privacy but also to use a password.
As I understand it, this is something that can't be got over by use of headers etc. - the behaviour as intended by Vimeo is that it's only possible to access the video content (including, I guess, thumbnails) *after* the user has actively provided a password within Vimeo's embedded player. There's some relevant discussion here:
https://stackoverflow.com/questions/32317013/how-to-embed-a-password-pro...
What I do see in both the case where the referrer isn't provided, and that where it is but there is a password required, is that the domain_status_code property of the returned JSON-encoded object is set to 403 (vs. 200 in the case where all is well and a thumbnail_url is part of the response). So maybe it makes sense to use a backup, default thumbnail URL that can reflect the nature of the required fallback e.g. a key for 403/'access denied' and perhaps something else in other cases? I'll try to provide a patch to explain better what I mean if I get a moment.
Comment #7
gooddesignusa commentedThanks for the patch!
Currently running in to an issue with private videos.
After googling around I found this issue: https://www.drupal.org/project/video_embed_field/issues/2862500#comment-...
I added the referer header to the drupal_http_request to help get domain level privacy videos working.
Instead of making a new issue, I figured it made sense to add it to this patch.
Comment #8
tomdearden commented#7 is pretty much identical to a patch covering both these issues that I've been running here for a couple of days with success - so I'd be happy to say it's working for me - I don't know what the etiquette around two issue resolutions in one patch should be, though?
Comment #9
bisonbleu commentedRan into this. Patch in #7 fixed it for me. Thanks
Comment #10
mef613 commentedJust ran into this too for a video, despite the fact that it wasn't private - not sure why the URL thumbnail retrieval was failing, but it was preventing my entire media browser from loading. #7 worked to fix it - worth committing to a new dev release?
Comment #11
larynComment #12
oldspot commentedI can confirm that we had the same issue with thumbnail url not being present for private videos in the request which meant it would throw a 500 error when loading the media browser and file edit page.
The patch works great.
According to the project page though this module is looking for maintainers which is why i guess this patch has not been committed in the last 4 years since it was implemented.