jQuery update not replacing js files in Drupal 6

There is a problem with the jquery_update.module file.

Prior to jQuery 1.3.2, all the header information was in the form:

/*
 * jQuery 1.2.6 - New Wave Javascript

jQuery Update was matching on the number to see if it should override Drupal's included JS file.

Since v1.3.2, the header information is now in the form:

/*
 * jQuery JavaScript Library v1.3.2

The pattern matching fails and the module reverts to Drupal's default jQuery file.
The correct replacement pattern should be:
$pattern = '# \* jQuery JavaScript Library v([0-9\.]+)#';

This replacement should be done in the file jquery_update.module, line 91.

also getting this problem on a clean d6.16 install. The file doesn't get replaced and continues to use the version packaged with core (1.2.6).

It didn't do anything for me either until I loaded the jQuery release itself:

From the jQuery UI module readme.txt http://drupalcode.org/viewvc/drupal/contributions/modules/jquery_ui/READ...

-- JQUERY UI 1.7 --

The jQuery UI module uses jQuery UI 1.6 because jQuery UI 1.7 requires at least
jQuery 1.3, which is not shipped with Drupal 6. If you absolutely need to move
to jQuery UI 1.7, you can get around this by doing the following:

* Install the jQuery Update module appropriately from:
http://drupal.org/project/jquery_update

* Download the latest jQuery UI 1.7 release from:
http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.7

* Replace the old jQuery UI folder with the 1.7 package at:
/sites/all/modules/jquery_ui/jquery.ui/
so the actual jQuery UI JavaScript files are located in:
/sites/all/modules/jquery_ui/jquery.ui/ui/*.js

The update was required by the Modal Frame API module which reported the problem on the status page until I uploaded the jQuery release itself.
This may be a bad hack though; I'm not sure.

I am using jQuery Update, jQuery UI, and tabs without any issues. So, I cannot reproduce this.

To replace the jquery files jQuery Update does use a hook_preprocess_page() call that is theme registry altered to be the last one called. If one is being called after that or something else is affecting $scripts after that the replacements won't happen.

jquery_update is not replacing .js and keeps 1.2.6 version.
It was working for me on first linux server with php 5.2 and when I tried to put it on second server with php 5.3 the jquery.js is not replaced and also Admin menu 3.0alpha4 is not working. I got an JS error "b.support is not defined" if this helps.

When I tried to uninstall and install jquery_update on my first linux server the same problem occured. Now I have 2 servers without jquery replaced and I can't get it working?

had the same problem. changed jquery_update.module, line 91 as suggested by ceptyr in #2 - no luck. then I found that the jquery version in folder jquery_update/replace was still the 1.2.6. I replaced it with the current jQuery file and now it works.

I'm using 6.19... still the same problem with Jquery Update. I tried updating line 91 as suggested, flushed all cache, etc. but no go. All of the replacement files within the replace folder were also of the newer version. So I can only opt to manually replace the file in the misc folder.

Same here. Module is not replacing the 1.2.6 version.

Same here! I'm using Jquery UI and I downloaded 1.7 into jquery.ui but I'm not sure if this caused it since I did not check before that. Disabling jquery UI does not solve the problem.

I'm on Drupal 6.19

Subscribing

I think I'm having similar problems. I've installed and enabled the module. I've used the config interface to select 'minified' as recommended but jquery isn't being updated. Is there a way of kicking off this process? What am I missing? - Still stuck on 1.2.6. I Need to get up to 1.3.

After doing some reading around the subject it seems like this is probably the correct behaviour given 6.16's JQuery version limitations. Irritating, but not the fault of this module.

The same behavior - module installed, cron run, cashe flushed, js files are the same. Jquery 1.2.6. What to do?

This seems to be a regression in version 2.0 branch?

Check my solution earlier for the code to update.

I can confirm that, whatever the version of jquery_update used, core jquery is not overridden.

Flushing the caches seems to break it (most of the time) and running updates seems to fix it (seems to be all the time). Anybody know what to make of that?

As previously mentioned, the _get_version function looks at the comments at the top of the js files to determine their versions. The problem is the same pattern is used for all files (including the default), but the format differs from file to file (list follows):

• * jQuery 1.2.6 - New Wave Javascript
• jQuery JavaScript Library v1.3.2
• jQuery JavaScript Library v1.7.1
• /*! jQuery v1.7.1 jquery.com | jquery.org/license */

The versions are checked when the caches are flushed, and if the version checks fail (return an empty string), the jquery_update_replace configuration variable is set to false, preventing the module from later performing the replacement.

I initially went with a single pattern that would work with all four of the above formats (jQuery.+([\d\.]+)), but have since switched to multiple patterns in hopes of making it easier to append additional formats in the future.

I came up with
$pattern = '# * jQuery [a-zA-Z\s]*v([0-9\.a-z]+)#';
before reading this issue, your solution might be more future proof?

I now see that my expression wouldn't capture the New Wave Javascript format, although I'm not sure if it should, considering the jquery_update module is (probably) not going to offer < v1.3 anymore?

The module uses the same pattern to find the default version (misc/jquery.js), so it can be compared against that of the available replacements. It only makes the replacement if the replacement version is higher.

I suspect that this check is unnecessary, as the version bundled with Drupal isn't likely to change, but I wanted to alter the functionality of the module as little as possible.

I also ran into this issue, and at first wondered what on earth was going on. Suddenly after a cache clear I got 'max recursion' errors in jquery.js, then I noticed it was still using the original drupal version of jquery.js.

