Insert Into Post for Audio / Video doesn't always work

[wonderboymusic]

As Otto pointed out, "Link To" can be set to "None" which was sending a broken shortcode to the editor. The HTML sent to the editor should be based on what is selected using "Link To" in the Media modal.

the attached patch makes the shortcode always work, but doesn't change when the Link To option changes. Working on that next.

Is this still a bug?

Will in-westi-gate

this is still necessary - the patch still applies cleanly and needs to be committed, but the ticket shouldn't be closed yet, need to decide what to do when someone selects "Link to Attachment Page" or whatever

this is mainly for the content editor, not the format meta

In 23870:

Fix some Insert-into-Post for Audio/Video bugs.

props wonderboymusic. see #23831.

attachment:23831.2.diff​​ enforces dimensions for video, when present, in all cases. The post format meta for video is now a shortcode, so the dimensions don't have to be looked up on the fly. For audio and video, the meta can be an attachment id, url, HTML embed code, or a shortcode

Introduces attachment_url_to_postid() which will try to convert a URL containing a home_url() front into post ID by looking at the guid column for an attachment in the posts table

The issue Otto brought up, which is the original reason for this ticket, still exists. The question is: should the content change for Insert Into Post for audio or video when the user selects the custom, file, post or none URL option. As it stands, all insert the proper shortcode, there is no difference based on that selection

Replying to wonderboymusic:

Introduces attachment_url_to_postid() which will try to convert a URL containing a home_url() front into post ID by looking at the guid column for an attachment in the posts table

This will not work on many sites. The guid is _not_ the url to an attachment when the site or the uploads directory has been moved. To do something like this you will need to look at _wp_attached_file post meta, etc. Check out wp_get_attachment_url().

Refreshed against latest trunk

Wouldn't url_to_postid() work for attachments? From my testing, it does.

last I checked, only checks attachment page, not the actual file

I am going to redo that func as per Ozz

Replying to wonderboymusic:

last I checked, only checks attachment page, not the actual file

Indeed, I only tested with attachment pages.

In 23969:

Enforce video dimensions.

props wonderboymusic. see #23831.

23831.5.diff​ fixes the 404 - dynamic rendering of file types that trigger Flash or Silverlight was the issue

23831.5.diff doesn't fix the 404 for me. The 404 happens on the front end and the back end. This fixes neither for me.

Can you confirm your cache is empty? I was able to reproduce the error repeatedly until I cleared Chrome browser cache

My cache is completely empty. Multiple browsers. Still can reproduce the issue.

Did you upload the wrong patch or forget to add a file to the stage? Looking at .5.diff, I can't imagine why you'd think that would have any effect on the front of the site.

​https://github.com/johndyer/mediaelement/issues/835

It still works for me locally, not sure what is up - I pasted the URL on GitHub

23831.6.diff​ + flashmediaelement.swf​​ are latest for MEjs 2.11.3 - works for me... could use other testers. Need to select videos that trigger the Flash or Silverlight plugin so that we can confirm the .swf and .xap paths aren't 404ing

In 23977:

Update MediaElement.js to 2.11.3

props wonderboymusic, John Dyer. see #23831.

Missed a semicolon in [23870], see 23831.7.diff​.

In 23998:

Add missing semicolon. props kovshenin. see #23831.

Replying to azaozz:

Replying to wonderboymusic:

Introduces attachment_url_to_postid() which will try to convert a URL containing a home_url() front into post ID by looking at the guid column for an attachment in the posts table

This will not work on many sites. The guid is _not_ the url to an attachment when the site or the uploads directory has been moved. To do something like this you will need to look at _wp_attached_file post meta, etc. Check out wp_get_attachment_url().

Sounds like a valid concern to me.