Customization 'accept' attribute values of file input in upload widget.

Comments

14 comments

  • Avatar
    Aditi Madan

    Hi Andrei,

    You can use the `clientAllowedFormats` option in the upload widget and specify the video formats and that way it will only let the user upload video files. If you try and invoke the widget through input element it will eventually open the widget disregarding the accept parameter and the button element does not support accept type. You can either use resourceType or clientAllowedFormats.

    Regards,

    Aditi

     

    0
    Comment actions Permalink
  • Avatar
    Andrei

    Aditi, thanks for your suggestion.
    We're using `resourceType` video when configuring the upload widget and I was trying the `clientAllowedFormats` option as well. It is limiting uploading however it is used by API for validation.

    It would be nice to have an option to control the `accept` option on file input. In addition to the existing options for Look and feel customization it would improve UX.
    Any chance of having an additional parameter for this purpose in the future?

    As an example, such parameter could support a comma-separated list of allowed file extensions or MIME types and be directly bind to input (Browse button)

    0
    Comment actions Permalink
  • Avatar
    Aditi Madan

    Hi Andrei,

    I will raise a feature request with our product team to consider adding this in the future. As of now, we have the options that I shared earlier with you.

    Regards,
    Aditi

    1
    Comment actions Permalink
  • Avatar
    Ed

    Has there been any progress on this? Seems basic to improve the UX of the this section

    0
    Comment actions Permalink
  • Avatar
    Eyal Katz Talmon

    Hey Ed! Thanks for reaching out.

    The feature request is still being considered and prioritized against other tasks, and therefore, unfortunately, there wasn't any progress made so far. We'll update this thread about any progress made in the future.

    Regards,

    Eyal

    1
    Comment actions Permalink
  • Avatar
    Ed

    Just adding to this. Is there any way I could get access to the input from a query selector? So far it seems not possible due to the iframe being from a different origin. Or is there a way to get the widget codebase so I can make the changes myself?

    0
    Comment actions Permalink
  • Avatar
    Michal Kuperman

    Hi Ed,

    Currently, there is no option to access the input from a query selector or to get the widget codebase. 

    Let us know if you need any further assistance.

    0
    Comment actions Permalink
  • Avatar
    Aditi Madan

    Hi Andrei and Ed,

    I just wanted to let you know that this issue is fixed now. You should be able to use the `accept` attribute with the upload widget.

    Please test and let me know if you have any questions.

    Regards,

    Aditi

    1
    Comment actions Permalink
  • Avatar
    Kirill

    Hi Aditi,

    Could you elaborate on where we can use the `accept` attribute?

    Moreover, in accordance to docs(and your answer above), we can use `clientAllowedFormats`
    Here is the description:

    Allows client-side validation of the uploaded files based on their file extensions. You can specify one or more file extensions, and/or limit the allowed files to "videos" or "images".
    Note: As a shortcut, you can use a string to pass a single value (e.g. "gif")
    Default: null.
    Example: ["webp", "gif", "videos"]

    But when

    ['image/*', 'video/*']

    or 

    ['images', 'videos']
    <input type="file" name="file" class="cloudinary_fileupload" accept=".image/*,.video/*" tabindex="-1" multiple="multiple">

    As you can see somewhere internally a dot is added to all array elements. It is confusing.
    In order to specify all images/videos, we have to define all formats.

    Could you help with that?

    0
    Comment actions Permalink
  • Avatar
    Eyal Katz Talmon

    Hey Kirill, thanks for reaching out!

    It seems that the syntax mentioned in the documentation is incorrect here.
    The correct syntax is using singular notation -

    clientAllowedFormats: ['image', 'video']

    This generates the following accept attribute for the input element -

    accept="image/*,video/*"

    I'll create an internal ticket for the documentation team to fix this section.

    Hope this helps!

    0
    Comment actions Permalink
  • Avatar
    Kirill

    Thank you Eyal Katz Talmon!

    What about `audio`? I've tried 

    clientAllowedFormats: ['image', 'video', 'audio', 'raw']

    Output is 

    accept="image/*,video/*,.audio,raw/*"
    0
    Comment actions Permalink
  • Avatar
    Stephen Doyle

    Hi Kirill,

    In our feature set, audio files are considered "videos" for the purposes of identifying which transformation options can be used with them, and this parameter is parsed based on our resource type values of 'image', 'video', 'raw'.

    I can see that doesn't match what you need here, which is for the 'accept' property to include an audio/* MIME type.

    It may be possible for us to add a special 'audio' option here or to also add audio/* when the 'video' value is provided and I've created a task for our widgets team for that.

    In the short term for audio files I think the best workaround is to list the specific formats via their file extensions (e.g. aac, mp3, wav, etc)

    Thanks,

    Stephen

    0
    Comment actions Permalink
  • Avatar
    Kirill

    Hi Stephen,

    Thank you for your response.

    A special 'audio' option here seems to be the best option. Since as a user, I want to control what exact types input can accept(maybe just audio).

    Anyway, thank you!

    Kirill

    0
    Comment actions Permalink
  • Avatar
    Stephen Doyle

    Hi Kirill,

    I've linked the task I created for the widget team with this forum thread, so we can let you know if any changes are made to address this, and in the short term I think listing the specific audio formats you want to support should represent a workaround for most cases

    Regards,

    Stephen

    0
    Comment actions Permalink

Please sign in to leave a comment.