Fix jQuery preference order to prevent conflicts with third-party widgets#354
Conversation
…gets When other Django admin widgets (like PrettyJSONWidget, JSONEditor, etc.) load their own jQuery, they overwrite the global `jQuery` variable. Since django_select2.js prefers `jQuery` over `window.django.jQuery`, it ends up using the newly loaded jQuery instance which doesn't have Select2 attached. This causes "$element.select2 is not a function" errors on admin pages. By preferring `window.django.jQuery` (Django's protected instance), we ensure Select2 functionality works regardless of what other widgets do to the global jQuery variable.
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #354 +/- ##
===========================================
- Coverage 98.21% 48.73% -49.48%
===========================================
Files 7 7
Lines 280 277 -3
===========================================
- Hits 275 135 -140
- Misses 5 142 +137 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hi @marcelo-maldonado95 👋, intersting… yes, that is the better default. Let's ship it! Best, |
|
django doesn't vendor jquery in the default setup window.django is undefined when the django admin app is not enabled So the selection syntax, even before this PR, This is enough to fix setups without django admin enabled I think the above notes should be enough to justify another bugfix release. I separate these notes because I didn't reach a conclusion or a suggestion. I agree with this PR that django_select2 shouldn't rely on the global jquery by default For anyone using at the same time django admin Any automatic choice is fragile. I can't think off the top my head of a clean way to add a setting for the choice of namespace |
|
Thanks @Digenis excellent point. Sorry that I missed that. I released a patch using optional chaining. It's baseline "widely available", I don't see an issue with that. Hm… I'd love to switch to something that uses ESM dependencies. Sadly, Select2 doesn't see many updates these days. If you have an idea for another library or want to co-author one, please let me know. |
|
This is causing regression outside the admin and will be reversed with the next bugfix release. Sorry @marcelo-maldonado95, please see ticket #366 for more information. |
Understood, no problem. Thanks for the heads up! |
Sorry for the late reply. I'm not familiar with es modules. But, there have been numerous new standards since select2 development stalled |
Problem
When using django-select2 with Django admin (Grappelli or standard), other widgets
that load their own jQuery (like
PrettyJSONWidget,JSONEditor,django-summernote, etc.)can overwrite the global
jQueryvariable.Since
django_select2.jscurrently prefersjQueryoverwindow.django.jQuery: ```javascript factory(jQuery || window.django.jQuery)It uses the newly loaded jQuery instance which doesn't have Select2 attached, causing: $element.select2 is not a function
Solution
Reverse the preference order to use Django's protected jQuery instance first: factory(window.django.jQuery || jQuery)
This ensures Select2 functionality works regardless of what other widgets do to the global jQuery variable.
Related
This complements Fix #292 which ensures proper JS media loading order. That fix controls django-select2's own loading order, but can't prevent third-party widgets from loading jQuery afterward.