#22149 closed defect (bug) (fixed)
Customizer Uploader doesn't restrict by file type
Reported by: | pento | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Upload | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
When using the Theme Customizer to upload a new background image, it doesn't restrict the file types that can be uploaded. For example, I can upload a video file, the file will be uploaded and inserted into the Media Library, then the Customizer will try to treat it like an image.
I think the best way around this would be to restrict uploads in the Customizer to images only.
Attachments (3)
Change History (20)
#3
@
12 years ago
The async fix in 22149.3.diff won't work unless the Customizer upload control passes on the context, which, judging by the code in customize-controls.js, it should in post_data[context]
. Opened #22215.
#5
follow-up:
↓ 6
@
12 years ago
- Cc mdhansen@… added
Tested patch 22149.3.diff and 22149.2.diff and both worked on custom-header.php and custom-background.php. However, I am able to upload mp4 files and pdf on the customizer without warning.
#6
in reply to:
↑ 5
@
12 years ago
Replying to MikeHansenMe:
22149.3.diff should block non-image uploads in the Customizer only when the patch is #22215 is applied.
#10
@
12 years ago
For custom headers and backgrounds, this looks solid.
For the customizer (and anything that uses Plupload), we can limit the filetypes that a Plupload will accept via JS (see the filter
property), and could block the uploads earlier on as a result.
At this point, it probably makes sense to land the customizer-specific code as well.
#12
@
12 years ago
While [22492] works, Plupload's falls back to the browser's default behavior for filetypes it doesn't recognize, which is pretty universally a terrible experience. So we might just want to reject it PHP-side for now.
#13
@
12 years ago
In theory, [22492] is the best solution. In practice, Plupload handles disallowed files terribly, by falling back to the browser default. That means HTML files replace the entire viewport, ZIP files get re-downloaded, etc. I'd rather revert and go with solely 22149.3.diff.
#14
@
12 years ago
koopersmith and I were both testing this with drag events. This is definitely a better experience for the dialog, because non-images are grayed out. We should be able to intercept the drag event for disallowed files in our own Plupload handlers/wrappers. So I'm going to leave it for now.
Confirmed. This is also true for the old Custom Header and Custom Background upload fields. Here's what I get when I upload a PDF as a Header Image: http://cl.ly/image/3P2c1I0o2e2H And when I do that with Custom Background I get the "Background updated" message, and the
background-image
inbody.custom-background
now points to my PDF file.