Make WordPress Core

Opened 12 years ago

Last modified 5 years ago

#22128 new defect (bug)

Adding upload mimetype in Multisite does not work if mimetype is not already defined

Reported by: bjornw's profile BjornW Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 3.0
Component: Upload Keywords:
Focuses: ui, multisite Cc:



We would like to add 3gp to the list of file types to be uploaded in the sites of our network install.

We've tried to add 3gp to the Network Settings->Upload File Types setting for this. However after having saved the setting we were still not able to upload 3gp. It seems the user setting is being overruled by the list of global settings.

Steps to reproduce issue:

  1. Use WordPress Network install (aka Multisite)
  2. Add the file extension 3gp to the upload file types setting in Network Settings
  3. Save Settings
  4. Try to upload a 3gp file using the Media Library, it will fail with the message: 'Sorry, this file type is not permitted for security reasons.'

It seems the upload file types defined in the Network Settings cannot overrule / add new file types if this file type has not already been defined in the function wp_get_mime_types() (see file: wp-includes/functions.php).

Expected behaviour

Changing the Upload File Types by adding a new extension results in WordPress accepting files ending in this extension. Or warn the admin that this extension is unknown and more info (such as the full mime type) is needed.

Proposed solution

We are aware of the hook 'upload_mimes' to fix this with a plugin, but we suggest that the superadmin Network Settings->upload file type overrules WordPress' built-in defaults instead of the other way around.

Attachments (1)

screenshot-mimetypes.png (40.3 KB) - added by roytanck 12 years ago.
Possible UI enhancement to make mime type availability clearer (proof of concept code available on request)

Download all attachments as: .zip

Change History (24)

#1 follow-up: @SergeyBiryukov
12 years ago

Related/duplicate: #20997

#2 @roytanck
12 years ago

IMHO, the root of the problem here is that there's a "hidden" list of mime types that WordPress is capable of accepting (via uploads), and there's a network-wide setting that accepts only a subset of this list. The UI does not make this clear to admins, and there's no UI for the list.

#3 in reply to: ↑ 1 @BjornW
12 years ago

SergeyBiryukov, the related issue you mention is closed. It refers to your documentation of this issue on the Codex. This is helpful, but I'd consider this still to be an usability bug causing unexpected behaviour for superadmins.
Therefor I suggest it should be addressed not only by documenting the issue, but by solving it in the UI.

My suggestions:

  • changing the UI so that a superadmin can only select file extension from the WordPress included whitelist with a note referring to your documation that this can be changed using the hook 'upload_mimes'. This can, for instance, be done by showing the WordPress whitelist in a multiselect dropdown instead of an input field.
  • completely removing the UI option, and relying on a plugin for adding / changing file extensions with it's own GUI. This is probably similar to how a single WordPress install deals with file extensions (haven't checked it yet).

12 years ago

Possible UI enhancement to make mime type availability clearer (proof of concept code available on request)

#4 @wonderboymusic
12 years ago

  • Keywords reporter-feedback added; dev-feedback removed

there's a filter for 'upload_mimes'

