Changes to oEmbed?

Hi all,
Until recently, we had been successfully using a very simple plugin to allow us to embed videos from our campus streaming media in Pressbooks. It doesn’t appear to be working in our production environment, possibly because the filters Pressbooks applies for oEmbeds may have changed?
Here’s the code our plugin was using
add_action( 'init', 'uwmad_kaltura_add_oembed_handlers');
function uwmad_kaltura_add_oembed_handlers(){ wp_oembed_add_provider( '*', '', false ); }
@ned or @dac.chartrand or others, can you see anything that we might need to change or update so that it works in the new Pressbooks environment?

Can you post an example URL?

Your plugin basically says if a URL matches the left side, then call the Oembed server on the right side.

Example using:

When you click the 2nd link you get JSON.

If I do the same with something from your plugin:

I get JSON.

If I do it with

I get Application Error.

Note that the pattern isn’t the same.

Here’s a sample URL: should also work, without the extra parameters.

The book where we noticed this malfunctioning is, if that helps …

Hi Steel, I installed the plugin you use on a test network and dropped the sample URL into a new chapter (running the latest Pressbooks) and got an OEmbed without issue:

In the link you shared to the book, I’m a bit confused. The first embed URL ( prompts for a username and password when I try to access it directly (the sample URL you gave me does not). Same with all the subsequent ones that are only showing as URLs. If you try the OEmbed endpoint for one of them there’s no JSON:

It looks to me like whoever administers the Kaltura MediaSpace server at UW Madison made a bunch of videos private, which is why (some of) the embeds aren’t working. No code has changed on our end.


That makes a lot of sense—sorry for taking up your time to solve a problem I should have more done more thorough investigation on before bringing here. The original email from the author noted some iFrames that had been stripped out and I too quickly assumed that this issue was also related to changes introduced in 5.0.0.