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
Comment | File | Size | Author |
---|---|---|---|
#4 | public_private_media_storage.png | 110.04 KB | xjm |
Comments
Comment #2
Wim LeersI disagree. This is a
FieldStorageConfig
setting. Storage cannot be changed after creation, because then all existing field instances would no longer work.Comment #3
xjmSo, 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.
Comment #4
xjm@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.
Comment #5
xjmLet's postpone this on #2894270: Users unable to add an extension to the file upload field for now.
Comment #6
Berdir> 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.
Comment #7
xjmPosted #2895124: Field storage settings give a scary red warning that they can't be changed when the cardinality is the only thing with restrictions for the storage settings UX issue.
Comment #8
Wim Leers#2894270: Users unable to add an extension to the file upload field landed!
However, I think it's probably best to first discuss a direction to take in #2895879: Discuss (and agree upon) method(s) for preventing certain Media Source field settings from being changed?
Comment #9
seanBCan we close this and move on in the follow ups? This is technically fixed now.
Comment #10
Wim LeersOh, HAH! Good point :)
Comment #11
xjmYep, let's mark it as a duplicate. Thanks!