#40935 closed defect (bug) (fixed)
Facebook Video Works On Preview But Not On Theme
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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.
9 years ago
#3
@
9 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
@
9 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.
9 years ago
#7
@
9 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
@
9 years ago
- Owner set to westonruter
- Resolution set to fixed
- Status changed from new to closed
In 40939:
#9
@
9 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 thefetchmethod. Then the video widget specifically can extend thatisAllowedUrlmethod 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.