Provide an extensible mechanism for thumbnail configuration and customization

Ready to QA

Added a related issue. This one is really tricky.

I really feel that making blocking web requests on the server side in the formatter isn't the direction that should be taken, as it opens up the potential for denial of service security concerns.

Ideally this information would be captured when the oembed resource is created and then able to be referenced from the formatter. Obviously that's a much wider scope issue, but it's the only safe way I can see to accomplish this.

Thoughts?

I'd be happy to discuss this further. I have some ideas, but am sadly short on time due to #dayjob.

If you're on slack, feel free to hop into #oembed-lazyload and we can chat :-). I'm drafting up a quick and dirty of what I feel might be the most holistic approach to making thumbnails the most useful to the most users, hopefully finishing up within the next 12 mins or so.

I've pushed out a branch called flexible-metadata-alter-architecture that scaffolds in some API additions such that...

1. Users may opt into customizing oEmbed metadata altering (it won't be activated by default)
2. If enabled, all ProviderEnhancer plugin types will get a chance to customize metadata through a new method: public function alterOembedMetadata(array &$data, $url)
   For example, the YouTube provider enhancer can download thumbnails of various resolutions based on what's available on the remote end
3. Speaking of YouTube...the stock enhancer now ships with a setting that allows end-users to opt into downloading the "highest resolution thumbnail available"

Work yet to be done:

1. Continue adding test coverage -- there are now significant gaps.
2. Figure out how to plumb this into the front-end while retaining API backwards-compatibility

I've just pushed a minimal viable product for the front-end bits. It's still not 100% useful, as the front-end still coerces everything to use a 16:9 aspect ratio.

Additional formatter settings are still required to make this a 100% turn-key solution. Luckily though, I think we can do all of this while still retaining backwards compatibility. It looks like we'll need a conditional container sizing mechanism that lets users choose between rendering things with...

• An aspect ratio (has to be the default option, for b/c purposes
• A maximum width / height (the options are already in the formatter settings, but are presently ignored!)

I'll take a peek at how the off-the-shelf oembed formatter does the CSS bits for the max width/height rendering strategy, but as the branch now stands, an end-to-end test should be possible after sprinkling some custom CSS on things.

I'm satisfied with the functional pieces and test coverage here. The only remaining task is an upgrade path + upgrade path testing.

Retargeting to 2.1.x.

Committed and pushed to 2.1.x! Thanks for everything, Eduardo.

I'll be cutting a 2.1.0 feature release in the near future. Take care.

Automatically closed - issue fixed for 2 weeks with no activity.