Open iliman opened 7 years ago
Looks like our css is setting the z-index for all select2 containers to 16000, which is underneath the customizer panel (set in core to a z-index of 500000).
I don't remember offhand why we needed to set that z-index value, as opposed to just leaving the select2 container indexed at 999999 as it's defined in the select2 library styles. If someone would like to test removing our style overrides and see if anything breaks, we might be able to fix this one quite easily.
Or we can just add a separate z-index for the customizer:
.wp-customizer .select2-container {
z-index: 999999;
}
This issue has been fixed by the Kirki author here. You can close this.
As @iliman said, the conflict with Kirki has been fixed but there are othe plugins that use select2 in the customizer and are affected by the low z-index. Xwp customize post is one example.
I agree with @antekdesign that we should fix the z-indexing issue here.
It'd be nice if we could use a more specific selector to target only the select2 containers which are inside the media modal, so that we don't clobber the layering of any other select2 fields elsewhere in the WP admin. Unfortunately, the way we're calling select2 currently doesn't pop the container inside the modal, so something like .edit-shortcode-form .select2-container
won't work off the bat.
I think the best way to target only the instances of select2 that we actually want to modify is to do something with the "theme" argument that gets passed to select2. Passing a string as the "theme" of the select2 field will give the dropdown a unique classname that we can then target in CSS, so that we don't override any global styles.
When Shortcake is active, all the select fields in Kirki stop working(in the customizer). The
SELECT2_NOCONFLICT
constant doesn't help.Versions used:
Shortcake 0.7.2, latest master branch Kirki 3.0.3