#30123 closed defect (bug) (fixed)
Custom Mime Type filter problem in upload.php list view
Reported by: | csschris | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.1 | Priority: | normal |
Severity: | normal | Version: | 4.0 |
Component: | Media | Keywords: | has-patch |
Focuses: | administration | Cc: |
Description
The issue is that the option values in the select box for attachment-filters are being passed through urlencode on page render and form submission.
I describe the problem with more detail here
This only happens in list view.
Attachments (4)
Change History (13)
@
10 years ago
sorry, hopefully this is the correct .diff file, not the txt version as my previous ones ;-)
@
10 years ago
sorry, hopefully this is the correct .diff file, not the txt version as my previous ones ;-)
#3
@
10 years ago
- Milestone changed from Awaiting Review to 4.1
- Owner set to wonderboymusic
- Status changed from new to assigned
#6
@
10 years ago
Note that the chosen solution here using sanitize_mime_type()
breaks when presented with a comma-separated list of MIME types which is a valid return from get_post_mime_types()
. The originally suggested fix of using esc_attr()
works properly and seems more correct to me. See #30788.
#7
@
10 years ago
@mdgl that's interesting.
To handle a comma sepereated list of mime types, like
application/x-pdf, application/pdf
I think it would be logical to extend sanitize_mime_type
to support this.
For example by adding a single comma (,) into the preg_replace
part of that function.
So instead of this line of the sanitize_mime_type()
function:
$sani_mime_type = preg_replace( '/[^-+*.a-zA-Z0-9\/]/', '', $mime_type );
we could instead use this:
$sani_mime_type = preg_replace( '/[^-+*.,a-zA-Z0-9\/]/', '', $mime_type );
#8
@
10 years ago
Hello birgire, yes, changing sanitize_mime_type()
as you suggest would fix the problem, but I don't think this is the right way to go. The comma is not valid in (simple) MIME type names [see https://www.ietf.org/rfc/rfc2045.txt and http://www.rfc-editor.org/rfc/rfc2231.txt] and by changing this function we might be introducing problems elsewhere.
The bug here is simply that the value needs escaping as it is being used inside a HTML attribute, so I think your original suggestion of using esc_attr()
is the correct solution.
As also reported independently here:
http://wordpress.stackexchange.com/questions/166530/post-mime-types-filter-not-working-in-list-mode
there's a potential problem when filtering custom post mime types, in the list mode.
When we register a custom post mime type, as suggested:
then it will add the following option to the select box for attachments filters:
When we submit this option, the relevant GET request becomes:
The reason for this is the
urlencode
part:Check out this source line: https://core.trac.wordpress.org/browser/tags/4.0/src/wp-admin/includes/class-wp-media-list-table.php#L73
This wasn't a problem in WP 3.9 because it wasn't encoded:
See this code line in version 3.9: https://core.trac.wordpress.org/browser/tags/3.9/src/wp-admin/includes/class-wp-media-list-table.php#L67
I wonder if we could use
esc_attr()
instead ofurlencode()
:so the HTML of the option becomes:
and the
GET
request becomes:which works as expected.
Ps:
Another idea would be to use the
sanitize_mime_type
function:where
but I also wonder if we would need this function or
urlencode
or evenesc_attr()
, since it looks like these mime type strings have already gone through thesanitize_mime_type
function through:but then again, someone might remove or modify the filter ;-)