This patch did help things, but needed another cache clear to completely fix it. So a +1 for me on this patch.

I was also having this issue. After I flushed the caches the new versions would show up fine, but after cron ran it would revert to the core jquery.js.

Patch in #23 works great for me so far...
I'd vote for getting this into the 2.0 branch ASAP.

Same issue, patch in #23 solved issue for me!
Marking RTBC...

Cheers

Same issue when deployed to production, patch in #23 fixed it.

good job.

Same issue for me. Patch #23 works great. Thanks!

Same issue. Patch #23 works

Drupal 6.23

Did #7
And in jquery_update.module,v 1.5.2.2.2.8 2010/04/23 replaced on line 99 with the code from #2

$pattern = '# \* jQuery JavaScript Library v([0-9\.]+)#';

It worked only a while and the problem came back.

Patch in 23 worked for me.

I am curious though, why is this module is comparing version numbers anyway? This module knows which version of jQuery it provides and what comes with core. It is intentional to install this module and provide the specific jQuery(s) it comes with. This is unnecessary and (apparently) harmful logic that should be removed.

I agree with #33. There is no reason to try to parse the version from the file since the module ships with jquery included. Adding all this logic just for the case when people 1 - have installed a different version of jquery than the one which ships in the module and 2 - use another module which does a hook_requirements check for the jquery version, seems to be a poor design choice. I can see why it might have been made at a time when the module was intended to allow you to install any version of jquery you needed, but that's not how things ended up.

Disable the version check by changing row 125 to this:

variable_set('jquery_update_replace', true);

Agree with #34, let's get rid of this regex.

Core's version of jQuery doesn't change very often historically. Therefore, I don't see the harm in adding a constant that sets this for jQuery update.

If at some point core's version changes, this could be refactored into a switch statement that looks at the VERSION constant. That's just the cost of doing business.

Regex is gone, this should simplify things.

Forgot to update the install file.

#23 works perfectly also with pressflow 6.28. Great work - Thumbs up!

This was driving me mad trying to update an old website... Let's commit #38, works great and I'm pretty sure it's a better approach. Plus taking out regex shizza makes me happy.

I made a separate patch at #1061242: jQuery not updated to 1.7 when compression is enabled, but obviously this thread is bigger and more people have confirmed it solves the problem. +1 to the solution here too. More efficient and solves the problem directly.

Marked this one duplicate too: #1459286: jquery_update_get_version not working. Patches everywhere!

This issue still happens in Drupal 6, using latest jquery_update dev (attempt to use 1.7). Current Drupal 6 still uses 'New Wave Javascript' pattern. Patch in #23 worked for me.

I, too, see the same issue happening on D6 and latest jquery_update dev. I manually applied the patch in #23 and it worked.

My .info file reads as follows, matching the latest of the 6.x development branch shown with an Oct 1, 2013 date on the project page.

What I see is this issue is marked "Reviewed & Tested" - and yes, that's true. But on the issues list this one is shown as green, even though the patch hasn't been rolled into any tarball much less a -alpha release.

name = jQuery Update
description = Update jQuery and jQuery UI to a more recent version.
package = User interface
core = 6.x

; Information added by drupal.org packaging script on 2013-09-30
version = "6.x-2.0-alpha1+7-dev"
core = "6.x"
project = "jquery_update"
datestamp = "1380584084"

Bump? :)

Bug in the install file, this should do the trick.

BTW, doing a full "Flush Caches" on the site will reproduce this problem. The admin_menu module has a nice Flush Caches feature to do this. Once the cache has been flushed, you have to go back to the jQuery Update settings page and press Submit to get the replacement files working again.

I applied the patch in #46 and it fixes the problem perfectly. Looking good! This approach is preferred since as pointed out in #38, the core version will never change.

Confirm that flushing caches reproduces the problem.
Confirm that #46 works great.

Almost in time for the 5-year anniversary of the issue. :)

I hate to be that guy to ruin 5 years of work ... but the patch in #46 causes a white screen of death if you also use the Advagg module.

E_ERROR Error in file "advagg_js_cdn.module" at line 48: Call to undefined function jquery_update_get_version()

So it would be far safer if jquery_update_get_version() was not removed and then the install file would not have to be modified either.

That should be an issue in the advagg queue. I don't think other contribs should block progress here.

Maintainer: Please apply patch #46 since that was RTBC.

The patch you are asking to commit to this module is guaranteed to break advagg along with any other module that may have called jquery_update_get_version, a public function that the patch unnecessarily removes. It causes a complete white screen, a critical error which obviously should not be committed. That makes it this module's problem.

As I have demonstrated with the patch in #50 you don't even need to remove that function nor change the install file to achieve the exact same result without breaking anything else. Your way, we have to find and inform every other module that may have called the function to change their code or just let them break and annoy loads of people. I don't see the downside of using the newer patch.

I realise you are probably frustrated because of how long this issue has dragged without a commit. I hate it when that happens too. But instead of being defensive and dismissive you could contribute even more now by confirming that the patch I posted works and then changing this to RTBC.

Your way, we have to find and inform every other module that may have called the function to change their code or just let them break and annoy loads of people

We should at least mark it as @deprecated http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutoria...

--- sites/all/modules/jquery_update/jquery_update.module	(revision 2167)
+++ sites/all/modules/jquery_update/jquery_update.module	(revision )

This wasn't made from the drupal.org repo, so it can't be applied. Otherwise "sites/all/modules" wouldn't appear.

Drupal 6 reached EOL (end-of-life) on February 24, 2016.