Support for a Field HTML input attribute "readonly" state

Created on 9 November 2023, about 1 year ago
Updated 29 April 2024, 7 months ago

Problem/Motivation

We have a content type that has fields that use conditional fields dependencies. Several fields are set to disabled when they meet a condition. If we edit that content type with some disabled fields, data for the date range and taxonomy term fields are lost on save. This does not happen with all field types but it does happen with date range and taxonomy term fields. From what I can tell, a disabled field gets the disabled attribute added to the field form inputs. In HTML, if an input has the disabled attribute, the data for that input is not sent over on form submission. Drupal must be handling the save of the form inputs differently depending on the field type.

Steps to reproduce

  1. Edit content type that has the following field types: text, date range and taxonomy term.
  2. Add some data to those field.
  3. Add Conditional Fields dependencies that sets the state for those 3 fields to Disabled.
  4. After the content type has data and those fields are set disabled, edit it again and click save
  5. Notice that the data for the text field type persists but the data for date range and taxonomy term is lost.

Proposed resolution

To have fields to be not editable data persisting on form submission (i.e. be passed over on form submission), a readonly state option would accomplish this. The field would be not editable but the data would not be lost on save.

✨ Feature request
Status

Needs review

Version

4.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States coledev

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @coledev
  • πŸ‡ΊπŸ‡ΈUnited States coledev
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update about 1 year ago
    130 pass
  • @coledev opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States coledev
  • Status changed to Postponed: needs info 9 months ago
  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    Thanks for the report and all the efforts in here.

    I have to decrease the issue priority. Descriptions of the Priority β†’ and Status β†’ values can be found in the Drupal project issues β†’ documentation.

    Interesting issue. I think if this is a global issue in the scope of this project, then it is not for Date and Term fields only. Change the title accordingly. Apart from that the provided solution is not implementable this way because it a) fills very individual needs and b) is not the same as being really disabled. This should be called another state then and would need changes in the UI and form texts.

    Please elaboate on if fields which are disabled are ALL losing its content and if this also happens in other scenarios out of Conditional fields. If that' the case - and I think so it is - then this is rather an issue for core "how to deal with content of disabled fields". But again, the other option would be to implement a new status feature maybe called like "Appear like disabled/frozen (no editing possible)" or something.

    But again, that are two different issues and we need to decide which issue we want to handle here.

  • Issue was unassigned.
  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin
  • Status changed to Needs work 8 months ago
  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    Side note: Date range is no core field. And disabled and readonly are two different HTML input behaviors. There is a readonly state attribute for HTML input fields doing exactly what you want, so you can REALLY make the field readonly without acting as disabled, not only simulate it with CSS. This part is missing in the patch.

    Apart from that: The solution provided in this issue here is a great idea and actually should be a feature request since it implements an interesting new feature (originally as a work-around created by issue reporter but actually a great idea for a new feature). So let me sort the issues out and convert this issue here into a feature request with your patch as starting point. It also a great temporary work-around for the issue with dependency settings getting lost when a from field widget gets disabled under manage form display, like tracked in this issue: πŸ“Œ Refactor the concept of how dependency settings are assigned to fields and entity bundles Active

    Thanks for the report and hard work in here. Changed issue summary and title/scope accordingly.

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin
  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    In fact I see now there is already a starting point @todo placed in the code of src/Conditions.php

      // @todo Add support to these states:
          /*
          'relevant'   => $this->t('Relevant'),
          '!relevant'  => $this->t('Irrelevant'),
          'valid'      => $this->t('Valid'),
          '!valid'     => $this->t('Invalid'),
          'touched'    => $this->t('Touched'),
          '!touched'   => $this->t('Untouched'),
          '!readonly'  => $this->t('Read/Write'),
          'readonly'   => $this->t('Read Only'),
          */
    
  • First commit to issue fork.
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 7 months ago
    130 pass
  • Status changed to Needs review 7 months ago
  • πŸ‡ΊπŸ‡ΈUnited States bernardm28 Tennessee


    This should be ready to be reviewed.
    I tested it with DrupalPod 10.1.x and the standard theme.

Production build 0.71.5 2024