Issue with z-index when opening in modal dialog

The patch from #5 fixed this issue for me. Thanks!

This not only happens in CKEditor but also when you embed a form in a modal dialog. The provided patch in #5 fixed the error for me. Marking as RTBC!

This solved the same issue for me, but in a layout builder dialog. Meaning, this isn't specific to ckeditor dialogs. Also, #3258855: Autocomplete results are not visible when using select2 widget in a dialog seems a duplicate to here. Will close it as such.

+1 on RTBC.

The patch work fine for me too.
+1 on RBTC.

On a multivalue field referencing a paragraph (e.g., multiple images or otherwise) the select2 widget cannot attach to complete_form['#id'] because the id gets a unique string appended to it each time another instance of the paragraph is added. So, for example, you might have a form "node-article-form", but when another paragraph is added you'll get something like "node-article-form--o142r5QGpA8". This patch, instead, gets the form id that appears in the markup (i.e., without that unique string).

The problem with such solution that Select2 will stop working with Paragraph Classic widget or for instance with Inline Entity Form complex widget.

The solution could be to add the ability to set dropdownParent inside the widget itself. So the form id will be taken from the appropriate subform if this is the case.

It was not as easy as I thought. I should've to implement special handling for regular forms and for widget that is inside ief/paragraph forms.

Another solution could be to check if current request is trigger by an ajax request and only, in that case, add dropdownParent inside Select2 element.

    if (
      // The most reliable way to check if request was triggered by an ajax request.
      \Drupal::request()->isXmlHttpRequest()
      && empty($element['#select2']['dropdownParent'])
      && !empty($complete_form['#id'])
    ) {
      $element['#select2']['dropdownParent'] = '#' . $complete_form['#id'];
    }

But I'm not sure about the consequences.

#17 Fixed the issue I was having. No regression issues found in small positive manual test. Code changes are easy to read and reasonable.

Hi, tested patch #17 on a Drupal 9.5.9 and it works.
RTBC +1

Confirmed, #17 fixes the issue for me too, here on Drupal 10.1

One more success with #17, Drupal 10.1.8, PHP 8.2. Thanks for the work on this!

@herved the patch does not work without the #prefix/#suffix wrapper because the ID is key for the dropdownParent property to have a unique ID to work with/reference. If $wrapper_id isn't added as an ID here, then you'd need to add the ID to some other element wrapper around the field, but within the modal.

I should add that I have just found some cases where this patch does break styling of some Select2 elements on the site I applied it to, so a change record/notice is definitely important if you stick with the current solution. If you can place the ID used by dropdownParent in some other pre-existing wrapper, that would have less impact.

Is there a way we can determine when the wrapper is actually needed in the Select2 class, vs. simply setting the dropdownParent to the form ID (without adding any wrapper), as was the approach at the start?

After further review of the impacts throughout our site, I've found that the wrapper is not actually needed for any of our Select2 fields, but when present it DOES cause significant styling issues in some cases.

I think it would be well worth figuring out how to be more selective about the inclusion of the wrapper, to minimize impact to users of this module. I'd take a stab at it myself, but I don't have any use cases that actually need it, so it's hard for me to know where to begin and how to test.

Could the issue be more easily solved in JS by determining if the element is in a modal and then getting the parent form object to set as the `dropdownParent `?

The attached patch is working for me in paragraphs, modals and regular forms without the need for a new wrapper element.

Is this still an issue?
Because for me it seems to work.

Patch #25 did not work for me using Layout Paragraphs where a field within a Paragraph has Select 2 enabled for form display.

Patch from #17 works in this scenario for me.

Yes, it is still an issue. Drupal 10.3, Select2 4.0.13, drupal/select 1.15.0. Using MR 8, not the patch (which seem to be just static copies of the MR).

Path in #17 works for me with Layout Paragraphs and select2 field in modal form

MR 8 Working for a dialog modal bootstrap and drupal 10

Patch #17 fixes the issue for me, on Drupal 10.2

We are having a content type having a field that is using the Layout Paragraph widget, and the select boxes are not working as stated in this issue.
Applying the patch #17 fixes the issue in our environment , Drupal v10.5.6, Layout Paragraph v2.1.1and Select 2 v2.0.0.
The select boxes are now working as intended.

Tested in Drupal 11.2 after applying this patch for jQuery 4 support - https://www.drupal.org/project/select2/issues/3509122

Was able to replicate the issue, and the patch at #17 fixes the issue.

Patch #17 fixed the problem! Drupal 11.3 + Select2 2.0.0