#20672 closed defect (bug) (fixed)
Mime-Type Matching Error With Certain Added Mime-Types
Reported by: | toneburst | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Media | Keywords: | has-patch |
Focuses: | Cc: |
Description
I think I've found a bug in the handling of post_mime_types with certain legitimate file MIMEs. My suspicion is that the problem is related or similar to that reported in #Ticket #17855, and apparently fixed in Wordpress v3.2.
The particular problem I've been experiencing only becomes apparent when adding MIME-types to the $post_mime_types array via the post_mime_types filter hook. For example, the following is a legitimate MIME-type:
application/vnd.google-earth.kml+xml
However, if I add the MIME to post_mime_types array with:
function kml_modify_post_mime_types( $post_mime_types ) { $post_mime_types['application/vnd.google-earth.kml+xml'] = array(__('KML'), __('Manage KML'), _n_noop('KML <span class="count">(%s)</span>', 'KML <span class="count">(%s)</span>')); return $post_mime_types; } add_filter( 'post_mime_types', 'kml_modify_post_mime_types' );
in my plugin, I don't see a filter link at the top of the Media list (like the ones for Video, Audio etc.), as I should do. I may be wrong, but I think this is because the '+' character in the attachment MIME-type is not handled correctly.
To test this, I tried faking a new MIME, minus the '+'. I changed the MIME-type my plugin add to the post_mime_types array to
$post_mime_types['application/vnd.google-earth.kmlxml'] = array(__('KML'), __('Manage KML'), _n_noop('KML <span class="count">(%s)</span>', 'KML <span class="count">(%s)</span>'));
then changed the value in the MIME field of a previously-uploaded KML file to the same (application/vnd.google-earth.kmlxml). Now I DO see the filter link, and clicking on the link reveals the KML file as the only item in the filtered list, as it should.
I'm not sure if the problem manifests itself anywhere else. I've not found any evidence it does, but it may well do. From doing some multi-file searches on the WP system files, my suspicion is that the problem is with one or both of the following functions in post.php:
- wp_match_mime_types()
- wp_post_mime_type_where()
but I'm really not sure.
I'd be grateful if a more skilled coder than me could confirm if this is actually a bug. I'm afraid my regular-expression understanding is minimal, but I suspect this might be an easy fix for someone who knows their stuff.
I'm more than happy to run any tests anyone might suggest to help pin down the source of the problem and/or help fix it.
Thanks guys.
a|x
Attachments (3)
Change History (9)
#4
@
10 years ago
This patch applies clean for me and does the trick.
Here's boilerplate for a plugin to test.
<?php function kml_modify_post_mime_types( $post_mime_types ) { $post_mime_types['application/vnd.google-earth.kml+xml'] = array(__('KML'), __('Manage KML'), _n_noop('KML <span class="count">(%s)</span>', 'KML <span class="count">(%s)</span>')); return $post_mime_types; } add_filter( 'post_mime_types', 'kml_modify_post_mime_types' ); function add_kml_mime_type( $mime_types ) { $mime_types['kml'] = 'application/vnd.google-earth.kml+xml'; return $mime_types; } add_filter( 'mime_types', 'add_kml_mime_type' );
And then download a random KML file. Upload it, and notice the MIME-type tab for KML in the Media Library tabs.
The problem is that
wp_match_mime_types()
fails if$wildcard_mime_types
contains regular expression special characters like "+".The attached patch uses the technique from WP_oEmbed: replace "*" with a non-special string, preg_quote(), replace the placeholder string with "[-._a-z0-9]*".