Description

jQuery.noConflict(true) should be used instead.

Now that django's jQuery object is namespaced to django.jQuery (#12882), it doesn't need to appear anywhere else in the global namespace. Most jQuery plugins overload the jQuery object (documented here: ​http://docs.jquery.com/Plugins/Authoring ), and putting the admin's object here makes it harder to use a newer version. django apps like django-selectable, which requires a recent jQuery and jQuery UI, are affected. [16415] should be reverted.

The problem of using jQuery.noConflict(true) (and which is what was changed to jQuery.noConflict() in r16415) is that it removes any jQuery from the global namespace, even if it's the jQuery shipped with a 3rd party app.

So, with the current state of jQuery.noConflict() you should be able to put another jQuery after Django's jQuery and it should just work because it's overwriting the jQuery object in the global namespace. Unless I misunderstand something the django.jQuery object should then still be the same Django-jQuery.

jQuery.noConflict(true) actually restores the previous jQuery (from _jQuery). The admin <script> tags include jquery.min.js immediately followed by jquery.init.js . With noConflict(true), the admin has no effect on the global namespace; it will never remove an existing jQuery. I've checked the jQuery source, and the tests for this behavior appeared in ​https://github.com/jquery/jquery/commit/1ac9d6fbeed214d59ea5c31a87ff2c19bb08dbc8 (before jQuery 1.2.2).

By the way, extrahead customizations appear before the admin script tags.

I've talked with robhudson about this at the sprints. We could not find any specific case where the admin would not have played nicely with third-party plugins prior to [16415]. We do see, however, how leaving jQuery in the base namespace could potentially break plugins. jezdez did commit [16415] to solve a real problem but unfortunately cannot remember the exact details. For these reasons, we should revert the change as a cautionary measure and prevent potential regressions in 1.4. This is not to say that [16415] was necessary invalid -- if one can provide a specific case where this is an issue, please do yell!

In the google groups post above, tyrion-mx suggests that the django-admin jQuery could overwrite the jQuery object as well.
This was asked for convenience, so that using jQuery plugins doesn't require a copy of jQuery. However that is a bad idea, because it ties the jQuery version to whatever Django ships (which is quite old due to release cycles, and already incompatible with django admin addons), and removes control from users of the django admin. It would break things if it appeared in a release.

Which is why I'll reiterate that django's jQuery should be self-contained, jQuery.noConflict(true) should be used, and the attached patch should be applied.

(There are some incorrect assumptions in tyrion-mx's post: {% block extrahead %} customisations, which appear before the admin jQuery, were working correctly before r16415, because noConflict(true) does not remove the jQuery object, but rather restores it.)

@anonymous: I tend to agree with you, however what we need right now is some concrete examples of how/why things would break with the current situation. Could you try to upload some code sample or maybe a sample project (in a zip file) concretely illustrating the problem that you're talking about?

Also, please do not assign tickets to other people unless they've specifically asked you to ;-)

Thanks for putting this sample project together. It appears quite clearly that currently the admin simply overrides any user-supplied jQuery with is own embedded one. I've talked through this with jezdez on IRC, and we'll proceed by reverting the change and adding some documentation.

Fixed #16776 -- Fixed a regression introduced in r16415 which caused Django's embedded jQuery to overwrite any pre-existing values of window.jQuery in the global namespace. Many thanks to Rob Hudson, Jannis Leidel and "anonymous" for the help resolving this issue.