LYTE: change in YouTube API caching behavior

As mentioned earlier here, Google checks YouTube API usage and can cancel a project/ API key if there are no API requests for 90 days. Based on the fact that earlier post received more hits the last week and people asking on the WordPress support forum, I went back to the drawing board code editor and added logic for LYTE’s cached YouTube API responses to expire after 2 months, causing somewhat regular requests to YouTube which should keep Google happier with the API usage.
Obviously if you have page caching (which you should) this can have an impact as well, as a cached page will not result in LYTE “seeing” the request, so the cached YouTube data would not get refreshed even if older then 2 months. Then again having such aggressive page caching would likely cause other issues (nonces in forms becoming invalid and such), so I *think* the one month margin (results cached for 2 months whereas Google wants activity in 90 days) should suffice.
For those who don’t like the cache to expiry of if you want more or less then 2 months; I added  2 filters allowing you to tweak with a bit of code. Returning false to lyte_ytapi_check_cache will make LYTE function as before (no cache expiry) and the cache expiry threshold can be changed using the lyte_ytapi_cache_gracetime filter.
And like blogposts concerning LYTE, here’s a video to show it action: Yves Tumor with “Gospel for a New Century”. Weird stuff I admit (you have been warned), but good weird really …

Yves Tumor - Gospel For A New Century (Official Video)

LYTE YouTube API use warning mail

WP YouTube Lyte users might have received the following mail from Google/ YouTube:

This is to inform you that we noticed your project(s) has not accessed or used the YouTube Data API Service in the past 60 days.
Please note, if your project(s) remains inactive for another 30 days from the date of this email (November 9, 2018), we will disable your project’s access to, or use of, the YouTube API Data Service. As per Section III(D)(4) of the YouTube API Services Developer Policies (link), YouTube has the right to disable your access to, and use of, the YouTube Data API Service if your project has been inactive for 90 consecutive days.

The reason for this is that LYTE caches the responses from YouTube to ensure optimal performance. You can check your API usage at  https://console.developers.google.com/apis/dashboard. In my case it actually was not inactive although not very active either;

To make sure my API access would not get disabled I ticked the “Empty WP YouTube Lyte’s cache” checkbox in LYTE’s settings, saved changes to force LYTE to re-request the data from the YT API when pages/ posts with LYTE’s being requested again. The result:

I do have a non-neglectable number of videos on this little blog already, but here’s one more for a rainy Saturday-afternoon;

Damien Jurado - Allocate (Live and acoustic on 2 Meter Sessions)

 

WP YouTube Lyte 1.6.0: the one with the other API

I just released WP YouTube Lyte 1.6, featuring the following changes:

Proof the new player UI looks great;

Grizzly Bear - gun-shy [Official Music Video]

If you’re struggling to get a Google API key; there’s extensive information in the FAQ on the why, what & how. WP YouTube Lyte will automatically fall back to the old anonymous API v2 if you don’t provide a key. As API v2 will continue to work for a couple of more weeks, all will be fine. I am, in the mean time, working on a separate plugin that will automatically provide an API key for WP YouTube Lyte to use (and which in the future might offer other extra’s). You can contact me if you would be interested in test-driving that service-plugin.

WP YouTube Lyte and YouTube API v2 end of life

The YouTube API v2 is now officially to be shut down soon after April 20th. That’s bad news for WP YouTube Lyte, which uses this version of the API to perform unauthenticated read-only requests to fetch a.o. video title and thumbnail information (example here). The v3 API is supposed to simpler yet more powerful and migrating should not be a big problem, except for that little detail that v3 doesn’t allow unauthenticated requests at all. So I’ll need to add authentication (via an API key) to the mix, leaving me with the dilemma of having to choose between these approaches, none of which I really like:

  1. Tell WP YouTube Lyte users to get their own API key and have them enter it in the plugin’s settings-page. Risk: upsetting users who all of a sudden have to get an API key (“huh, what key?”)
  2. Get an API key myself and hardcode that in WP YouTube Lyte. Risk: abuse of that key (and neither a server key nor a browser key is applicable really), reaching limits, being denied access.
  3. Create and operate a proxy application that sits between the v3 API and each and every WP YouTube Lyte instance, taking care of authentication with an API key. Risk: having to write & install that proxy application, making sure it is available 24/7 (it’s a single point of failure) + obviously the same abuse-risk as in (2).

No, I’m definitively not happy … 🙁