Problem/Motivation

When adding the media module to core, it was decided that source field should be locked. This was done because we don't want them to be deleted, and in some cases they also shouldn't be changed (the brightcove media source uses an entity reference as source field where a specific entity bundle should be selected).

The problem is, locking the source field also removed our ability to change the private/public file settings for "File" and "Image" fields.

Proposed resolution

There are several other issues on the locked field topic:
#806102: Locked fields can change the widget but not settings
#2274433: Do not allow to alter Locked field via UI
#2289551: Clarify what 'locked' means for a config entity and whether it's okay for code to rely on a locked config entity existing
#2894270: Users unable to add an extension to the file upload field

Discuss what field settings/operations should and should not be locked and how to best solve this.

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#4 public_private_media_storage.png110.04 KBxjm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

seanB created an issue. See original summary.

Wim Leers’s picture

I disagree. This is a FieldStorageConfig setting. Storage cannot be changed after creation, because then all existing field instances would no longer work.

xjm’s picture

So, the place where you can configure this is:
admin/structure/media/manage/file/fields/media.file.field_media_file/storage

That's not exactly discoverable, but it is possible. The limitation is that once you have any data in any file media field on the site, anywhere, you're restricted to using the storage that you used for the first field. This is different from core files, where you can choose this each time on a per-field basis.

To clarify what I think @Wim Leers is getting at, it's not because of the field being locked. It's because of the fact that it's a field storage setting, and with entity reference and a default file field, that means you have to use the same storage across all things that use media files, site-wide.

The workaround is to create additional Media types -- like a "Private file" media type -- and use that instead when you want private storage.

xjm’s picture

Issue summary: View changes
FileSize
110.04 KB

@seanB and I looked at this some more, and turns out, the message on the storage settings about not being able to change it is a big fat lie (for any field, not just media entity reference fields). This caused #1266748: Changing cardinality lower than highest existing delta causes data loss upon save, which was fixed and now provides "smart" validation to prevent you from causing data loss by changing the cardinality below the maximum number of values in a given field.

So, you can swap between public and private storage to your heart's content on any file, image, or media field, if you ignore the message telling you it's not possible.

The difference for Media here is that the locking removes the operation dropdown button, but not the link to the field storage settings. Which is also a different bug:

And, of course, as above, the public vs. private storage is shared site-wide instead of per field, unless you create another media type to reference. But, since you can create another media type to reference, that's a workaround to all these problems, so I don't think this one is a must-have, even if the storage settings were working as advertised and the locking were properly preventing the storage settings from being changed.

For now, I'm going to move this into "Should have" on the roadmap. If we solve #2894270: Users unable to add an extension to the file upload field (which has no workaround or bugs enabling it) by removing the field locking, the UI inconsistency also goes away.

xjm’s picture

Status: Active » Postponed
Berdir’s picture

> I disagree. This is a FieldStorageConfig setting. Storage cannot be changed after creation, because then all existing field instances would no longer work.

Plently of storage settings are changeable, as long as they don't break existing data or require schema changes. It's up to each field type to decide what is allowed, list fields for example allow to add new and remove unused options but not remove options that are in use.

There is really no reason that the default location for files can't be changed, it's just a default for new files, there is no validation or anything, you can for example easily add files from different places through an entity_browser based widget.

But that's a different problem that should have its own issue.

xjm’s picture

seanB’s picture

Can we close this and move on in the follow ups? This is technically fixed now.

Wim Leers’s picture

Status: Postponed » Closed (outdated)

Oh, HAH! Good point :)

xjm’s picture

Status: Closed (outdated) » Closed (duplicate)

Yep, let's mark it as a duplicate. Thanks!