Not able to add option with key and label '0' to List string field

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

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 ?

RE https://www.drupal.org/project/drupal/issues/3411419 , 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 exist:

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 (integer) values, keep in mind you'd need to do this for every instance when adding a new field 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. Then you'd never have to worry about the (integer) value of 0 impacting future updates to your list.

These solutions will work but keep in mind if you plan to use (integer) 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? Didn't have more time to look into where default_value is set.

I encountered 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?

I also have that issue.
Any ideas how to manage this by something that is no ta patch and without losing the data?
Will test #32

Put up MR 11000 with fix and tests. This is ready for review.

I tested the functionality in local and I am not able to reproduce the error with the changes from this MR anymore.

The current test pipelines https://git.drupalcode.org/issue/drupal-3416819/-/pipelines/405923 do seem to have errors still:

2) Drupal\Tests\options\FunctionalJavascript\OptionsFieldUIAllowedValuesTest::testOptionsAllowedValues with data set "List string with 0 value: Enter button" ('list_string', ['0', '1', '2'], true, 'Enter button')
Failed asserting that two arrays are identical.

The current test pipelines https://git.drupalcode.org/issue/drupal-3416819/-/pipelines/405923 do seem to have errors still:

That is the "test-only" job. All MR changes outside of test code is removed, and the run is intended to demonstrate that the bug currently exists. The main test jobs passing demonstrate that the changes fix the bug.

The suggested code from review does not handle 0 correctly, so I'm moving the MR as is back to Needs review.

Left a comment on the MR.

The changes are needed because the test needs to evaluate the case when the label and value are both string 0, so "0", "1", and "2" need to replace "First", "Second", and "Third".

Ah I see. Not a clear as was before but I get it. That was only feedback I had

Manually testing following the steps in the summary
Create a list filed
Item: 0 => 0
Item 1 => 1

Everything works as expected.

Works as expected

Error message "Value field is required" still present after patch with MR!11000 over Drupal 10.4.4. My field was inherited after migration. It is a translatable field on a multilanguage site and the error occurs when I uncheck the "Users may translate this field" checkbox, and, indeed, in "Allowed values" there is "0" key.

@erwangel can you provide the keys and values for all the allowed values? Translated ones as well, if they were set.

@godotislate I attached the yml file with the field.storage.node.myfield in its default language (fr). I added the translations of each value so the file is not directly importable as config.

@erwangel I am unable to reproduce your issue with the provided config. Can you provide reproduction steps starting with a core install with standard or minimal profile?

If not that, perhaps a screen recording of what actions you are performing and the error.

This one is tricky, but the test changes look good and the logic seems fine. I wondered about changing the early return to remove the nesting or similar but could not really come up with anything better.

Committed/pushed to 11.x, thanks!

This needs a backport for 10.5.x, 10.4.x?

The patch MR11000 apply cleanly on 10.4.x but does not appear to resolve the issue.

I can confirm this is still a problem on core 10.5.1. I try to save and set a default and get "Value field is required" validation error, so I can't save it.

@potassiumchloride: You cannot set default value if an entity already has values from the selection-field.
First you should delete the entities which use the field, before you can make options.
If you create a new (N E W) field, you can not set default value before the field is saved at the first time.
After the first save you can edit the field and set default value and "required" to the field and save it.
(Tested in Drupal 11.2.4).

My problem has been that the value 0 (zero) in the key was not allowed. In my code i use (int) -1 as "null-value" because of that. (Just as @tawellman).
In my latest test for you I didn't reconize this problem. Perhaps it is gone?

I'm sorry. I should have been more clear. I have the same problem as the original one, but I didn't specifically mention it in that above comment. I have a value (0) as a key in a list (integer) field. Everything worked as expected until about a year ago, prior to about 10.2 and then I could no longer edit the field settings. I now have the same situation for a site that is being migrated from 7 to 10. A migrated field has a list (integer) field where one option has a value of zero. When I try to edit the field settings, I cannot make any changes: adding a new field value, require or unrequire it, etc. because I get the "Value is required" error. So, while this issue is set to "fixed" it is not fixed for me on 10.5.1.

First you should delete the entities which use the field, before you can make options.

This issue occurs on a site with hundreds of thousands of nodes, and I can't delete entities that use the field, nor make changes to the field settings because the value (0) prevents saving the /admin/structure/types/manage/[type_name]/fields/{field_name] page.

Ok, I recognize the problem. I've tried the same thing, but I haven't found a solution.
I had to create a new field with the same integer values ​​except for 0 (zero). Instead, I chose -1 as the NULL value. You can also choose another value, but both solutions have in common that you have to program the field to have a different value for "empty" or NULL.
Then I copied all values ​​from the old field (and converted 0 to -1) to the new field and then deleted the old field.
...but that requires reprogramming your own source text.