Not able to add to List (text) field with "0" as the first machine name.

I think this may be previously reported but I haven’t searched in detail.

I have search a bunch. Any suggestion on what to be looking for? Am I using the wrong terminology?

I definitely remember issues concerning 0 values in past. They could be different than this one.

I got the same problem. My site actual is a new site set up at core version 10.1.x. At that time the problem wasn't there. It first accrued after updating to 10.2.x. The problem might be related somehow to https://www.drupal.org/project/drupal/issues/3411419 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed ?

RE https://www.drupal.org/project/drupal/issues/3411419 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed , this has been committed and seems to be present in release 10.2.3, which I just updated to, but this issue still persists for me.

I tried the patch from MR in #10 on Drupal 10.2.3, but no luck in my case.

I have a list field with the first option having machine name "0" which I can't update anymore due to this issue.

Likewise #8 the issue seems to still exists:

I have a Drupal site with text list fields which have a machine names 0, 1, ...

On Drupal 10.1.8 they are valid and editable, with 10.2.3 I get ""Value field is required.".

I'm seeing this issue as well. It only started with Drupal 10.2. Previous versions do not experience this error. It's happening on sites that were upgraded to Drupal 10.2 as well as new installs of Drupal 10.2.

I'm also experiencing the error if you reuse the list field on another entity type e.g. if you have the field on one paragraph type and then try to reuse the field on another paragraph type. It is worth noting that the field is added to the second paragraph type even though the error is displayed. But you cannot add additional values to the list.

Note: I have seen this error for both List (text) fields with the machine name of the text string '0' as well as List (integer) fields with the machine name of the number 0.

10.2.6
Still have issue.

I have the same issue. I have a list field and the first option has a machine name "0" and I can't update the field at all. I need to add a default value for the field but because I can't save it without "Value field is required" I can't update the default. This bug renders the field un-editable.

I'm encountering this issue as well on 10.2.6
The value field remains disabled, displaying a 0 value.

The list field i'm working on requires new field options and i'm currently unable to do that and not sure what to do.

I am not able to replicate this on 11.x.

I have an update with a work around. You can ethier remove the field and recreate it adding the new items to your list and keeping the machine names with their boolean values, keep in mind you'd need to do this for every instance you'd need to add a new item. If you have a time constraint and you need to make a quick change without mucking up the code this works.

-however-

It's best to recreate the list using a meaningful string of text for the machine name indicating the items action. The you'd never have to worry about the boolean value of 0 impacting future updates to your list.

These solutions will work but keep in mind if you plan to use boolean values refrain from using 0 as it equals null and that can cause breakage in this case. Hope this helps!

While using a value of "0" in a list (text) field is perhaps ill-advised, it should be possible, and it should definitely be possible to use a value of 0 in a list (integer) field. But that produces the same error.

I guess something is testing whether there's a value using empty() when really it should be calling isset() or a strict equals.

Re-titling to reflect the more general problem. Fortunately I found this before pushing the new field to production.

On the commit from #8, I got it working by changing:

```
return $element['#default_value'] ? (string) $element['#default_value'] : NULL;
```

To

```
return isset($element['#default_value']) && is_scalar($element['#default_value']) ? (string) $element['#default_value'] : NULL;
```

Its an odd situation, the main issue comes from the core\lib\Drupal\Core\Form\FormBuilder

```
// Final catch. If we haven't set a value yet, use the explicit default
// value. Avoid image buttons (which come with garbage value), so we
// only get value for the button actually clicked.
if (!isset($element['#value']) && empty($element['#has_garbage_value'])) {
$element['#value'] = $element['#default_value'] ?? '';
}
```

Where default_value is interpreted as a integer. Probably a better solution somewhere else to make sure default_value is cast as a string? Didnt have more time to look into this.

I encounted this same problem with Drupal core 10.2.7.

We have an existing List (text) type field which has been used to select a VAT value. The values stored there have been 0, 10, 14 and 24 to correspond with the Finnish VAT values. I was trying to add a new value there to take into account a new allowed value in Finland. Now I noticed that with the new list UI I am not able to store the value 0 anymore. The value gives a validation error that the field is required because the value 0 is most likely interpreted as an empty value.

The key itself has been working fine for us and in our case it would be perfectly valid and good value for the select element and any other value would require code changes and also changes to a lot of existing content where the 0% has been the default value.

I think that the problem is on \Drupal\options\Plugin\Field\FieldType\ListItemBase::validateAllowedValues:

      if ($current_element['item']['key']['#value'] !== NULL && $current_element['item']['label']['#value']) {
        return $current_element['item']['key']['#value'] . '|' . $current_element['item']['label']['#value'];
      }
      elseif ($current_element['item']['key']['#value']) {
        return $current_element['item']['key']['#value'];
      }
      elseif ($current_element['item']['label']['#value']) {
        return $current_element['item']['label']['#value'];
      }

      return NULL;

