Media library filename based on GUID prevents embedding

[daxelrod]

The "Add Media" modal on posts is dependent on GUID matching the actual filename to allow embedding of audio and video media attachments. The "Attachment Display Settings" pane provides options for "Embed or Link" or "Link To" depending on canEmbed. But if the GUID is a permalink (example.com/?attachment_id=XXX) instead of an actual filepath (example.com/wp-content/wp-uploads/file.mp3), the audio or media element cannot be embedded in a post via the admin UI - only the "Link To" options will be presented.

wp.media.controller.Library.canEmbed checks for attachment type "audio" or "video" and also checks the filename for a specific extension:

return _.contains( wp.media.view.settings.embedExts, attachment.get('filename').split('.').pop() );

If given an actual filename, the function performs as expected. But provided with a permalink, it fails and the attachment cannot be embedded.

Imported media especially has this issue because of how GUIDs are automatically assigned in wp_insert_post():

	// Set GUID.
	if ( ! $update && '' == $current_guid ) {
		$wpdb->update( $wpdb->posts, array( 'guid' => get_permalink( $post_ID ) ), $where );
	}

Fixing this has a side benefit of making the attachment title (filename) in the media library more accurate as well.

[daxelrod]

Patch to replace GUID with attachment filename

[daxelrod]

Attached patch which attacks this from wp_prepare_attachment_for_js(). Replaced $attachment->guid with get_attached_file( $attachment->ID ).

[wonderboymusic]

In 32914:

In wp_prepare_attachment_for_js(), when setting filename, call wp_basename() on the result of get_attached_file(), not WP_Post->guid. guid can be set to the result get_permalink(), which is not a file path.

Props daxelrod.
Fixes #32531.