Remove jQuery CDN setting in favor of using jQuery Update module

+1 to committing this.

Why would you commit this!? Updating jQuery like that breaks a LOT of Drupal, which is the entire reason that we *have* jquery_update module. You have just destroyed any chance of being able to use this theme.

And even if it doesn't break things, you're still loading two instances of jQuery on the page, which completely kills front end performance.

So you're giving people with limited development knowledge a switch that can, worst case, completely break their site, and best case, slow down frontend performance by a factor of two?

That doesn't seem wise.

Good documentation about how to download jquery_update and whatnot is the right path here.

Well the entire reason for jquery_update existing is that newer jQuery versions don't play nicely with core/contrib Javascript. Sure, it breaks ctools stuff, but that's what happens when you mess with the jQuery that's being loaded: things break. jquery_update aims to fix that by swapping out the broken javascript files with fixed versions. Dropping some external jQuery in without fixing those files will cause them to break.

However, since you've added the external jQuery in noconflict mode, that /should/ be avoided, in theory. But that doesn't solve the problem of having two separate jQuery instances loaded on the page.

I think that it's totally reasonable to depend on jquery_update for this theme and not try to duplicate that functionality. Let jquery_update handle the intricacies of updating jQuery and focus on what this theme is trying to do: integrate Bootstrap.

I have no issue with externally hosted resources, but pulling in jQuery like that is reckless. jquery_update is the de-facto, community accepted solution. Going against that is causing more problems than it solves.

A big +1 to cweagans' concerns.

I totally understand the desire to make things easier for the site builder by providing a quick switch, however it does give inexperienced people a lot of rope to hang themselves with as well. Having worked as a consultant delivering Drupal trainings to people who are inexperienced, experienced, and everywhere in between, the quickest way to get them to passionately hate a technology is to provide them with an easy button loaded with gotchas.

Specifically, the majority of JavaScript in Drupal assumes the version of jQuery that ships with core, which I believe is 1.4. If you upgrade to 1.7, a lot of things break such as the ability to use certain features in Views, the core ajax functionality in some cases, and a bunch of other bugs that place you deep in the guts of jQuery and core Drupal JavaScript to debug. So although the original intent was to help out inexperienced developers, the result is that they are thrown head first into debugging that even Drupal wizards find difficult.

At the end of the day, no matter how inexperienced you are, you should be able to install a module if you are working with Drupal. Heck, you already installed this theme, which is arguably more difficult to do. The benefit of piggy-backing off of jQuery Update is that the module is working to address the incompatibilities for you, so even though there are still gotchas, there is a large community of people actively working to resolve the problems in the module without the site builder or this theme having to address them. jQuery Update is a top 30 module in terms of usage, and that's saying something. Let's do site builders a favor and guide them towards the best solution available that is backed and tested by a large community.

Thanks in advance for your consideration to this,
Chris

But the second part kinda confuses me because its not related to the solution presented in this patch/commit.

OK, I see now. Thanks for sticking with me on this. I think I missed the overall point and honestly don't have any expertise in the no-conflict stuff, especially with the multiple version of jQuery on the same page. So given that this topic is about something different than I though it was and something that I have little value to offer, kindly ignore me. :-)

Thanks,
Chris

Yes, but executing two separate instances of jQuery on the same page is a huge performance issue. The jquery_update module is the solution that you should use. Period. If you're not doing that, then you're causing more headaches than you're solving. Anyone should be able to download a module if they have already downloaded a theme.

jquery_update is *the* accepted way to update jquery mostly due to the community of contributors that are working on fixing the problems that it causes. Loading another jQuery in noconflict mode is a bad idea, especially when it's done by an option that beginners who don't know any better will use. You should be steering said beginners toward smart solutions, not quick solutions that cause performance issues.

FWIW, I actually just ran into an issue where having two versions of jQuery breaks the Bootstrap JavaScript APIs. This is confirmed at https://groups.google.com/d/msg/twitter-bootstrap-stackoverflow/cMv8WYCd....

Posted bug at #1853936: Bootstrap JavaScript API broken when the CDN setting is enabled with more details about what was discovered in #1846736-22: Remove jQuery CDN setting in favor of using jQuery Update module.

Sorry I missed this discussion earlier. Just to offer another suggestion / perspective.

