Contrib.social

Remove file field uri_schema $has_data lock

Open on Drupal.org →
Created on 9 February 2012, over 13 years ago
Updated 26 May 2025, 4 months 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.

  • Comment 4 months ago →
    🇮🇳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.

  • Comment 4 months ago →
    🇮🇳India mohit_aghera Rajkot
  • Comment about 2 months ago →
    🇦🇺Australia mstrelan

    I 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 about 2 months ago →
    🇦🇺Australia mstrelan

    It 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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024