Problem with upload_mimes hook

Thanks for your report and for posting your code.

The current MLA version does a one-time processing of registered MIME types when it is first loaded, captures everything at that point, then takes over from there. It does not go back to the upload_mimes filter on subsequent page loads.

The $mimes['svg'] = 'image/svg+xml'; type is already present in the MLA list. You can easily add the $mimes['harm'] = 'text/plain'; type on the Settings/Media Library Assistant Uploads tab. Once that’s done you will have both types in the supported/active MIME types list. If you inactivate MLA your filter will take over and provide the same outcome.

I am marking this topic resolved, but please update it if you have any problems or further questions regarding MLA’s MIME type support. Thanks for your continued interest in the plugin.

I understand your reasoning but I simply think your capturing shouldn’t result in the impossibility of other code (for example other plug-ins) to be executed properly. On what priority is your capturing executed? If every other code has a higher priority than that the setting (or unsetting) will be correct.
I haven’t checked what filter wpuxss_eml_upload_mimes is supposed to do but will that be blocked too?

Thanks for your update and for your understanding. I agree that the current approach is a compromise. I remember spending a lot of time working on interactions with other code and plugins before settling on the solution I did; it got very complicated.

The MLA filter runs at priority 0x7FFFFFFF, or 2147483647 base 10. If you assign your filter a priority number greater than that it will run after MLA and may give you the results you want. I haven’t tested it, but you can give it a try.

I regret the news is not better, but let me know if you try the priority experiment and what your experience is. Thanks again.

Well I added my filter with priority 9223372036854775800 (which is 7 lower then php_max_int on my server. Then my filter works fine and both mime types are added. I know the priority is just a number in an array but why did you code such a large number? Isn’t there some way to postpone execution of your add filter to the moment you desire?

And come to think of it? Why does my add mimes only work after your filter execution? Shouldn’t it be the other way around? Your filter wants to pick the available mime types or not?

Thanks for experimenting with the filter priority and for posting your results.

The MLA MIME Type support was added in version 1.40, released in June 2013, and I haven’t looked closely at these features since then. The following remarks are based on a recollection of my thinking at that time.

MLA distinguishes three categories of MIME type definitions:

1. WordPress core definitions
2. MLA additional definitions
3. Custom definitions

There are, of course, other sources of “custom” definitions such as other plugins and site-specific PHP code like yours. When MLA MIME support is first activated the code goes through all of the defined MIME types and 1) loads the WordPress core types, 2) adds the MLA additional types and finally 3) adds any custom types sourced from other plugins and PHP code.

After the initial load, MIME types can be added, removed, activated or deactivated using the Settings/Media Library Assistant Uploads tab. MLA stops looking for or accepting any MIME types from other sources (plugins and code) because I could not work out how to reconcile changes from those other sources with changes made through the MLA user interface. For example, the MLA “Views” tab lets you define “Post MIME Types” that are used for some WordPress functions but not for associated a file type with a MIME type. I also could not think of a reason to continue using other plugins or code once MLA support was active. If you can make a case for changing those assumptions I will reconsider.

You asked “I know the priority is just a number in an array but why did you code such a large number? Isn’t there some way to postpone execution of your add filter to the moment you desire?” The large number is the WordPress-approved way to postpone execution of my add filter until after other plugins and code has run, so I can capture the maximum amount of custom type definitions when the “first activated” analysis is performed.

You asked “Why does my add mimes only work after your filter execution? Shouldn’t it be the other way around? Your filter wants to pick the available mime types or not?” If your code runs after the MLA filter it starts with the list MLA provides and adds to it. As I explained above, MLA wants to “pick the available mime types” when it first runs but ignores them after that to ensure that all of the data MLA uses is in a consistent state.

I hope the above explanation make sense and answers your questions. I appreciate your engagement on this topic.

Thanks for your elaborate reply and explanation.
I would like to zoom in on the MIME type definitions that MLA picks up.
And especially the Custom definitions. How are these set? Apparently not by using the WP created upload_mimes filter?
So can you perhaps describe how someone (like me) can add to those custom types so that addition will be picked up by MLA?

You asked “How are these set?“

In the Settings/Media Library Assistant admin screen you will find two tabs, “Views” and “Uploads”. These tabs are the MLA user interface for defining and using MIME types.

The Uploads tab handles “File Extension and MIME Type Processing”. There is a table of all the MIME type/file extension associations with several views to filter it, bulk actions and rollover actions. There’s also a form you can use to define new types and associations. At the bottom of the form is a “Search Known Types” button that leads to a complete database of all type and file associations I know of. The “File Extension and MIME Type Processing” section of the Documentation tab explains how it all works.

The Views tab handles “Library Views/Post MIME Type Processing”. Post MIME Types are a WordPress construct used to define views for the Media/Library and Media/Assistant screens. MLA extends this construct to provide “Table Views” you can use to filter the Media/Assistant submenu table with custom field queries. The “Library Views/Post MIME Type Processing” section of the Documentation tab has more information.

In the current MLA version these two Settings tabs are the only way to manage MIME types; there are no hooks or API functions to do it from code. Of course, you can disable either or both of these MLA features if they don’t apply to your application. Just scroll to the bottom of the tab and uncheck the “Enable” box.

I hope that makes sense. Let me know how the user interface or documentation might be improved. Thanks for your continued interest in the topic.

Thanks again for answering.
I probably didn’t pose my question right.
What you describe in your answer are the MLA settings I know of. For me those belong to category 2: MLA additional definitions.

What do you mean by the definitions in category 3: Custom definitions?

Ah, let me try to clarify. MLA settings are those supplied by code and templates I have coded in the plugin. Custom definitions are anything you, the user, add by using the forms in the user interface and clicking “Add Upload MIME Type” or “Add View”. That’s all there is to it. Does that make sense?

Yes that makes sense.

Not to be nit-picky but the list should have been:
MLA distinguishes three categories of MIME type definitions:

• WordPress core definitions
• MLA additional definitions
• MLA custom user definitions

And what about other plug-ins that do something with the mime types?
Not that I use any of them (apart from MLA and Enhanced Media Library):
WP plugins for mime Will those still work?

As I wrote in my first post:

The current MLA version does a one-time processing of registered MIME types when it is first loaded, captures everything at that point, then takes over from there. It does not go back to the upload_mimes filter on subsequent page loads.

Any other plugin that is active when MLA does its first scan will “contribute” additional MIME types to the initial list. After that, any further changes made in other plugins are ignored. Changes from other plugins will “still work” in the sense that MLA will supply equivalent changes.