function get_allowed_mime_types() {
	return apply_filters( 'upload_mimes', wp_get_mime_types() );

Which has another filter:

function wp_get_mime_types() {
	// Accepted MIME types are set here as PCRE unless provided.
	return apply_filters( 'mime_types', array(

The documentation on this is unclear as to what the network options do

#5 @SergeyBiryukov
12 years ago

  • Keywords ux-feedback added; reporter-feedback removed

screenshot-mimetypes.png seems good to me.

#6 @BjornW
12 years ago

@SergeyBiryukov: Is the info in the ticket enough for someone from UX (any names?)

#7 @SergeyBiryukov
12 years ago

I guess so, comment:2 summarizes the UX/UI issue.

#8 follow-up: @helenyhou
12 years ago

I think there could be better docs and language to make it clear that the admin option can only really select from a subset of what's available via code (and not allow it to save something that doesn't work). A pile of checkboxes is probably not the right UI, though - it's slower than typing a comma separated list, and leads to all sorts of issues with alignment, balance, and label length. I wonder if something like autocomplete would work better, even, although it still would require better descriptive text as to why you can't just add anything. Definitely agreed that it's misleading experience overall and needs some sort of help.

#9 in reply to: ↑ 8 @BjornW
12 years ago

@helenyhou: I agree the docs should be better, but I also think the UI should reflect the limited set of choices. Checkboxes reflect the limited options one can choose. Another option could be a multi-select dropdown. IMHO text input fields convey a 'free-form' field in which anything may be typed into which clearly is not the case. Therefor I would suggest something which conveys the limited set of options instead.
As for label lengths, this should not be a problem since we would only display mime-types / file extensions as label, which afaik do not have to translated. As roytanck shows in his screenshot the list of checkboxes can be made into more or less balanced lists. Perhaps adding a select all & reset would make it more userfriendly, similar to selecting multiple posts?

#11 @helenyhou
12 years ago

  • Keywords ux-feedback removed

Not saying that a free-form text input doesn't have its problems or that there are only documentation problems and no UI problems. Saying that a potentially enormous set of checkboxes is perhaps not the way to go, and maybe it would be worth discussing other methods.

#12 @SergeyBiryukov
12 years ago

Another option I'm thinking about is to keep the text input and display an error message on saving when trying to add a mime type not from the list of acceptable types.

#13 follow-up: @nacin
12 years ago

In general, I think I would prefer for this UI to be in a plugin — including the current input box.

#14 in reply to: ↑ 13 @roytanck
12 years ago

Replying to nacin:

In general, I think I would prefer for this UI to be in a plugin — including the current input box.

If we'd move this into a plugin, you'd still set upload quota, etc though this network admin screen, but (without the plugin installed) you'd have no control at all over upload file types? And no info about default allowed types? I feel that upload-related settings should be in one place and 'complete' without plugins.

The only UI pattern I can think of that really accommodates a many-from-even-more selection like this one of those dual lists with arrows inbetween.

#15 @SergeyBiryukov
12 years ago

  • Version changed from trunk to 3.0

#16 @mbijon
12 years ago

  • Cc mike@… added

What is the current take on relying on JS for the admin to work?

I think a UX like this jQuery tag input plugin provides, especially including the autocomplete list, would be compact and simple: (autocomplete demo is 3rd down on right-side of that page)

... but the no-JS fallback would probably require layout changes to accommodate all the checkboxes or multi-select lists.

edit: I just realized licensing on that plugin isn't clear. I've seen other versions of this, might need to find a GPL one.

Last edited 12 years ago by mbijon (previous) (diff)

#17 @helenyhou
12 years ago

We generally stick to having a fallback, which could be a comma separated list. Tags/non-hierarchical taxonomies work like that, although it still leaves you without knowing what's actually available for use. Not sure autocomplete is the right way, though. It doesn't necessarily give you an overview of what is or isn't available, and to me isn't really any better than freeform text input here.

I have a suspicion we're throwing UI at something that needs a different approach entirely. Why does this setting need a UI at all?

#18 @mbijon
12 years ago

True on autocomplete in general. Would be interesting to have an "all-complete" list instead. All available extensions would be included, but by highlighting the already allowed extensions within that list you'd have better visualization & possibly on/off functionality.

Do you mean no UI in core (ie: the plugin idea) or that this should be setup like CPTs?

Allowing an array or CSV list in PHP would be a pretty easy way to still support this in core, bult leave the UX up to plugins.

#19 follow-up: @helenyhou
12 years ago

I guess I mean that perhaps there doesn't need to be UI in core, and would rather not think about what a plugin would do right at the moment. I just want to figure out what the base issue is here, and what the right workflow would be.

This is my understanding:

  • There is a filterable set of mimetypes that are allowed in a WP install (whitelist).
  • In a multisite installation, there is a network setting for mimetypes allowed (or rather, extensions), that in unindicated reality can only be a subset of the aforementioned set.

Since it's network-wide, not site-specific, and thus only manageable by a superadmin and quite technical, I'm not sure I see why there needs to be an option for this at all, much less any UI to go with it. Seems to me that the solution for changing what mimetypes are allowed on a network install is to use the upload_mimes filter mentioned in comment:4. Is there something I'm missing about what the end result is of the whitelist-of-a-whitelist technique currently employed vs. straight up filtering the allowed mimetypes?

Last edited 12 years ago by helenyhou (previous) (diff)

#20 in reply to: ↑ 19 @BjornW
12 years ago

@helenyhou: We have developed several WordPress Multisite installations for clients. Ranging from 100 to more than 30K users. In our experience the superadmin, in the organizations we've worked with, is usually not the same person as the one allowed or able to implement code to use a filter in order to change a setting like this one. A superadmin may seem technical, in our experience they usually are not. Your suggestion to drop the UI is therefor in our opinion & experience not a solution for this issue.

I personally would prefer to try out the solution proposed by roytanck as the fallback option & enhance his solution with Javascript for more modern browsers to make the UI more pleasant, like mbjion suggested.

Maybe we should concentrate our efforts on a plugin to 'demo' a few UX changes and see if we can get the best one into core?

#21 @helen
12 years ago

  • Keywords ui-focus added

For the record, I work for an agency myself :) I guess the whole concept of having a UI that can only do a whitelist-of-an-invisible-whitelist seems less than ideal no matter the technical ability of a superadmin. What I meant by technical was the nature of selecting file types to allow for upload on a network-wide scale. If you're developing things for clients, then surely you can implement the filter or install a UI plugin for them? Are they really changing this setting so often it warrants a UI? Does messing with the UI fix the base conceptual issue of there being a whitelist-of-a-whitelist? (It might, I'm just wondering.)

Yes, working on a UI (whether through code/plugin or mockups) that keeps long lists, strings, and any other potential variants in mind would be good.

#22 @jeremyfelt
11 years ago

  • Component changed from Multisite to Upload
  • Focuses multisite added

#23 @jeremyfelt
9 years ago

  • Severity changed from critical to minor

Overall I tend to agree with the thought that this input is of little value for most installations. It gets especially annoying for both parties (network admin and dev) when a non whitelisted filetype (e.g. EPS) is added to the input field and continues to generate support requests until someone realizes that the mime type hasn't been added. This actually happened today for me. :)

That said - I can see a benefit to not allowing uploads of the ~90 mime types whitelisted by default, especially when not all fit in the "media library" box. Some UI is useful for reducing the current list, but that UI will likely be used anywhere from 0 to 1 times by the majority of multisite configurations.

As for the initial subject of this's a good thing that a whitelist exists and blocks invalid values.

One of the "expected behaviors" listed was:

Or warn the admin that this extension is unknown and more info (such as the full mime type) is needed.

I think that would be a good solution to this ticket. A plugin would be a perfect place to iterate possible UI solutions, though patches here would be helpful as well.

Note: See TracTickets for help on using tickets.