Make the default jQuery version (1.4.4) for D7 an option

Instead of providing another jQuery 1.4.4 in replace/jquery/1.4/jquery.js as the patch in #1 does I would prefere to just use the default jQuery lib provided by Drupal. Patch attached, which just disables the replacing mechanisms of jQuery Update and hides the compression/CDN options in the settings form.

I've been needing this for a long time as jquery_update-dev has broken some parts of my admin (and frontend as well).

I've applied this patch and it has resolved my issues.

Here's a new patch against latest dev. We should get this patched in, as I believe it could help a lot of strange admin issues.

Added option to select jquery version shipped with drupal for admin theme only.

...for admin theme only.

Any specific reason for limiting this to the admin theme? The whole point of offering the default shipped version is to use it in order to troubleshoot issues. So, we need to be able to configure these following combinations:

- some specific jQuery version for user-facing theme / default core jQuery for admin theme [now possible with your patch]
- default core jQuery for user-facing theme / some specific version for admin theme [not possible]
- default core jQuery for both the user-facing and the admin theme [users can disable jquery_update]
- specific (and possibly different versions of jQuery) for the user-facing and the admin theme [current jquery_update behavior]

Is this still needed?

There was another issue where we decided not to do this for the simple reason you haev 1.4.4 available to you by not enabling this module.

Now you also have the option of switching jquery version on the "back-end" or front-end part of your site.

Let me know.

Now you also have the option of switching jquery version on the "back-end" or front-end part of your site.

And that's precisely why we need the 1.4.4 option: one might want to use an updated version of jQuery for the front-end and still use what comes with core for the admin UI (or the other way 'round). As it is now, none of these combinations are possible. You can only have either whatever comes with core (by disabling the module or not installing it at all in the first place) or any combination of updated non-core versions of jQuery.

Please reconsider as this would make troubleshooting jQuery related issues a lot less tedious. Thanx in advance.

+1 for seperating frontend jquery version from backend jquery version. (and include the default jquery version at least for the backend as an option)

currently too many things in the admin ui are broken with jquery_update enabled, rules module with token integration is broken (last thing I remember) and too many other things to keep track off.

+1 for having default jquery version as an option at least for the backend, because there are some issues in the backend with newer jquery versions (Rules for example).

Default jQuery in the backend as an option please.

@klonos the thing is that technically you can't run 1.4.4 on the backend but you can run 1.5 and there is barely any different with running 1.5 in the backend over 1.4.

Is anyone having issue with 1.5? and require 1.4?

I'm reluctant to do this unless enough people have valid reasons for it. jQuery update isn't currently written to allow the default version to be used which is why I'm trying to avoid the complications.

Fair enough. Perhaps we should actually postpone this till somebody reports issues with 1.5+

I know of at least one major issue with rules and 1.5, going to screencast it this weekend.

Yes, you can't use rules ui with jquery 1.5.
@see #1810656: Rules UI does not work with JQuery 1.7+

+1 for including this, it isn't exactly a lot of work and will help fix some sites.

@ericduran

jQuery update isn't currently written to allow the default version to be used

So why not to make it non-default 1.4 then? It looks like people are asking about it, and adding 1.4 just the way other are added shouldn't be that much of a problem?

Actually that sounds like a good plan. Shipping with a 1.4 but a newer version.

This way we can just drop it in the replace folder and not to have extra code to handle the regular /misc folder.

I'm ok with that. I'll whip up a quick patch.

Well 1.4.4 was the last one in the 1.4 serious but I would still prefer having it in the jquery replace folder so we won't have to add any more php code to handle edge cases.

Does this work for everyone?

@ericduran: I still don't see what the big deal is, it's not like the patch in #4 adds very much code?

It's not really that big of a deal.

My main issue with this is that all of these fixes are essentially work around instead of fixing the actual issue. So far the only noticeable module that is broken is Rules UI. Instead of having Rules UI run with 1.4 we should fix it to work with the latest versions. I already submitted a patch over at #2086105: jQuery UI menu not including and a comment over at #1810656: Rules UI does not work with JQuery 1.7+.

This seems like a better approach to me instead of adding work arounds in the module. This is was the same problem with views. Instead we just fixed the views issue.

Idk, If everyone disagrees with me, I'm ok adding this but essentially we're just making life harder for all of us.

the thing is, newer websites need jquery_update and in the current state it causes so much trouble that you can not rely on it / ship with an updated jquery version. Ill be happy if there's no need for 1.4 anymore but till then we need a workaround for live sites.

@ericduran - module updates not only jQuery itself but also some libraries, right? Even if there is no more recent version of 1.4, it would be nice to be able to use CDN for it, or update accompanying libraries. Even if there are no updates at the very moment.

Of course Views and Rules UI should be fixed, too, but my ex employer used to have some really old own code, too, and a lot of it, in admin area. I believe there might be more cases like this. So if that's not too much of a problem, I would be really glad to see 1.4 shipped just like the other ones within this module.

The CTools modal dialog was having problems with jQuery 1.5 as well (I ran into it adjusting the settings of a context in Panels or Mini-Panels). Reverting to 1.4.4 fixed the issue there.

I've rerolled the patch against the latest HEAD. I'm RTBC'ing this issue since I didn't change the patch from #4 other than to put the patch root directory at jquery_update and based on the above comments.

but essentially we're just making life harder for all of us

