Skip to content

Rethink allowedType parameter in media-upload functions/components #7155

@mirka

Description

@mirka

I'm proposing two changes to the allowedType parameter used in the functions/components related to media uploading:

  1. Rename allowedType to accept
  2. Mimic the syntax rules for the accept attribute in an <input type="file">

I think this would result in less confusion in our codebase, and more flexibility/clarity for third-parties who are going to use these components.

Context

As we expand the scope of file uploads to filetypes beyond image/audio/video, I'm finding some problems with the allowedType parameter as it stands.

  1. The name sort of conflicts with WP's get_allowed_mime_types(), which is what we're planning to use for checking allowed types before uploading (Check allowed mime types before uploading media #6968).

    Note that the WP-side allowed_mime_types is the list of all types that the current WP user can upload, which is dependent on the site. In contrast, Gutenberg-side allowedType is being used for restricting a component to only accept a certain type, like "image" for Image blocks.

    For example, an SVG file would pass a Gutenberg-side allowedType="image", but it might be rejected against the WP-side allowed_mime_types if SVGs are not allowed. In any case, they each serve a different purpose and warrant different behaviors/errors when rejected, so we can't merge these two checks together. We should rename our allowedType so it won't be confused with the WP-side allowed_mime_types.

  2. The syntax to be used for allowedTypes is not immediately apparent. Since its purpose is very similar to the accept attribute in an <input type="file">, we could just rename allowedTypes to accept and mimic that syntax.

Relevant functions/components

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Feature] MediaAnything that impacts the experience of managing media[Type] QuestionQuestions about the design or development of the editor.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions