Block editor doesn't preview videos requiring signed URLs

[davidmpurdy]

The block editor needs to use signed URLs when they're enabled in settings. I'll work on a PR for this.

@B-Interactive what would you think about moving the iframe URL without the querystring into a separate function? Then the editor could get it via AJAX without needing to duplicate the logic.

[B-Interactive]

I think that's fine @davidmpurdy, I'll try to get that done today.

If I may check my understanding, you're working towards having an AJAX query fetch the signed URL, so this separate function should provide everything prior to that?

Current returns something like (varying a little depending on the chosen media domain):

https://customer-[someid].cloudflarestream.com/[signedURL]/iframe?poster=https://customer-[someid].cloudflarestream.com/[signedURL]/thumbnails/thumbnail.jpg

Separate function would return something like?

https://customer-[someid].cloudflarestream.com/

So perhaps a media domain specific function?

[B-Interactive]

There's a bit of a complication with this and I'm still nutting out how to simplify. It stems from the difference between the standard domains, and the account specific subdomain:

Standard domain style: https://iframe.cloudflarestream.com/SIGNEDTOKEN?

Account specific sub-domain style: https://customer-0123456789abcdef.cloudflarestream.com/SIGNEDTOKEN/iframe?

The options that I see at the moment are (in order of preference highest to lowest):

1. Provide the full embed code, but place UID in as a placeholder and perform a case sensitive string replacement in JavaScript with the AJAX obtained signed token. The potential advantage here is consolidation of code (avoid separate block vs shortcode handling), and preferences like playback parameters. String replacement would also handle the poster URI. So it'd look something like this:

   <iframe src="https://customer-0123456789abcdef.cloudflarestream.com/UID/iframe?muted=true&#038;loop=true&#038;autoplay=true&#038;poster=https://customer-0123456789abcdef.cloudflarestream.com/UID/thumbnails/thumbnail.jpg" style="border: none; position: absolute; top: 0; height: 100%; width: 100%" allow="accelerometer; gyroscope; autoplay; encrypted-media; picture-in-picture;" allowfullscreen="true" id="stream-player"></iframe>

2. Similar to 1, but only part of the URI, not the full embed code, and no parameters. This requires separate parameter handling for blocks. Something like this:

   https://customer-0123456789abcdef.cloudflarestream.com/UID/iframe?

3. Return only the basic media domain without any UID placeholder, and the requesting function will need to decipher and handle it accordingly. When using the account specific domain, that'd be something like this:

   https://customer-0123456789abcdef.cloudflarestream.com

So I'm leaning towards 1, but might you have any thoughts, concerns or ideas?

[B-Interactive]

I've made a branch for testing option 1 here: 68232ae74a6ee8ada67c902659116b7223a40e24

[B-Interactive]

I've added this issue to the WordPress Submission Ready milestone, as I think the ability to browse the Stream library is an important feature off the bat.

[davidmpurdy]

Sorry I haven't made progress on this. I keep getting projects coming down the line that need to jump to the front of the queue, and every time I sit down to do this something else comes up.

I'm planning to do a PR to split the first part of get_video_embed into a get_video_url function which generates the $src_uri from the $uid. With that, the block can get the URL from the server and just handle querystring parameters on the JS side. I think it's the best compromise between the official recommendation of not rendering on the server if not necessary (still doing querystring client side) but also recognizing that in some situations (signed URLs), we will need information from the server.