The first condition casts the label value to boolean, so the 0 (string or integer) gets rejected, and then the following 2 do the same for the key and value again, so NULL is returned.

I gave it a try here: https://git.drupalcode.org/project/drupal/-/merge_requests/9096/diffs

Here is also a patch (the exact same diff) for 10.3.x

MR appears to have failures, but seems like a change that will need test coverage.

Hiding patch as fixes/reviews should be done through MR.

I tested this quickly today and at least in my case the patch did not yet immediately fix the issue. It was still giving me the required field error with Drupal core 10.2.7. There might be some other contrib module involved here because I remember bumping into problems related to the new list field edit UI and perhaps Field permissions module. I wasn't immediately able to find the relevant issue but disabling field related modules like Conditional fields and Field permissions didn't resolve the issue for me yet. I'll see if I can figure out the problem in our environment.

I did a bit more testing and I can still reproduce the issue but it seems like it only happens in the content type where the option value is still in use.

I was able to save the field settings in a second content type where the field UI doesn't have theCannot be removed: option in use. warning. Basically it's a second content type utilizing the field but there is no content created in this environment. I was also able to add a completely new field with zero as the machine name.

So my problem might be related to some additional validation that happens when there is existing content where the option is used.

That being said, in hindsight at least in my case the correct field type should have been List (float) instead of List (text) but there might still be other cases where the zero should be a valid machine name also for a text list.

This is a nasty problem and it is still not solved. Using 0 as a key in a list is no bad practice at all in my eyes. Updating a old website from Drupal 8, the page is under Drupal 10.2 unusable, because I can't and new options to a list field or change labels. I wonder why this issue still does not have a higher priority. I still have no real solution to the problem.

I tried the patch from #25 against 10.2. Patch applies but does not work.

In my case i was trying to remove an option but am blocked from saving the form. But this is just a form validation. I removed the value from the config file and re-imported. This worked for me.

I tried the patch from #25 on D10.3.10. Patch applies but does not work.

Wow, this is wild! For a workaround just duplicate the value: 0 and its label, change them to the desired values in the field storage config file and re-import it.

E.g.

settings:
  allowed_values:
    -
      value: 0
      label: 'Existing label for value 0'
    -
      value: 1
      label: 'New label for new value 1'

Under drupal 10.3.10, I tried to import this

uuid: xxxx-xxxxx-xxxxx-
langcode: fr
status: true
dependencies:
  config:
    - field.storage.paragraph.field_myfield
    - paragraphs.paragraphs_type.paragraph_text_media
  module:
    - options
id: paragraph.paragraph_text_media.field_myfield
field_name: field_myfield
entity_type: paragraph
bundle: paragraph_text_media
label: 'My label'
description: ''
required: true
translatable: false
default_value:
  -
    value: 0
default_value_callback: ''
settings:
  allowed_values:
    -
      value: 1
      label: 'Label 1'
    -
      value: 3
      label: 'label 2'
    -
      value: 4
      label: 'label 3'
    -
      value: 0
      label: 'label 4'
    -
      value: 5
      label: 'label 5'
    -
      value: 6
      label: 'label 6'
    -
      value: 2
      label: 'label 7'
field_type: list_integer

and this :

uuid: xxxx-xxxxx-xxxxx-
langcode: fr
status: true
dependencies:
  config:
    - field.storage.paragraph.field_myfield
    - paragraphs.paragraphs_type.paragraph_text_media
  module:
    - options
id: paragraph.paragraph_text_media.field_myfield
field_name: field_myfield
entity_type: paragraph
bundle: paragraph_text_media
label: 'My label'
description: ''
required: true
translatable: false
default_value:
  -
    value: 0
default_value_callback: ''
settings:
  allowed_values:
    -
      value: 0
      label: 'label 4'
    -
      value: 1
      label: 'Label 1'
    -
      value: 2
      label: 'label 7'
    -
      value: 3
      label: 'label 2'
    -
      value: 4
      label: 'label 3'
    -
      value: 5
      label: 'label 5'
    -
      value: 6
      label: 'label 6'
field_type: list_integer

Getting this message in drush config-import :
[notice] Synchronisation de la configuration : update field.field.paragraph.paragraph_text_media.field_myfield.
[notice] Finalisation de la synchronisation de la configuration.
[success] The configuration was imported successfully.

But the field is not updated
If anyone has any idea what the problem is, or my yaml config is not correct?