#40935 closed defect (bug) (fixed)
Facebook Video Works On Preview But Not On Theme
Reported by: | emanweb | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.8.1 | Priority: | normal |
Severity: | normal | Version: | 4.8 |
Component: | Widgets | Keywords: | has-patch fixed-major |
Focuses: | Cc: |
Description
I am using a vanila Twenty Seventeen with 4.8RC2 and once I add a Facebook video using widget it shows up in the preview but not after adding it. See screenshots below:
Enviromments tested:
WP: 4.8-RC2-40875
Nginx: 1.10.1
PHP 7.1.4
MySQL 5.6.34
WP: 4.8-RC2-40875
Nginx: 1.10.1
PHP 7.0.3
MySQL 5.6.34
WP: 4.8-RC2-40875
Apache: 2.4.10
PHP 7.0.3
MySQL 5.6.34
Once Added Video URL It Shows This
p.s.: This is my first time reporting a bug, so please excuse me if I did it the wrong way.
Attachments (1)
Change History (14)
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
8 years ago
#3
@
8 years ago
Alternatively, it would be more ideal to allow for arbitrary oEmbed video or audio to be referenced. To do that, we'd need #34115 resolved, and then the widget would need to switch between ME.js rendering and oEmbed rendering, depending on the URL provided.
#4
follow-up:
↓ 5
@
8 years ago
I got same problem with frontend when using direct link to .mp4
( https://myhost/file.mp4 )
It works fine with the backend, all the time, but shows as link on frontend
https://myhost/file.mp4?loop=0
Clean WP, twenty seventeen theme (updated)
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
8 years ago
#7
@
7 years ago
- Keywords has-patch added; needs-patch removed
I spent some time exploring the options here - ideally like @westonruter said above, the most ideal solution would be to respect all whitelisted embed providers, like Facebook, in this scenario. As he mentioned, we do need #34115 resolved to proceed there since we can not use any of the embed shortcode logic without a $post
. I would go a bit further and say to fully leverage oembeds, we should explore a way to add mime types to the provider list ( https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/class-oembed.php#L57 ) - so we could properly determine which embeds would work in which context ( Audio vs Video widget ).
Ultimately though, this kind of brings me back to the notion of a generic oembed widget. When we do have the ability to use embeds with a post, perhaps when a user pastes in an approved embed URL, the widget automatically changes from a Video or an Audio widget to an embed widget.
For the time-being though, we are still restricted by the $post_ID
requirement ( https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/class-wp-embed.php#L193 ) in the embed shortcode logic. If this were not there, we could add logic to the widget rendering that detects an embeddable URL, and returns the embed instead of the wp_video_shortcode
logic. As such we are still currently limited by what mejs
supports for playback which is Vimeo and YouTube.
40935.1.diff extends the existing validation logic in media-widgets.js
to ensure the URL inserted in the modal is Vimeo or YouTube before fetching the oembed/proxy. This allows a URL to an external .mp4 file to be used still, but also ensures that only the truly supported external providers can be used.
#8
@
7 years ago
- Owner set to westonruter
- Resolution set to fixed
- Status changed from new to closed
In 40939:
#9
@
7 years ago
- Keywords fixed-major added
- Resolution fixed deleted
- Status changed from closed to reopened
Re-opening for consideration in 4.8.1.
This is a bug. Only YouTube and Vimeo are supposed to have been acceptable.
The video widget somehow needs to extend the fetch logic to take into account isHostedVideo, perhaps. There could perhaps be a new
MediaWidgetControl#isAllowedUrl()
which by default returnstrue
, or rather it should include the specific logic in thefetch
method. Then the video widget specifically can extend thatisAllowedUrl
method to take into accountisHostedVideo
. Since oEmbed is not supported by the audio widget at all, then it should bail entirely if the URL is not for an audio file.