Support Youtube v3 API and playlists

This would be nice indeed.

I guess the list id could be in the atom's data attribute.

Unfortunately as I see we have to act on scald_youtube quite fast, cause the v2 API calls it uses are going to be shut down in a few months.

But v3 requires an API key, so we have to add this text field in there as well, and the user has to create it before the prefill would work.

#4 is the first working version.

For now if the youtube API key is not filled, it will just likely error out, should do more checks there.

Unfortunately it required a lot of changes, but not much we can do about that, the v3 api is totally different.

@jcisio : this might be a blocker for 1.4 ?

Added an additional check, so if the api key is not given then uploading is not possible.

But we can adjust that if needed.

Forgot the condition in the form alter.

Updated the patch.

I have done a comparison between using the v3 api and parsing the video's html page.

api v3:
con:
- we need an api key
- it does not support the video's original width and height, and tags
pro:
- can get the title, image (several resolutions), author, and generally a lot of data using the API.
- can easily decide by return value whether the video exists or not.

video's html
con:
- if the video does not exist, there is no robust way to get informed about that as the page will still get a 200 response, and its not in any meta. And parsing html would be unreliable.
Maybe we could use the fact that then the meta og "title" is empty.
- Cannot get the author's name from the og attributes
pro:
- dont need an api key
- we can get the tags, original video width, height, title, one of the thumbnail images, and some other attributes from the og attributes, but is generally a limited way of gathering data.

Conclusion:
It seems that using the v3 api will be the preferred method, however since it does not provide all data, we will still need to use the other method as well to gather some information from og tags.
We can maybe provide a fallback in case the api key is missing to gather the information only from the og tags on the video's html, but then its not going to be as reliable, and we wont be able to prefill the author.

Currently patch in #9 implements the v3 api version with some extra information from og attributes on the video's html, but it requires the api key.

I've implemented a fallback, since the video's youtube page has to be queried anyways for tags and video width and height, it is something we cannot avoid.
However to prefill the author the api key will need to be supplied, and the api key can be used for future improvements to query more data from the video.

So in this patch if the api key is not filled then it will query only the video page, and not the Api.

Just a little backward compatibility so the author attribute of the info object is still available with the v3 as well.

The commit in #12 had issues with older php versions.

Attached new version.

Is it possible to make things work without updating everything to work with the new v3 API? Obviously this needs to be done all the way to work with YT API v3 but is it still possible to patch what's already there to get the data we were able to get before? We're stuck on Scald 1.2 on our project and will get around to upgrading to 1.3 and eventually (hopefully with this work included!) to 1.4 but wondering if a functional patch is possible?

Its possible, but requires extra work, as this patch will not apply to version 1.2 for sure.

The good news is that upgrading from 1.3 to 1.4 (currently dev) is relatively easy, i have just done it on a project and there was no real problems. There is only one change is that the options['link'] now needs to be urldecoded in custom code, if you have used that option in custom code.

So in order to create a temporary patch for 1.2 this patch has to be rerolled for that version. The good thing is that the youtube provider have not changed a lot, so it wont be very difficult to do.

An other solution would be to separate out the youtube provider to its own project, like it was done with other providers as well before, but then maybe even vimeo and dailymotion should be separated out to their own projects.
But I cant decide in that alone.

Re #17: there is #2025785: Move some providers into contrib, I think there was an agreement, but no action has been taken.

Yes so we have two options:
A) commit this patch
B) remove the video providers into separate contribs.

we have to do A or B before 1.4 as this issue seems to be kind of critical.

@jcisio : so then just to double check, can I go ahead with B)?

Yes, I think B) is better and safer. A few days ago I tested the last version of Scald and had no problem, so we'd better separate providers into contribs (step 1: create contribs, step 2: remove them from Scald) then release 1.4, then review and commit this patch in scald_youtube. Could you take care of a few providers (e.g. scald_youtube and maybe others that you feel comfortable with, can discuss in the other issue)?

Okey, will do.

Committed.

Committed it, because its already on some of our production sites, due the critical aspect of the issue.
And it seems to work for me fine.

But since now this is a separate contrib, we can easily fix if something bad happens for some reason :)

Doesn't pulling this module out of scald core into its own module cause some problems with upgrading since the module won't be there anymore and would then be in a different location from then on? What am I missing?

For users upgrading to the latest dev and soon 1.4 of Scald Core, and where the youtube/vimeo or dailymotion providers were in use before the following steps have to be taken to successfully move the module in the registry:
- Install Registry Rebuild (if not already installed) either as a drush
command or as a php file.
Explanation at https://www.drupal.org/project/registry_rebuild
- Download the youtube/vimeo/dailymotion modules depending on which ones were
used before on the site into the contrib directory.
- Run Registry Rebuild
(Because in this case those modules were already deleted in the latest dev and 1.4 of Scald Core)

For users using old builds of Scald Core and just would like to use the latest version of Scald YouTube:
- Install Registry Rebuild (if not already installed) either as a drush
command or as a php file.
Explanation at https://www.drupal.org/project/registry_rebuild
- Delete the scald_youtube module from the Scald module directory.
- Download scald_youtube module into the contrib directory.
- Run Registry Rebuild

So basically the only thing happens here is that the scald_youtube directory will move outside of Scald's folder. But for that to work you need to run registry rebuild to update the registry.
It works fine after that though.

Of course instructions like this will appear in the 1.4 release notes of Scald Core.

good to know that this would still work if we don't update scald core. not sure we're ready for that on this project quite yet. we've done a bunch of customization to scald (without hacking) but worry that something will break in our implementations and custom code tapping into scald's hooks.

I just have to say this is such great work. Thanks Balint! It worked so smoothly and the API key isn't even required. Just curious then, what does adding the API key to the config settings (admin/structure/scald/video for all who are wondering) do that it doesn't do without that?

Thanks :)

Currently the V3 API key is only used to prefill the author field.
Because the author is not in the og meta attributes of the video's html markup. Of course it could be salvaged from other html, but that would not be reliable.

Later if the task #2491393: Use YouTube V3 API as primary source of information when key is supplied is done, we can use the V3 API key to prefill values even if the video's html page is not accessible due some firewall settings, or other reasons.

And in the future it could be used to query some other data that is not found in the meta attributes of the video's html page.
(Or maybe if the V3 API gets improved and we can query the tags from the API, then we would be able to use the API exclusively when the key is supplied..)