Since the recent update in Dato we cannot insert our Youtube videos in the embed format as it transforms the URL instantaneously.
Now it shows the pop-up alert and if we delete the parametres after the “?” it changes the url to a non embed format. However, it still works with the urls we inserted few months ago.
How can we fix it?
Thanks beforehand
Hi @guillem.moreso. We fixed the “?autoplay=1” part of the problem, but we cannot do much regarding DatoCMS changing the URL to the canonical one. This is actually the correct behaviour.
To build your iframe you should use the provider_uid attribute of the video field… something like this:
`<iframe src="//www.youtube.com/embed/#{provider_uid}?rel=0" frameborder="0" allowfullscreen></iframe>
So whats the behaviour of this field supposed to be ? because i get the same problem. I’m pasting in a direct private url for a vimeo video.
Am i right in assuming that this field expects a specific format of url?
If so, then the helper text should explain that, because not being able to type in a url without it throwing that error and taking the cursor away from being able to actually type, looks like a bug.
Hello @emile.swain
Dato doesn’t expect a specific link format to the video, the direct URL should be enough.
The vimeo video has to be “embedable”, perhaps the fact that it is private is not allowing dato to embed the video into an iframe.
Could you try with a different public vimeo video and see if you have the same behaviour?
Thank you
Well its a public distribution vimeo link. in the format https://player.vimeo.com/external/123456.sd.mp4?s=abcdefgh&profile_id=164
Which is want we need to manually embed it in our application.
I get this when trying to access the link:
Perhaps it is not really public?
its not a real link, i made it up. I don’t have a public video i’m willing to share from vimeo on a public forum.
the link is the format for vimeo videos that point directly to the source, i.e. the actual mp4 file. rather than an embededable browser player.
Ohh, my bad, i should’ve noticed that 
In that case, the problem seems to be that Dato only supports the embedded link, or the “undirect” URL to the Vimeo video page.
So either https://vimeo.com/123456789
Or https://player.vimeo.com/video/123456789
Cool i try that. I thought i had the other day, and it still failed.
I think the error toast is a bit aggressive, as it take the cursor away from the input field when your typing. Means its impossoble to type a url. Ideally the component should just flash red, rather than disabling input.
I agree that the toast is a bit aggressive, we’ll see what we can do.
But the point of that video field is that you can paste the plain link to Vimeo, as @m.finamor said before.
What we do is fetching more info from Vimeo/FB/Youtube and expose it via API. For instance you can retrieve all this info from GraphQL on a external video field:
video {
height
provider
providerUid
thumbnailUrl
title
url
width
}
If you have already a URL of what you need and you don’t want our functionality, then maybe it’s better if you save directly your URL.
Hope this makes sense!
Hello @emile.swain
We added a debounce to this fields validation, this way you won’t get kicked out of focus due to a failed validation anymore like before.
Thank you for the feedback!
I use private Vimeo video’s restricted to certain domains, all tough we have a custom domain added to our Datocms dashboard which is whitelisted. The CMS won’t accept our private video.
I tried adding datocms.com as whitelisted domain but it doesn’t solve the problem. Any ideas?
Hello @jef.roosens and welcome to the community!
I’m sorry but we currently don’t support domain-level privacy for Vimeo embeds (the requests are always made using a dynamic IP), you can choose other Vimeo privacy options listed here: Manage your video's privacy settings – Vimeo Help Center
I just stumbled accross the same issue wanting to update old videos and I don’t get why this is supposed to be the correct behavior for youtube videos.
It’s a highly breaking change that looks pointless to me
Hello @jimmy.delas we are using the values that we are getting back from the YouTube API.
Why do you see it as a breaking change? We are surely open to discussions, I just want to better understand your point of view, thank you!
I’m running into the same issue; why not make both YouTube links available w/ and w/o the “embed”? (For reference, I’m adding the “/embed” but gets transformed to the “/watch” url). However I guess I can use the suggested solution to re-build the url using the providerUid but it makes it THAT much complicated when adding videos from multiple sources.
@claudio a bit late here, but have you considered using a plain text field if you don’t need to preserve the embed info?
Or I’m not sure what you are suggesting here
We’re having trouble embedding an unlisted Vimeo URL that we’ve set to be embeddable anywhere
In Dato, we’ve tried pasting its URL in an external video field:
player.vimeo.com/video/783356975?h=3345a83142
But in both cases, the rendered Dato page truncates the URL:
If this relates to the issues/fix above, can you clarify if ‘public’ is currently the only privacy setting in Vimeo that works with the external video field?
(…We’d prefer to keep it unlisted if possible in case there are other recommendations)
Thanks for any info
Hello @kwebbink,
when you add an external video, we pull information from the Oembed providers. For Vimeo we use their own service, for example, for your video:
Now your video seems public to me, so it works as expected, I’m not sure how it behaves when unlisted. If you want you can try yourself and see how it goes. Unfortunately if Vimeo doesn’t return the information that we need, probably it’s better to use a simple text field and do what you need on your end.
Thanks @mat_jack1 – yup/apologies, we ended up setting the original video to ‘public’, so I tried with another unlisted video [which will stay that way] in case it comes up again:
That response includes the same keys/info as for the now-public video:
…But if the External Video field uses the video_id instead of parsing the uri to form a link (not sure?), then it would be missing the necessary suffix that’s only included in the uri – e.g.:
Either way thanks for taking a look!
-Kate