When I upload a private Vimeo video through media interface, I get notice Undefined $data['thumbnail_url'], the problem is that Vimeo doesn't return 'thumbnail_url' for private videos.

Comments

sdstyles created an issue. See original summary.

sdstyles’s picture

Status: Active » Needs review
StatusFileSize
new832 bytes

I 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.

vistree’s picture

Hi, 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?

vistree’s picture

StatusFileSize
new846 bytes
loze’s picture

I 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' ]]);

tomdearden’s picture

I'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.

gooddesignusa’s picture

StatusFileSize
new1.36 KB

Thanks 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-...

NOTE: In the case of a video with domain-level privacy, the oEmbed request returns a simplified response containing the embed code only and no private metadata. To get the complete response, send the Referer header along with the request, and set its value to the video's whitelisted domain.

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.

tomdearden’s picture

#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?

bisonbleu’s picture

Ran into this. Patch in #7 fixed it for me. Thanks

mef613’s picture

Just 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?

laryn’s picture

Status: Needs review » Reviewed & tested by the community
oldspot’s picture

I 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.