[wp-trac] [WordPress Trac] #38172: Enable Video Headers in Custom Headers

WordPress Trac noreply at wordpress.org
Tue Sep 27 21:02:02 UTC 2016


#38172: Enable Video Headers in Custom Headers
-----------------------------+------------------------------
 Reporter:  davidakennedy    |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Themes           |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:
-----------------------------+------------------------------
Changes (by celloexpressions):

 * keywords:   => needs-patch


Comment:

 Here are a bunch of initial thoughts on the patch (we'll need a lot more
 work here):

 In terms of naming, the section should probably become either "Header" or
 "Custom Header," see the discussions around naming "Custom Logo" for
 history.

 We should absolutely use the core video functionality,
 `wp_video_shortcode()`, rather than building video tags manually. We can
 add any additional parameters that this feature requires to the core
 function. See also the code I shared previously that uses this:
 https://gist.github.com/celloexpressions/77aa54eb7020aa921ec1d3a3ce29696e.

 Using the core video functionality brings MediaElement.js, which is
 bundled with core, adding cross-browser support for any (generally) video
 format that was uploaded and fallbacks for browsers that don't support
 `<video>` at all.

 MediaElement can skin external videos from Youtube or Vimeo; however, in
 my limited testing, autoplay was not possible. There may be ways to hack
 around it, but it's probably best to focus on local uploads and education
 around video file sizes.

 We'll probably need to link off to a page on the codex or a handbook to
 explain video encoding in more detail, with filesize, bitrate, etc. as
 considerations and suggested editing software. In probably almost all
 cases, users will have to go through other software to get their video
 from where they shot it to being able to upload it. Many sites also have
 upload size limitations ranging from 1MB to 50MB; we'll need better
 educational resources around how that can (sometimes) be changed and why
 files needs to be kept small anyway so that visitors will see them.

 Most themes should be able to add something like `the_header_video();` to
 display the video. However, we should look at the interaction with header
 images more closely. Most likely, if there's a video, it'll be displayed
 in place of the header image, and there should be a function that wraps
 both and shows what's there automatically for themes. If we want to always
 show the headers UI even when there's a video, let's document that
 decision and the reasons, and potentially add help text to the header
 image control explaining that it's only shown when there isn't a video, if
 the theme supports video.

 Is there a reason that there should be separate parameters for image size
 vs. video size? The API would be cleaner if we restricted that both should
 match. It will be extremely important for themes to exercise extreme
 caution with their recommended video sizes since that'll have the biggest
 impact on file size and the ability for users to even upload larger files
 on their server, so that may be one reason.

 This should support selective refresh out of the box, by wrapping the
 video output in a div that core can target with a partial. That'll also
 provide support for cross-linking between the preview and the customize
 pane. `postMessage` isn't worth the effort for something like this since
 it essentially requires a partial refresh but without the Ajax call.

 The theme support should probably be two things: a boolean `video`
 parameter that defaults to false, and the default fallback. We'll need
 major restrictions on file size from the TRT if we allow default videos to
 be bundled, as they will drastically increase the size of theme zips and
 slow down installs. Even 1MB of video may be too much. And external
 hotlinked defaults are a bad idea.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38172#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list