Module seems incompatible with Drupal 10.2

oleksandr.s → changed the visibility of the branch list_predefined_options-3436776 to hidden.

+1 encountering same error.

Hi, here is patch related to this issue.

1. In patch I modified key for '#states' and added 'table' key. As now, drupal builds field storage settings form using table element $element['allowed_values']['table'] . https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/modules/opt...

2. In patch I modified 'name' selector of list_predefined_options_plugin_id to control states of allowed_values as now, drupal using subform key wrapper. https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/modules/fie...

thanks for the patch, but unfortunately it is not working on my end.

See the screen-recording →

Hi @stmh, thank you for reviewing and testing.

Here is new a patch.

Good work figuring this out!

Why the mix of patch and MR though? I've reviewed the patch but I've just seen there's an MR too :(

Please just stick to one channel -- ideally a MR.

1. +++ b/list_predefined_options.info.yml
   @@ -4,7 +4,7 @@ description: 'Provides reusable, predefined options for list fields'
   -core_version_requirement: ^8 || ^9 || ^10
   +core_version_requirement: ^10.2
   

   What's the convention on our release number if we drop support for a core major?

2. +++ b/list_predefined_options.module
   @@ -5,17 +5,19 @@
     * Implements hook_form_FORM_ID_alter(): field_storage_config_edit_form.
   

   This needs updating too.

3. +++ b/list_predefined_options.module
   @@ -5,17 +5,19 @@
   -function list_predefined_options_form_field_storage_config_edit_form_alter(&$form, FormStateInterface $form_state, $form_id) {
   +function list_predefined_options_form_field_config_edit_form_alter(&$form, FormStateInterface $form_state, $form_id) {
   

   Urgh... Yes, core forms aren't part of the API, but this is a pain :(

4. +++ b/list_predefined_options.module
   @@ -36,8 +38,29 @@ function list_predefined_options_form_field_storage_config_edit_form_alter(&$for
   +    // Form API '#states' functionality based on some classes.
   +    // So add these classes.
   +    // @see state.js.
   

   Can you explain more why we need to add these manually? That sounds like a bug in core to me.

5. +++ b/list_predefined_options.module
   @@ -45,38 +68,75 @@ function list_predefined_options_form_field_storage_config_edit_form_alter(&$for
     * Implements hook_ENTITY_TYPE_presave(): field_storage_config
   

   Needs updating.

6. +++ b/list_predefined_options.module
   @@ -108,6 +168,11 @@ function list_predefined_options_field_storage_config_presave(EntityInterface $e
   +  if ($plugin_id) {
   

   That seems like an unrelated fix?

+++ b/list_predefined_options.module
@@ -45,38 +68,75 @@ function list_predefined_options_form_field_storage_config_edit_form_alter(&$for
-function list_predefined_options_field_storage_config_presave(EntityInterface $entity) {
+function list_predefined_options_field_config_presave(EntityInterface $entity) {

These CRUD hook changes are wrong -- the 10.2 change is a UI change only. Config settings are still in the same entities.

I don't understand this change:

-    $entity->setSetting('allowed_values_function', 'list_predefined_options_allowed_values');

+    $form_state->setValue(['field_storage', 'subform', 'settings', 'allowed_values_function'], 'list_predefined_options_allowed_values');

I was struggling to understand all the changes in that MR, so I made a fresh branch, to gradually take changes one by one.

I've gone for what I think is a simpler approach, of altering the storage settings form as we already did, rather than altering the outer form. I *think* that means that our code doesn't need to be away of the subform-in-form situation, which makes it less brittle.

Hi, tested.
MR4 works for me.

hi, MR4 works for me as well!

Fixed. Making a new release on a new 3.0.x branch, since we're dropping support for a major (see https://mglaman.dev/blog/drupal-module-semantic-versioning-drupal-core-s...).

Also making a new 2.0.0 beta which is marked as incompatible with 10.2, so Composer hopefully installs the right things!

Automatically closed - issue fixed for 2 weeks with no activity.