Problem/Motivation

When creating a media type that relies on a filefield, such as Image, the standalone form, such as /media/add/image, uses the filefield widget, with any configuration done for that widget on the default form mode.

However, when creating the same media type via the media library modal, any configuration done for the filefield widget on the media_library form mode is ignored because the modal hardcodes use of a `managed_file` form element.

No form fields added to the media_library form mode are shown either!

This breaks contrib modules such as Filefield Sources: #3213873: Doesn't seem to work in media library

Quite possibly using a normal form mode will also fix #3477339: Media library widget FileUploadForm incorrectly creates multiple media entities if the media file field has multiplicity !=1

Steps to reproduce

Create a new field (say, text field Credit) on media Image, and add it to both the default form mode and the media_library form mode. Add a mediareference to a content type, say article.

Create an image through /media/add/image and see your text field.

Create an article through /node/add/article and press the add media/image button for that field and create an image through the media library modal and you do not see your text field.

Proposed resolution

Use the configurable filefield form widget instead of the hardcoded managed file element.

Remaining tasks

Check if any of the decisions that went into using the hardcoded element still apply: #2938116: Allow media to be uploaded with the Media Library field widget

User interface changes

The label for the file upload field will change from "Add file" to "Add a new file", the wrapper of the file upload field will say "Image", and possibly other minor cosmetic changes if we do not re-theme, but ultimately the modal and the standalone form should end up with styling consistent with one another.

Introduced terminology

None.

API changes

None?

Data model changes

None.

Release notes snippet

Issue fork drupal-3581690

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mlncn created an issue. See original summary.

captainjak made their first commit to this issue’s fork.

mlncn’s picture

mlncn commented
Issue tags: +Chicago2026

Phenaproxima points out that the reason for the hard-coding is to ensure that there is always the initial media source field (and nothing else), and the media_library form mode used for editing after this initial creation.

The danger of using a form mode is that people could remove the necessary source field.

This applies to *any* content edit form, though, that removing a critical field from the form mode could mess things up, so i still think that converting to a form mode and all the consistency and flexibility (and removing code for hard-coded form elements) is a worthwhile benefit. Alternatively the hard-coded form could be used until a form mode is assigned to override it; this would be a net addition of code but would protect from new file-based media types having invalid (or over-many fields) modal add forms. Validation code identifying the source field and ensuring that it exists on the special view mode, and removing the hard-coded view mode, would likely be not that difficult and the best option.