Reverse old embed HTML if it has videopress URLs in it

[gravityrail]

Older versions of VideoPress may have embedded HTML in a post in this format:

<p><embed src="http://v.wordpress.com/somevideoid" type="application/x-shockwave-flash" width="600" height="338"></embed></p>

Most browsers now block flash by default, so this old content cannot be viewed.

This patch fixes the issue in a minimal way by looking for embed codes with URLs matching v.videopress.com and extracting the ID from the URL.

It makes no attempt to extract the width and height. Nor does it "fix" your post by permanently changing the stored content. It simply intercepts the HTML during the_content and renders the shortcode, which then gets expanded to the full videopress tag at the default width and height.

Changes proposed in this Pull Request:

• Convert <embed src="http://v.videpress... markup into [videpress SomEVideOiD] shortcodes

Testing instructions:

• Create a VideoPress video and note the ID
• Edit raw HTML and add some markup like this:

<p><embed src="http://v.wordpress.com/[YOUR VIDEO ID]" type="application/x-shockwave-flash" width="600" height="338"></p>

• View the post, output should be the HTML5 video embed

Proposed changelog entry for your changes:

• Automatically render old videopress flash embed code as HTML5 player

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: January 14, 2020.
Scheduled code freeze: January 7, 2020

Generated by 🚫 dangerJS against 52cb06f

[kraftbj]

What would you think about doing this same thing also when opening a post up for editing and/or on save? It'd organically fix older posts if/when they are ever edited while still catching those that aren't?

[jeherve]

I like Kraft's idea of fixing old posts, although I assume this may not be used much since I assume few folks end up editing old posts.

I do have some remarks below.

[kraftbj]

Suggestion:

• For this PR, convert the old embed to an oEmbed URL.
• Filter it on the_content at some mutually agreed point. I personally like the idea of providing it wide and far (e.g. anytime Jetpack is active).
• Lay aside for now my idea for converting it on editing/save/etc for a future PR in interest of not delaying implementation. Also, it allows us more time to research any other variations of the embed without having data change along the way.
• Adding unit tests with an instance that matches. @jeherve what other tests to you suggest?

[kraftbj]

I've updated the PR to use oEmbed and filter the_content more broadly. No unit tests yet.

Though, my initial testing suggests Core's oEmbed for VideoPress URLs is not working as expected -- they aren't loading with Jetpack active unless the VideoPress module is enabled. I'd like to investigate that before landing this PR.

[kraftbj]

I'd like some extra eyes to make sure this works. I think the oEmbed cache was getting in the way due to trying to embed a VideoPress that hadn't fully encoded yet and this works fine as is.

[jeherve]

I like this, it tests well and I think modules/videopress/utility-functions.php is just what we need here. This should be good to merge!

[gravityrail]

Thank you @kraftbj and @jeherve for jumping on this and doing a great job.