Stan.Ezersky’s picture

My solutuion

 * Return the path to the jQuery file.
function jquery_update_jquery_path() {
  // Check whether we are to retrieve the minified version.
  $jquery_file = array(
    'none' => 'jquery.js',
    'min' => 'jquery.min.js',
  $type = variable_get('jquery_update_compression_type', 'min');

  $curr_uri = request_uri();
	if (strpos($curr_uri,'admin')>0 || strpos($curr_uri,'edit')>0 || strpos($curr_uri,'add')>0){
		$path2 = drupal_get_path('module', 'jquery_update') .'/replace/jquery/1.3';
    return $path2 .'/'. $jquery_file[$type];
  else {
  // Find the jQuery version to use.
  $version = variable_get('jquery_update_jquery_version', '1.3');
  $path = drupal_get_path('module', 'jquery_update') .'/replace/jquery/'. $version .'/';
  return $path . $jquery_file[$type];  
rokr’s picture

markisatacomputer’s picture

I needed functionality like this so I ended up adding another setting so that certain paths will be excluded entirely from update.

Here's a patch.

markisatacomputer’s picture

ok. That was a little hasty. I decided to throw in the classic choice between either excluding a set of paths or only including that set. Here's the updated patch.

kpa’s picture

Although #2 is related, #4 gives the eventual result in a much simpler way.

Excellent patch @markisatacomputer - +1 to get this into dev version of jquery update.

pitxels’s picture

#4 Perfect, I really think this is how this module should be for 6.x

Stan.Ezersky’s picture

$4 great!

Lasac’s picture

2.29 KB

Here's the patch for D7, totally based on #4

tempo22’s picture

don't forget to change the path
--- L:/LASAC/DEV/SITES/sites/indepressie.localhost/

serjas’s picture

patch which will give an admin setting so user can set path to exclude 1.7

serjas’s picture

patch which will give an admin setting so user can set path to exclude 1.7

solomonrothman’s picture

Is there a way to only update jQuery for one particular theme? A Mobile theme? I'm working on a site that is stuck on Drupal 6, and I'm using theme switcher to provide the mobile experience The Mobile theme version, does not need to have admin functionality or even node creation (for this particular site). They just want a really slick interface for searching and displaying content, so to run jQuery Mobile I would like to update only the version of jQuery when that theme is active? Could this be achieved with this module by adding something like active theme? Although I'm using theme switcher, there are other use cases for wanting jQuery to be updated different based on the theme, jQuery mobile being one of them.

Zach Harkey’s picture

Status: Active » Closed (duplicate)
mpv’s picture

Version: 6.x-2.x-dev » 7.x-2.3
2.16 KB

Patch in #8 with correct paths.

Sarenc’s picture

This is a great addition to jquery_update. I vote for it being included.

cvharris’s picture

Version: 7.x-2.3 » 6.x-2.x-dev
Issue summary: View changes
Status: Closed (duplicate) » Fixed
Related issues: +#1067290: Fix jQuery 1.7 for Drupal 6
3.04 KB

I combined both #11 and #4 together in this patch, adding an exception that the exception paths may still be an empty string, in case someone wanted to only specify fallback paths and not exclude updating jQuery altogether.

This patch may not seem like an important one at first, but let me just say this issue has frustrated me for awhile now. Drupal 6 is still running several sites but there are many cool plugins out there that need jQuery 1.7, so there had to be a way to use jQuery 1.7 when you needed it and keep 1.3 when you don't need it, or just exclude updating altogether. This also solves many issues experienced at #1067290 At least these two features give Drupal 6 developers easier control to fix jQuery through this popular module.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

idebr’s picture

Status: Closed (fixed) » Active

I believe this issue is still relevant, as the patch in #16 has never been applied to the jquery_update repository.

RoySegall’s picture

I can see this patch is against D6. Do we need to roll it against D7?

plach’s picture

An alternative approach for D7 is available at #2181095-2: Disable jquery update for admin path option in settings.

avillanueva-npr’s picture

Version: 6.x-2.x-dev » 7.x-2.3
2.17 KB

I had issues with aliases but the change is minor (look at line 11)

$excluded = drupal_match_path($current_path, $update_exceptions) || drupal_match_path($alias_path, $update_exceptions);

So now if you have a content type where it's alias is post/* like on our sites this will still work.

avillanueva-npr’s picture

I needed to add the alias path.

SebCorbin’s picture

Title: Disable 1.7 on admin and node add pages » Disable jQuery Update on specific paths (admin or node/add)
Version: 7.x-2.3 » 7.x-2.x-dev

Just modifying the title to prevent misunderstanding with #1548028: Make the default jQuery version (1.4.4) for D7 an option

chevali’s picture

is there a patch for the latest version? i need to disable it on the node/add path, as it's conflicting with hierarchical select

badzpeed’s picture

Is there a patch for 2.4 ? i wanted to disable jquery update in the front page

markcarver’s picture

Status: Active » Closed (won't fix)
Related issues: +#1969244: Specify jQuery version per theme

We are moving in a different direction.

markcarver’s picture

Status: Closed (won't fix) » Needs review

Actually I closed this one prematurely, sorry. There is specific use cases: #2309163: Exclude alternate jquery version for certain pages.

guardiola86’s picture

Forget this patch, I added duplicated stuff and didn't work for me. I'm gonna create a new one.

guardiola86’s picture

guardiola86’s picture

Attached a new patch that solves the issues. Now you can exclude an administrative path from the alternate version and use the selected default. In frontend, if the path it's excluded then 'default' will be used.

markcarver’s picture

Just a crazy idea here, so bear with me. There are so many different types of modules that break because Module A was built on 1.7 and Module B was built on 1.8. Module C was built on 1.4 (core) and it doesn't matter what version one chooses, if you have a ton of modules that all work differently, they certainly don't always work together.

Now my immediate "solution" would be to just say to Module A, B and C: "Update your module to work with the latest jQuery version". How realistic is that though?

The patch is pretty straightforward. Based on the toggle, it will either only include or explicitly exclude matched paths. That is an all or nothing approach.

What if we simply had a way to support any version for multiple paths? For example (I do not actually know off the top of my head what jQuery versions these modules support, FYI):

 * Implements hook_jquery_update_paths_alter().
function views_jquery_update_paths_alter(&$paths) {
  $paths['admin/structure/views/*'] = 'default';
 * Implements hook_jquery_update_paths_alter().
function context_jquery_update_paths_alter(&$paths) {
  $paths['admin/structure/context/*'] = '1.6';
 * Implements hook_jquery_update_paths_alter().
function features_jquery_update_paths_alter(&$paths) {
  $paths['admin/structure/features/*'] = '1.9';

We could even provide a message to users warning them when multiple modules have defined the same path that have conflicting versions. This would be a better indicator that these two modules should work together or at least one of them should update their minimum supported jQuery version.

markcarver’s picture

Title: Disable jQuery Update on specific paths (admin or node/add) » Change jQuery Update for specific paths (module specific)
Plazik’s picture

#30 works for me. Thanks.

rcodina’s picture

Patch on #30 works for me too. However I see a big problem: If I want to exclude paths for administration pages, I cannot have different jquery version for admin pages and for frontend pages. So I'm forced to select "Defaul jQuery version" on administrative pages select.

Maybe we could have two different exclusion fields: one for admin and another for frontend pages.

Plazik’s picture

@rcodina see my configuration in screenshot. It works for me.

paean99’s picture

Seems to me that #31 is the beginning of a good solution. But the hook should be implemented by each modules themselves.
jQuery Update would give access to the different versions and continue to give essentially the sames options it has been giving (front-end, back-end and updates), taking care that the default versions are drupal core safe. While each modules and theme would call the specific version in their implemented path.

LeDucDuBleuet’s picture

#30 works for me as well. Thanks.

markcarver’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev
Status: Needs review » Needs work

I'm really not in favor of #30, especially now that #1969244: Specify jQuery version per theme has been committed. Has anyone taken a look at the proposal in #31 aside from @paean99?

But the hook should be implemented by each modules themselves.

Agreed and my example shows that (context, features, views) these would all be provided by the module themselves. If it were jquery_update providing them, it would look like jquery_update_jquery_update_paths_alter() since the hook (module name) is HOOK_jquery_update_paths_alter().

I would, however, suspect that for certain modules, like Views, we would need to provide initial support until an actual patch for the module can be made, committed and then released. Given that Views is in core now (D8), the contrib version seems (to me) like it's taken a back seat in D7... so I'm not entirely sure this will happen?

paean99’s picture

Sorry, you are right.
I misunderstood your post and it was sufficiently clear :(

Francewhoa’s picture

There is a related module at

This module allows multiple versions of jQuery instances loaded on the same page. Maybe some of its code could be adapted to the needs of this ticket. To change jQuery Update for specific paths.

Any volunteer? We would be happy to contribute Quality Assurance and documentation.

majorrobot’s picture

Just ran into this issue myself on a project. While #30 resolves the immediate issue, #31 is a more flexible solution. I think it's a great idea.

majorrobot’s picture

Attaching a patch that implements #31 with a drupal_alter(). This should allow other modules to change the jquery version by path. Note that this setting will still defer to the theme setting that is new in 7.x-3.x.

majorrobot’s picture

Status: Needs work » Needs review
majorrobot’s picture

Hmm, looks like there's not much sense in making a path override if it doesn't also override the theme setting (since the theme setting would always override the path setting).

Here's an updated patch that addresses this.

mattew’s picture

Here is a properly formatted patch (the precedent one had the full path hard-coded) and add a test for "current_path" so an internal path scheme may be use.

@majorrobot, thanks for your patch. Next time you may follow guidelines to supply a patch.

markcarver’s picture

Hmm, looks like there's not much sense in making a path override if it doesn't also override the theme setting (since the theme setting would always override the path setting).

Correct. If a module implements hook_jquery_update_path_alter and it still doesn't work for a theme, then the theme can also implement the alter to override what the module already provided since theme alters are always invoked last.

mattew’s picture

I think we should simplify the alter hook, it should just override the version number, and all the logic with paths should be somewhere else.
If the jQuery Update provide a field to set versions by path, this code could be somewhere in this module. But if it's not a feature of the module for the moment, altering the version is enough and could be committed very soon.

In my case I would like to set a version regarding the Content Type of the current node, so using this hook I have to provide the path of the current node through the alter hook, so in my case it's a weird usage of this alter hook...

And of course, the alter hook should have another name if it's not based on path.

markcarver’s picture

Status: Needs review » Needs work

Given that this is introducing just an alter hook, I would say that this is CNW.

It's generally considered "Best practice" to only introduce an alter hook for a generic hook implementation for modules (e.g. calling module_invoke() for jquery_update_paths, hook_jquery_update_paths() and then the alter after).

That being said, I actually envisioned this issue also tackling what I said in #31. Specifically around providing some sort of conflict resolution and/or, at the very least, a message stating that one or more modules are in conflict.

Also, I semi-envisioned a module being able to declare a minimum (perhaps even maximum) jQuery version directly from their .info file. Granted, that wouldn't be specific to paths, but we could possibly introduce that as well via .info. Thoughts?

Suffice it to say, I believe this issue needs a lot more thought and work behind just a simple alter hook.


Re #47:
This issue is strictly about specific paths. I'm not sure opening it up to any arbitrary criteria is the best course of action ATM. I could be wrong, however from my experience opening up an issue to include everything but the kitchen sink makes for a very long issue.

That being said, perhaps I misread your comment and what you're saying is that we should also provide a generic "alter"? One that is executed after all the above logic is said and done? If so, that should definitely be a separate issue.

mattew’s picture

Yes, it's what I mean, of course a separate issue is required ;)

But behind that, an alter hook to provide a list of path is, as you will agreed I think, not very compliant with the usage of a alter hook. I mean, an alter hook is made for altering something, like some data provided to the hook, and here we pass an empty array and treat it right after that. An alter hook should be use to alter an existing behaviour, not creating a new one. It doesn't make sense to alter a feature which do not exists in the module, don't you think? Is this what you meant when you say that an alter hook should alter an existing generic hook? That's why I thought that the jQuery version number could be more suitable to be altered, than an empty array...

What do you mean about the minimum version in .info? It means that every path provided (through a hook_menu) for this module will use this jQuery version? Why not, but it sounds weird for me, I don't see any use case where it could be really useful.