[wp-trac] [WordPress Trac] #39550: Some Non-image files fail to upload after 4.7.1

WordPress Trac noreply at wordpress.org
Thu Feb 23 16:38:26 UTC 2017


#39550: Some Non-image files fail to upload after 4.7.1
------------------------------------+------------------------
 Reporter:  greatislander           |       Owner:  joemcgill
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  4.7.3
Component:  Upload                  |     Version:  4.7.1
 Severity:  critical                |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------------

Comment (by kontur):

 Yes, I understand. At any rate, this bug pretty much renders a plugin of
 mine useless, since it is centred around uploading and displaying
 webfonts, all of which, I think, require that the accepted mime type gets
 augmented, and then successfully passes this check - which currently it
 doesn't, or seemingly only sporadic on some installations.

 Replying to [comment:107 blobfolio]:
 > Replying to [comment:106 kontur]:
 > > Even when passing in my augmented mimes again as $overwrites [...]
 finfo returns the type for my uploaded woff as ""application/octet-
 stream", which contradicts the mime received from the file extension which
 wp_check_filetype() correctly extracted, alas $ext and $type get set to
 false, which triggers the error message then.
 >
 > Yeah, in general, `application/octet-stream`, `text/plain`, and anything
 falsey like `NULL`, `FALSE`, or `""` should basically be treated as a lack
 of `finfo` support rather than a hard-stop error.
 >
 > At any rate, the role of `finfo` in the upload process is going to have
 to be diminished quite a bit from its 4.7.1 implementation. It can be used
 to reliably detect certain limited types of deception, but because the
 WordPress core only natively supports a single ext:mime mapping, it can't
 be used for broader validation.
 >
 > The WOFF spec does include magic number support, but since the format
 has been associated with a half-dozen different MIME types over the years,
 even if PHP does produce a match, it might not be the one match WordPress
 is looking for.
 >
 > There is, however, potential for plugins to provide a more robust
 `finfo()`-based validation process. Depending on how this ticket plays
 out, I'll put something together for everyone. ;)

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


More information about the wp-trac mailing list