Opened 7 years ago
Closed 7 years ago
#42896 closed enhancement (wontfix)
ms-files.php doesn't apply filters/actions defined in must-use plugin
Reported by: | cory.r.gilbert | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.9.1 |
Component: | Media | Keywords: | |
Focuses: | Cc: |
Description
This could be considered a bug or an enhancement, depending on how you look at it. I've decided to classify it as an enhancement because the issue I ran into apparently would have been avoided if the ms-files.php file took advantage of the filters/actions that I defined in a must-use plugin (apparently it does not). But there are perhaps other ways the specific issue could be addressed.
The specific scenario was as follows:
After an upgrading from 4.8.3 to 4.9.1, our multisite instance began using the wrong Content-Type when serving up JavaScript files that were previously uploaded to the Media Library.
In ms-files.php, there is a call to wp_check_filetype()
which in turns calls get_allowed_mime_types()
which was changed in 4.9.1 to prevent JavaScript files from being uploaded unless the user has unfiltered_html capability. It also applies the upload_mimes
filter which should allow plugins to tweak the returned list.
While this all works as expected as far as uploading the files to the media library, in the context of serving those uploaded files (via ms-files.php) our must-use plugins (which assigned unfiltered_html capabilities and also defined a filter for upload_mimes) are not active and therefore the wp_check_filetype()
is not able to determine the mimetype.
The code in ms-files.php then tries to use mime_content_type()
to identify the correct type, but does it incorrectly (I think because of what is described at https://bugs.php.net/bug.php?id=53035) and thus applies the incorrect content type response header when the file is served.
There are several debatable ways to fix this specific problem, but if the must-use plugins were applied in this context, then it seems like all would have been fine.
As
ms-files.php
has been deprecated for many many versions now, andms-files.php
specifically usesSHORTINIT
which is designed to run WordPress without plugins & most code loaded, I'm going to close this aswontfix
for now. Unfortunately it's not as easy as loadingmu-plugins
, as they will often rely upon other WordPress functionality which is deliberately not included at that point in time.If you need to change this in your environment, you can use the Multisite Sunrise functionality (Add
define( 'SUNRISE', true );
towp-config.php
and add awp-content/sunrise.php
file, which is effectively a mu-plugin).