You are not allowed to update the values in allowed_values for list type fields if the values are in use. This is ensured in list_field_update_forbid. This is good. I have a case though where I want to swap allowed_values for an allowed_values_function.

This patch allowed removing values from allowed_values IF there is an allowed_values_function AND the keys are kept using the existing logic.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

odegard created an issue. See original summary.

odegard’s picture

Status: Active » Needs review
FileSize
1.47 KB

Patch

joelpittet’s picture

We don't need to do isset() with !empty() because it does it implicitly but this patch looks good otherwise! Going to give it a try.

joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

#3 could be fixed on commit(or I can roll that in). This works though.

odegard’s picture

Thanks for checking it out.

Could you help me understand why we don't need isset and !empty?

I understand it's not necessary for this particular case when you want to actually switch between the two, but this will function run every time you try to update a list field. I don't think you can guarantee that these keys exists always?

knyshuk.vova’s picture

+1 to RTBC

odegard’s picture

You are of course entirely correct.

Patch updated.

The patch have been in use since 2017 on multiple installations.

joelpittet’s picture

Issue tags: +Drupal 7.78 target

Same here, using this patch in a few places, thanks @odegard.

RTBC++

koenstrien’s picture

I have found that this patch does not work for D9 as the list module has been removed. The function has moved to the Options module. I have changed the patch for D9 and would appreciate if anyone can test whether they agree this patch works. I have also added extra information to the error message to notify which keys are causing the import error.

koenstrien’s picture

koenstrien’s picture

koenstrien’s picture

Sorry for reuploading a few times, I have improved the patch to pass the drupal 9.0-dev test.

very_random_man’s picture

I can confirm the D9 patch is working for me.

rwam’s picture

Version: 7.x-dev » 9.3.x-dev
Component: field system » options.module
Issue tags: +Drupal 9

Confirmed that patch #12 works like a charm on Drupal 9.3.13 Therefore I switched version and component to match the requirements.

rwam’s picture

Note:
If the allowed values are dynamic, based on the entity or should not be cached statically you have to use default parameters for your custom _my_module_allowed_values function to avoid an ArgumentCountError because of the following line:

+++ b/core/modules/options/options.module
@@ -109,11 +109,19 @@ function options_allowed_values(FieldStorageDefinitionInterface $definition, Fie
+      $allowed_values_from_function = $function($field_storage);

Maybe an issue of this patch but you can solve this using:

function _my_module_allowed_values(FieldStorageConfig $definition, FieldableEntityInterface $entity = NULL, &$cacheable = NULL) {
  …
}

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Version: 9.4.x-dev » 9.5.x-dev
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

This could use some automated test coverage.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.