#29215 closed feature request (fixed)
WP_Customize_Media_Control
Reported by: | celloexpressions | Owned by: | ocean90 |
---|---|---|---|
Milestone: | 4.2 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Customize | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
We'd like to refactor the existing WP_Customize_Upload_Control
, WP_Customize_Image_Control
, and WP_Customize_Background_Image_Control
to leverage the media library (#21483). But the Customizer should also support inserting media (including things like Youtube videos) from a URL, for which "Upload" isn't the best term.
We should introduce a WP_Customize_Media_Control
to serve as the base media-related control that all of the other media image/upload controls extend (or, if we can't be fully back-compat, we could create new controls that extend this one). It should allow developers to specify either a media type (ie, audio, video, image, document, etc; mapping to allowed filetypes and embed providers) or potentially specific filetypes (like WP_Customize_Upload_Control
allows now).
Ultimately, the purpose of this control will be to bring the full power of the media manager into the Customizer.
Attachments (3)
Change History (15)
This ticket was mentioned in Slack in #core by ocean90. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
10 years ago
#7
@
10 years ago
- Keywords has-patch needs-testing added; needs-patch removed
- Milestone changed from Future Release to 4.2
29215.diff implements a new base class for all Customizer media controls: WP_Customize_Media_Control
. It's actually just the current WP_Customize_Upload_Control
with things that are only there for back-compat (from 4.1) pulled out and with a couple of key changes so that it used settings that store attachment ids instead of URLs. WP_Customize_Upload_Control
is then subclassed from the new media control, and contains the extracted back-compat and adjustments to make associated settings store URLs instead of attachment ids. There are no functional changes to the upload control or any of its sub-controls.
We could theoretically create a whole tree of sub-controls directly under the media control like the upload control currently has. But WP_Customize_Image_Control
is completely unnecessary now (just specify the mime_type
arg as image
in the upload or media control), so I don't think we should bother. Note that the default value of settings associated with WP_Customize_Media_Control
is still a URL, since it wouldn't make sense to support attachment ids here.
The CSS changes here are obviously absurd, see #30713 and #30618.
I think we should probably retain the existing @since values in what is now WP_Customize_Media_Control
rather than changing them all to 4.2, but could see it making sense to change them.
#8
@
10 years ago
Patched #30713, so we won't need to worry about the CSS class inflation once that goes in (either this or that can go in first, but the other will need a refresh).
Also, re-reading the ticket description, insert-from-URL still isn't in scope here, since that's easy enough to handle in a text field control or a custom control that implements previewing inline. The biggest issue with the existing media controls is the way the data is stored, and this solves that.
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#10
@
10 years ago
Still waiting for feedback or commit. I don't see any issues with this going into 4.2 but we're low on time if anyone does find issues.
#11
@
10 years ago
- Owner set to ocean90
- Resolution set to fixed
- Status changed from new to closed
In 31698:
After some discussions at WCLA Contributor Day, the thought is that WP_Customize_Media_Control could be a distinct control from the upload/image controls that does what we can't do there because of back-compatibility. The other controls will be updated to leverage the media manager, but we won't be able to leverage any of the other attachment info besides the image URL.
WP_Customize_Media_Control, on the other hand, could store more detailed/structured information in its settings. Potentially, we could store what we would normally put in
the_content
here and apply filters to get_option/theme_mod to render any media shortcodes, external embeds, images with captions and lt tags, etc.