Webp, gif and svg formats allowed as attachment of a review + prevent unsupported format upload

Hello,

webp, gif and svg formats are regular web image extensions.

Please allow uploading these

and avoid upload of a image if its name does not have valid extension. I think that currently file is uploaded (and disacrded?) even when the file extension is not supported by the HivePress.

Hi,

Thanks for the suggestion, we will consider adding this feature in future updates.

In the meantime, we can provide a snippet that allows uploading these file formats. Please also note that SVG files are restricted on the WordPress level by default, since they are generally treated as a potential security concern.

Regarding preventing image uploads when the file extension is not supported, could you please let us know if this issue occurs only on mobile devices or on desktop as well? I’ve tested this locally on the desktop version, and unsupported file types are greyed out automatically, so they cannot be selected.

we can provide a snippet that allows uploading these file formats

yes, if you can provide it, please go ahead, i will try it

if this issue occurs only on mobile devices or on desktop as well?

on the desktop (Firefox) it works correct (i can not select unsupported file), but on mobile (Firefox Focus browser on Android), it allowed to select non supported file (mp4?) and was uploading it (wasting data transfer) and then returned message showing supported image formats.

Please use the following snippet and add the desired formats:

add_filter(
'hivepress/v1/models/review',
	function( $model ) {
		$model['fields']['attachment']['formats'][] = 'webp'; 
		return $model;
	},
	1000
);

It seems that the issue may be happening on the Android/browser level. If the same behavior does not occur in another browser or on a different device, then the problem is most likely related to the specific device or browser being used for testing.

The important part is that even if the file can be selected on the frontend, it should still not actually upload successfully, the backend validation should reject it and return an error message accordingly.

Thank you, webp started working.
After I wanted to allow multiple extensions, your AI was again helpful to provide working snippet:

add_filter(
	'hivepress/v1/models/review',
	function( $model ) {
		$model['fields']['attachment']['formats'] = array_merge(
			$model['fields']['attachment']['formats'],
			['gif', 'webp', 'webm', 'mp4']
		);
		return $model;
	},
	1000
);

Regarding upload of a non-allowed file extension on a mobile with Android:

In Brave it does not allow me to select non-allowed extension. Good.
In Firefox Focus it allows me to select non-allowed extension and I can see the network activity started when i attach the non-allowed image. It does not appear on Media tab in admin area, but apparently still wastes data transfer, which is wrong and suggests that you have a bug in your code which allow certain web clients to bypass the restrictions. Do you have it in your internal bug tracker, consider if you can add it.

Also I think that you have unhandled issue with the file size. When i have selected 22MB large mp4 file, it was uploading it, but then not attached a preview to the review form and shown no message. Submitting the form does not add anything to the WP Media files. The size should be limited and if hosting limit is reached a warning displayed, if it is not possible to calculate file size without uploading it (wasting data transfer if the file is over maximum allowed file size).

Thanks for the feedback, we’ll take a closer look.

At the moment we are using the standard HTML accept attribute for the file input: <input type="file"> HTML attribute value - HTML | MDN. File selection behavior is therefore largely browser-dependent, as it depends on whether the browser correctly respects the accept attribute. It’s possible that some specific browsers handle this differently or require a non-standard approach.

In any case, backend validation will still be applied, even if a user manages to select an unsupported file type, it will be rejected on the server side.

Regarding file size, there is nothing specific implemented in HivePress for this, since we rely on the native WordPress function media_handle_upload() (media_handle_upload() – Function | Developer.WordPress.org). File size limits are enforced at the WordPress/server level, so please make sure those limits are correctly configured on your hosting environment.

The point is that your script still allows client to waste servers bandwidth by uploading file even it has unsupported extension. And i suppose that this can be prevented, so i repeat: “Do you have it in your internal bug tracker, consider if you can add it.”

You can not validate the file upload instead of silently failing (current state) due to a higher file size than allowed by server, not giving feedback to user? I have described the issue in my 2nd paragraph in previous post. I think that this is also worth fixing on your end.

Thanks for reporting the issue — just to clarify, this is a browser-side limitation. The only way to restrict selectable files is via the HTML accept attribute, which we already provide correctly.

Most browsers respect it, but Firefox Focus appears to ignore it, and browsers do not provide any other API to enforce file filtering during selection.

We still validate file types on the backend, so unsupported files are rejected (though this may result in some unnecessary bandwidth usage), but as noted, there’s no other API available to make Firefox Focus filter files during selection (as it is a privacy-focused browser), so unfortunaly this is not something that can be fixed on HivePress side.

@ihor You have not addressed the file size concern mentioned in my previous message in its second paragraph and in my message which is before it, in its last paragraph. I am saying this in case you have missed it.

Please refer to Kseniia’s clarification, while we’ll consider implementing extra checks on the browser side if the API allows this, currently we rely on the WordPress core uploader that enforces the file size restriction on the server side.