Denying upload_files cap makes Customizer and Media modal act oddly

[Otto42]

This is an unusual one, so labeling it as an enhancement rather than a bug. Somebody more familiar with the Customizer classes and Media modal might know the right way to handle this properly.

If you disable the upload_files capability, with the intent of not allowing file uploads by anybody (duh), then the customizer acts very odd in the assorted image-related controls.

Example code:

add_filter('user_has_cap', 'no_file_uploads');
function no_file_uploads( $caps ) {
	$caps['upload_files'] = false;
	return $caps;
}

The "Header Image" section still has an "Add New Image" button, which gives you the Media Library popup, with a spinner that never stops spinning. Also, the Upload Files tab still exist.

The "Background Image" section has a Select Image button, with the same broken Media Library popup as the other one.

Expected behavior: Media chooser that works, no Upload Files tab.

This may be an issue both with the Customizer showing incorrect buttons, or which more properly belongs to the Media modal in that it should still be possible to select an image even if you cannot upload one.

Alternatively, disabling upload_files in this way may be the wrong way to do it, although it is the most obvious approach.

[wonderboymusic]

The query for attachments requires the cap, so I view the endless spinner as a bug. Incoming patch will hide buttons when the user doesn't have the cap. The second portion, making the modal readable, will be tricky.

[wonderboymusic]

In 32913:

The query-attachments AJAX action immediately errors out if the user doesn't have the upload_files cap. As such, the Customizer shouldn't show buttons that launch the media modal when the user doesn't have the proper permissions to query attachments.

See #32654.

[wonderboymusic]

This is going to require some surgery

[SergeyBiryukov]

Related: #19817, #19834, #28327.