Unable to get/set form_state values in SelectionPluginBase::validateConfigurationForm when called from EntityReference::validateExtraOptionsForm

The BC Policy → states:

While the Render and Form APIs themselves are stable, the exposed data structures used to build and cache pages and forms are not. We will change these structures where necessary to make usability improvements or add features in minor versions. This means alter hook implementations may need to be updated.

So, it looks like OPTION 1 may not break BC, therefore, I am going to proceed with this option for now.

Thanks to @joachim on slack for providing me with the friendly BC Policy reminder.

Well to be clear, it still breaks BC.

It is more that core reserves the right to break BC in those cases but we still make best effort to provide the update on a non breaking way.

It's generally weighed against how disruptive the change will be. E.g. can you search contrib code and see how many modules will be affected?

How easy is the fix? The easier for contrib or custom to update especially in a way that supports multiple versions of core the more likely.

Finally, how important is the feature or bug fix?

Answering those questions will help determine the path to take.

You can always ask the views maintainers too, I've tagged this issue, but paying on the core development channel in slack will likely get your questions answered faster.

@nicxvan Thank you for the detailed response and clarification!

A code search revealed the Option 1 change would break two contrib modules:

1. taxonomy_machine_name → (SearchApiTaxonomyMachineName::validateExtraOptionsForm)
2. mapkit → (MapkitLocationFilter::validateExtraOptionsForm)

Both methods would require a relatively straightforward fix to account for the new form state values root, but would need a new version that only supported the 11.x version this was committed to. Supporting multiple 11.x versions would require in a more complex (and most likely undesirable) fix as two different form state values arrays would need to be supported.

MapkitLocationFilter::validateExtraOptionsForm would also need to remove their workaround to get the correct parent form when creating the SubformState.

The MapkitLocationFilter::validateExtraOptionsForm code gave me a better idea for the Option 2 fix. EntityReference::validateExtraOptionsForm simply needs to use the complete form obtained from FormStateInterface::getCompleteForm, when constructing the SubformState.

So on further reflection maybe Option 2 is a better fix for now with the consideration for Option 1 in 12.x?

I am going to update the IS with these findings. Both options are relatively straight forward to implement so I am going to create a branch and MR for both, which may help in providing context when deciding which option is best.

I will definitely reach out to views maintainers on slack for feedback also.

Updated IS with the latest findings and added steps to manually reproduce the error.

I have opened two draft Merge Requests for review and feedback on the proposed options for resolution.

MR !13089 - OPTION 1

MR !13090 - OPTION 2

The following bug 🐛 PHP warning when changing “Reference method” in Views EntityReference filter extra settings Active is causing the new test to fail in both draft MRs. I have added temporary code based on the fix from this issue to enable the tests to pass and not distract from further development on this issue.

Issue #3542769 will therefore need to be merged in before this one.

Setting to Needs Review to get feedback on the proposed resolution options.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.