The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When there is data in the image field, upload destination is changeable.
This may cause issues to site builder and editor when they accidentally change the upload destination.
Check following screenshot.
Steps to reproduce
- Add file and image field to article content type.
- Create one article content and upload image and files.
- Visit "admin/structure/types/article" and open the field settings form.
- Notice that "Upload destination" is disabled for the file field and it is not disabled for the image field.
Proposed resolution
- Upload destination should be disabled for image field when there is data in the field.
Remaining tasks
- Needs discussion with sub-system maintainer.
- Approval about the approach
User interface changes
N/A
Introduced terminology
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Original report by @alan d.
I've just gone through and edited about 50 image fields, changing these from a shared URL (see foot note) back to public. After changing the schema, I ran a quick test on one of the image fields. While this worked fine, it was not what I would consider careful complete testing.
Then I was about to do the same on all of the file fields until I discovered that these have a $has_data lock.
So my questions are;
- Why does the file field have this and the image field doesn't?
- Could the same issue apply to the image field?
Since these fields share the same base functionality, I would consider that either there is a bug changing this after the field is populated (ie: the reason for the lock) or that this is simply an oversight from a cut 'n paste when creating the field. Love some feedback, I'm about to parse the repository logs to see if I can find the commit that introduced this.
Note:
- This was a custom file schema created to allow multiple sites to all shared the same file directory that was hosted on another domain / outside of each sites web root. We switched from a multisite like set-up to domain access when we found out that almost 98% content was going to be shared in some form due to the requirements of two of these sites.
Comments
Comment #1
alan d. commentedThis was added in #367013: Field update (field_update_field).
Comment #2
alan d. commentedRunning a D7 patch to see if it detects any issues (i'm guessing there are no test for this though).
Comment #4
alan d. commentedD8 re-roll with check removed and a couple of basic file tests added.
Comment #5
alan d. commentedContrib appears to have some bugs related to changing file schema type. So i think that it should be either:
schema is decided via the field settings
schema is decided via the file as it was uploaded (field settings) then the file_managed.uri
So at the moment, we have both. Which way does the core team want to take?
Comment #8
alansaviolobo commentedComment #9
drupradPatch re-rolled for comment #4
Comment #11
alan d. commented@pksingh1987
?
Comment #12
drupradCorrect patch re-rolled for comment #4
Please ignore comment #9
Comment #13
drupradComment #16
drupradUpdated patch re-rolled for comment #4
Comment #17
alan d. commented@pradeep.singh
You are inserting a lot of Drupal 7 code into these patches! See https://www.drupal.org/node/2064123.
Comment #31
mohit_aghera commentedHi @alan d
Thanks for raising the issue.
This seems to have carried over from Drupal 7.
Even on Drupal 11.x ImageItem plugin doesn't have the
'#disabled' => $has_data(core/modules/image/src/Plugin/Field/FieldType/ImageItem.php line 200 or so)File field settings form when field has data:
Image field settings form when field has data:
I believe this might have missed while porting to D8+.
Decide whether we should keep or not:
- I believe we should keep the
#disabledattribute if image field has data.If we consider the following scenario:
- In initial phase we mark image field as public file field.
- Upload a few files.
- Later change this field as private
- Expectation to editors will be they all the existing files are private however they are not.
So essentially if field has data then this option should be disabled.
I am tagging sub system maintainer review.
Comment #32
mohit_aghera commentedComment #33
mstrelan commentedI don't necessarily agree with #31. Most of the time editors are not aware of the difference of public / private. Therefore it should be up to site builders to determine how to communicate this.
We have a use case for converting a file field on a media bundle to use private, to allow for an editorial workflow. The expectation is that files attached to draft and archived media entities should not be accessible to anonymous users. We already have existing files in public, and we can either choose to move them all to private, or leave them as they are and only use private file system for new files. We could even implement a presave hook that moves files to the private file system when the media entity is archived.
Comment #34
mstrelan commentedIt seems the $has_data lock was added to the uri_scheme in comment #17 of #367013-17: Field update (field_update_field) with no discussion as to why. Here's the commit db09a617. The intent of that issue was to prevent changes to fields that would introduce schema changes, but there is no schema change here.