We could possibly look to redevelop the old twitter_bootstrap_ui module ( http://drupal.org/project/twitter_bootstrap_ui ) and recommend it as a supported solution.

If we did so, then we could offer:

- Libraries API support #1852332: Integrate with the Libraries API module
- Ensure that jquery_update is set as a dependency (leveraging jquery_update rather than hotlinking via CDN directly)

We could also make the "bootstrap_ui" module set the jQuery version (using jquery_update) on installation....

Besides the issues reported by cweagans, this feature, due to the order of how the cdn script is loaded, breaks once, form, cookie and basically every jQuery plugin that is loaded before the theme layer (aka every jQuery plugin which is included by a Drupal module, even the Core ones).

@cweagans
As a beginner i had some issues,
Here some issues I had with jQuery update module:

Bootstrap at least needs version 1.7 (jQuery update module.
If choosing 1.8, my Views module breaks completely(version = "7.x-3.5")

jQuery update module version 1.7 --> Beauty Tips module (version = "7.x-2.0-beta2")
the user-interface is not working properly(no hover examples and the settings don't work).
With version 1.5 jQuery Update it does work.

For me it is not clear if the no conflict solution for multiple jQuery libraries works and how to implement and manage them.
jQuery update module works well, but to have checking all contrib modules if they work with it, is too much, as I need to work with Bootstrap as well.

I need to have the possibility to implement modules like Beauty tips. It looks now more easier to implement them in my custom small beginners module, and add the jQuery myself.

I think the theme should be separated from the jQuery integration in Drupal, as it has the drupal behaviors already set up as the architecture for this. Just loading some new version through the theme setting I agree is like an elephant in a porcelain shop.

If I need to clarify some problems I had regarding specific issues, please let me know I will provide more info.

I couldn't agree more with @cweagans and @cpliakas. This patch should be removed.

From http://api.jquery.com/jQuery.noConflict/:

Many JavaScript libraries use $ as a function or variable name, just as jQuery does. In jQuery's case, $ is just an alias for jQuery, so all functionality is available without using $. If you need to use another JavaScript library alongside jQuery, return control of $ back to the other library with a call to $.noConflict(). Old references of $ are saved during jQuery initialization; noConflict() simply restores them.

If for some reason two versions of jQuery are loaded (which is not recommended), calling $.noConflict(true) from the second version will return the globally scoped jQuery variables to those of the first version.

To summarize, clarify and reiterate what is stated on jQuery's documentation: using jQuery.noConflict() is not meant for loading two versions of jQuery. It is really only for special use cases where another library (like MooTools) is being used and the $ variable needs to be reassigned.

I understand that this patch was originally committed to help novice users implement a Bootstrap theme in a rather quick fashion with minimizing necessary understanding of why a higher version of jQuery is needed. However, I also think this is a very bad approach. This presents several issues:

1. This "enhancement" is duplicating code & functionality. This inadvertently forces support of jQuery in this project's issue queue. The jquery_update module exists for a reason, it should be used.
2. As previously mentioned, this method of implementation also forces two versions of jQuery to be loaded. Not only is this frowned upon by jQuery's documentation itself, it also adds a significant and an unnecessary impact on front-end performance.
3. Despite the attempt to help simplify getting Bootstrap "working", this actually provides more confusion in the long run. By loading two separate versions of jQuery, this actually makes it more difficult to track down bugs. Does it lie with the the jQuery version loaded with the Bootstrap base theme? Is it caused by a contrib module? Are they somehow intertwined? These are some of the questions the "novice" user might ask, if not more.
4. Instead of coding to standards and making things more solid, we're going down the path of providing "dummy" support. Instead of providing necessary documentation on how to get things working probably, we're introducing yet another path of uncertainty. How does this help a novice? How does this help reduce the amount of issues in the queue?
5. Drupal has never been synonymous with the words "dummy proof". Drupal is inherently complex, especially when you start getting into the front-end aspects. Now I'm not saying we shouldn't help simplify things so they're easier for novice users. However, documentation is the necessary path, not adding unnecessary code.
6. @boban_dj about Views and 1.8: this issue has been known for a while and was finally committed: #1802198-27: Views UI breaks with jQueryUI 1.8.2. I would like to point out though, that this is how issues should be handled. When a contrib module breaks because of a jQuery update, then it should be addressed and fixed by that module. We really should not get in the habit of trying to load two versions of jQuery to avoid fixing issues. Things break, let's fix them... not cover them up.

Changing title since the patch was already committed.

+1 to removing it too, jQuery Update is a better option IMHO

Attaching revised patch, forgot to take out the commented legacy exclude of misc/jquery.js in the .info file.

Committed.