True -- bugs that aren't caused by jQuery API changes should be fixed in the module. But it's a hard argument to make for fixing a bug that doesn't repro in a clean install... This gives us a workaround until we reach that Brave New World (gazes longingly toward the horizon) where all bugs are fixed where they ought to be fixed. :)

(Edit: Interdiff is against the patch in #4).

For me patch #23 is not working correctly with rules. If i add an action or condition i get "TypeError: $(...).once is not a function". But other things in the rules ui are correct with the patch now.

#23 doesn't work with AJAX requests (since it excluded all the ajax fix javascript). I've rerolled the patch (also against the latest HEAD) with a couple of tweaks and have confirmed that this works with a problem I had with field collection embedded forms (adding/removing items with ajax).

Patch #25 looks good with rules_ui too.

#23 doesn't work with AJAX requests (since it excluded all the ajax fix javascript).

+++ b/jquery_update.module
@@ -94,6 +94,13 @@ function jquery_update_library_alter(&$javascript, $module) {
+    // If the ajax version is set then that one always win.
+    if (!empty($_POST['ajax_page_state']['jquery_version'])) {
+      $ajax_version = $_POST['ajax_page_state']['jquery_version'];
+      if (in_array($ajax_version, array('default', '1.5', '1.6', '1.7', '1.8', '1.9', '1.10'))) {
+        $version = $ajax_version;
+      }
+    }

None of the previous patches in this issue had any changes to this code. Is that from another issue?

Moving that code to the function above was a deliberate part of the fix. Without this, performing 2 ajax requests in a row (e.g. adding field values to a multi-valued field) results in an error.

I think =)

#25 is working for me, on Rules UI (my specific need), and other things I've tried so far.

Yes, patch #25 works with rules and panels ui.

My specific issue was with path_breadcrumb. Patch #25 fixes that perfectly.

Thanks everyone!

Moving to RTBC based on #26, #29, #30 and #31. Thanks for the feedback.

Just tested on simplytest.me and #25 still applies and works as advertised.

I verified that it could use a newer version on the Frontend and a default jquery 1.4.4 on the Backend.

My specific issue was with inline_entity_form. Patch #25 works fine
Thanks jamsilver

This patch is working smoothly. Please commit it!

this is waiting for commit way too long, I don't know how you see this issue, but not being able to use the admin pages with jquery_update enables is kind of a critical bug for all site builders/ developers. Stuff like rules UI is almost unusable, having to patch jquery_update manually before being able to develop with/ for a new design is really annoying.

Agree with #36. Please commit it. Thanks

context integration might be a benefit for future site builders too, there is an old issue raised here: #874942: Context support for jQuery Update

Agree with everyone else here that this needs to be committed. I have seen the problem at various times with Rules UI, context, Inline entities, various commerce modules like commerce_ajax_cart, path breadcrumbs and views.

Even if you go to the module in question and get it fixed there, you likely just cause another issue. Like, say, you go to the Views devs and get Views working up to 1.8, and you go to the Path Breadcrumbs guys, but they only fix theirs up to 1.5, well then you still have an unusable site admin.

Every contrib module developer is going to make sure their admin features functions on a vanilla install with default jquery. If we don't provide an option of supporting the shipped jQuery, we are not just asking them to support the latest jQuery, we are essentially asking them to support EVERY version of jQuery that ships with this module, because there is no way to know which version site maintainers are going to use on their site. It's too much to ask them, IMHO.

RTBC++ this helps make sense of the "use default" in the UI too, awesome work.

Why is this not in 2.4? It was rtbc for a long time!

and this issue missed commit again, come on. make jquery_update usable!

@hass @Andre-B, This is a completely new feature didn't really seem critical for 2.4

2.4 was to help all the people that don't like running -dev but dev is/has always been pretty stable.

;-) Odds are this will make it in 2.5 I'll review this later.

Sadly I'm still against this patch in principle since jquery_update has always been about updating jquery, this is against the one job this module has to do.

I know a lot of people want 1.4 but that's the incorrect approach since the correct way forward is to fix all the modules that do not work with later version of jquery which is what I've spend most of my time doing which seem like a more appropriate fix then running multiple version/running and old version ;-)

Hope this is helpful :)

drupal.org takes a while to show the changeset.

This is fixed and can be expected in 2.5.

Thanks for all the hard work ;)

"I know a lot of people want 1.4 but that's the incorrect approach since the correct way forward is to fix all the modules that do not work with later version of jquery which is what I've spend most of my time doing which seem like a more appropriate fix then running multiple version/running and old version ;-)"

This isnt a bad approach, but man, jQuery update is breaking Views Admin (and other modules), Drupal becomes unusable in that case and a big headache for all until this is fixed. I just installed views 3.8 and 2.4 and Views UI is either non responding in some versions or I get broken page when I try to add new fields. Nobody wants that, so lets get some sense into all of this and have default jquery option in stable versions until at least Views are fixed.

@Marko B: This fix has been committed -- see #44. Since there hasn't been a new module release since then, you'll need to use the -dev release or use the 2.4 release and apply the patch.

It might be time to push for a 2.5 release of jQuery Update, but that would need a new issue and someone to go through all the commits since 2.4 and make the case to the maintainers.

Confirmed that the -dev release fixes this. Looking forward to 2.5 to be able to use a stable version of the module for this.