Remove file field uri_schema $has_data lock

Created on 9 February 2012, over 13 years ago
Updated 26 May 2025, 19 days ago

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;

  1. Why does the file field have this and the image field doesn't?
  2. 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:

  1. 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.
Feature request
Status

Needs work

Version

11.0 🔥

Component

file.module

Created by

🇦🇺Australia alan d.

Live updates comments and jobs are added and updated live.
  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇮🇳India mohit_aghera Rajkot

    Hi @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#disabled attribute 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.

Production build 0.71.5 2024