Upload by media category

[KTS915]

This PR follows PR #1403 and provides an additional option to upload a file according to media category:

If no media category has yet been created, the option is disabled with a message explaining that one needs to be created (together with a hyperlink to the place to do so):

Once that's done, a new dropdown will appear on the Add Media page, which will look like one of the following according to which uploader the user has chosen:

However, until the user has chosen a category in the dropdown, the uploader will be disabled (i.e. it will have the inert attribute applied to it). Once a category is chosen, this fires some JS to a new action at admin-ajax.php, which then registers the media category as the file destination and removes the inert attribute from the uploader, so that it can then function as normal.

When the file is uploaded to the media category folder, it will also automatically be added the media category within the admin, as will be shown by going to the List view of the media library.

[mattyrob]

I have been testing with a Media category called media and in Safari I have managed to upload files without a Media category selected and I've also noted that the files have uploaded to wp-content/uploads/ when I suspect it should have been wp-content/uploads/media/ - am I wrong?

When 'year' is selected the image is correctly added to wp-content/uploads/2024/.

[KTS915]

It looks like the sanitizing method I've used is causing this (on line 3884 of ~/wp-admin/includes/media.php ). I used sanitize_url to sanitize the option to set the correct subfolder. I used that because the value is appended to a URL, but it seems it then gets prepended with http:// or https:// in many cases.

Unfortunately sanitize_option and sanitize_key also won't work, because the strings being sanitized may contain a /. So what's the correct sanitization method here? Or is it OK not to use any?

[KTS915]

Hmm, sanitize_text_field seems to work. What do you think?

[KTS915]

I think sanitize_text_field is too permissive. However, after trying a few things, I think that sanitize_url is the correct sanitization method. I just need to ensure that the value being sanitized is prepended with /. Then it is seen as the relative URL that it is and everything works as intended. This means that I then need to remove that / from the place where it's currently added in the ~/wp-includes/functions.php file. New commit incoming!

And thanks for checking and spotting this!

[mattyrob]

Works are described now - the only irritation for me is in the standard media uploader, if no category is selected and am image is dragged and dropped, it results in the browser loading the image into the window. I doubt there is much that can do about that unless the code can intercept the upload but prevent it when no category is selected.

[KTS915]

I'll look further into that later today.

[KTS915]

Latest commit should address the problem of loading the image into the browser window when uploading is disabled. It turns out that there's no need to intercept the plupload script but just need to make use of the vanilla JavaScript API.

[xxsimoxx]

Usually I upload images directly dropping to the Media Library, and not from the "Add New".
From here I can't decide the category, and I get the image uploaded under the first category slug, and no category added.

[KTS915]

Thanks to a MutationObserver, the current status of this PR is that this should now be working as expected, except in the following case.

If someone goes to add a file from a post, page, or text widget, then uploads the file but then does not insert it into the post, page, or widget, and then uploads a new file, any attempt to change the location for this new file will not work.

What happens is that any attempt to select a new location is sent to and stored in the database, but the failure to insert the first file seems to mess up the modal itself; it continues to operate as if the location for the first file must be the correct location.

If the first file is actually inserted into the post, page, or widget, everything works as intended. It also works if the page is saved or refreshed after the abortive first upload.

So this is a bit of an edge case, and the fix is probably going to be hard to find, but it's where we are now.

[KTS915]

@mattyrob @xxsimoxx With my latest commit, I think I've solved this now!

[xxsimoxx]

Still getting similar errors, sometime the category is not added, sometime it's added the one that is the default for the dropdown.

[KTS915]

That's disappointing! But thanks as always for checking, @xxsimoxx. Backbone.js is a black box that's hard to penetrate.

I'm going to put this on the back-burner for now and come back to it again later.

[KTS915]

With my latest commits, I think this should work now! (I certainly hope so!)

[xxsimoxx]

I'm already not getting the category assigned. Seem that this happens when I leave the dropdown unchanged.
Also (but don't know if this issue is related to this PR) I'm getting, in the Categories page, a wrong count.