Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
jQuery 1.6.1 shipped today and it includes a number of backwards-compatible fixes for stuff which 1.6 broke when upgrading from 1.5.2
Can we expect this to be included in the 7.x version anytime soon?
Thanks!
Comments
Comment #1
mfer CreditAttribution: mfer commentedThe answer is yes, this will be coming soon. The reason I've been holding off is I really don't like the current architecture. With the quick jQuery releases (2 since D7 has come out) we could be looking at a 10 - 20 jQuery releases during the D7 supported life. The current architecture / branch usage is not really ideal for dealing with these releases. I'm looking into a better way of handling this.
Something should happen soon though.
Comment #2
alexweber CreditAttribution: alexweber commentedCool, thanks!
Comment #3
Fidelix CreditAttribution: Fidelix commentedSubscribing...
Comment #4
timcosgrove CreditAttribution: timcosgrove commentedHi there-
I'm working on http://drupal.org/project/jquerymobile , specifically on finally upgrading it to be compatible with jQuery Mobile 1.0b1. Unfortunately this requires 1.6.1 or higher.
Are there any pieces of the architecture problem that can handed off? I would be very happy to help out with it, if it's a problem you can break up.
Thx!
Comment #5
timcosgrove CreditAttribution: timcosgrove commentedThinking about it, what I'm going to do is provide an older-style update of jquery_update to 1.6.1/1.8.14 (current as of today). That way we can at least update the module while you guys are working on the rearchitecture.
http://drupal.org/sandbox/tim.cosgrove/1209060
Will post interesting updates as they happen.
Comment #6
timcosgrove CreditAttribution: timcosgrove commentedhttp://drupal.org/sandbox/tim.cosgrove/1209060
This has jQuery updated to 1.6.2 and 1.8.14. Everything that did not come compressed from jQuery Foundation has been compressed with UglifyJS & UglifyCSS.
I have not yet done more than cursory testing; will be running that myself, but would also appreciate a hand. Commonly problematic things like Tabledrag seem to be working.
The patch is too large to attach, and Gist.Github won't accept it either; please use the sandbox project.
If this is not done correctly please let me know; happy to take correction.
Comment #7
Levi DeHaan CreditAttribution: Levi DeHaan commentedHey hows this going? I am willing to contribute if you can give me some info as to what problems your experiencing.
Comment #8
klonosDupe?: #1067290: Fix jQuery 1.7 for Drupal 6
Comment #9
alexweber CreditAttribution: alexweber commentedNope, this thread is specifically about Drupal 7.x and the other about 6.x
Comment #10
klonosThanx for taking the time to explain Alex. Don't mind if we make this a bit clearer in the issues' titles then.
Comment #11
sunThat's the reason why Libraries API was invented. ;) A more general, more flexible solution is the whole point of http://drupal.org/project/jquery
However, as long as jQuery module doesn't provide a proper way of doing this, I'd highly recommend to keep on doing what we've always done in jquery_update: New major version for a new jQuery version.
Comment #12
minorOffense CreditAttribution: minorOffense commentedSome items don't work with the link in #6. Namely select boxes on the fields UI. The Widget selector remains disabled so you can't choose a valid widget.
Comment #13
minorOffense CreditAttribution: minorOffense commentedThe reason (at least it seems to be the reason) some drop downs and selectors aren't working is due to an API change in jQuery. Namely they've split off the set/get of DOM properties and attributes (used to all run through .attr() ).
For example, if you look in the field_ui.js file, the select options are being enabled/disabled using the .attr() function. This is fine in any version of jQuery prior to 1.6.x
But 1.6.x would require this to be modified to
See http://api.jquery.com/prop/
Change Log http://blog.jquery.com/2011/05/03/jquery-16-released/
I would assume there are a lot of examples like this throughout the javascript libraries in core/contrib. It may make the update to 1.6 tricky.
Comment #14
ReneL CreditAttribution: ReneL commentedUsing .attr() for boolean (property) values was broken in jQuery 1.6.0, yes, but should have been fixed for boolean values (like 'disabled') in jQuery 1.6.1:
http://blog.jquery.com/2011/05/12/jquery-1-6-1-released/
A quick fix would be to just add an alias prop function for jQuery <1.6, this could be useful for non-contributed modules, too (but also dangerous):
http://docs.jquery.com/Plugins/Authoring
If-blocks in Drupal JavaScript code should be better, then every use can be checked and handled individually:
if(jQuery.isFunction(jQuery.prop)) {
} else {
}
Info and examples:
http://ejohn.org/blog/jquery-16-and-attr/
http://www.davidtong.me/upgrading-jquery-from-1-4-x-to-1-6-1/
I really hope that jQuery Update 1.6.2 will soon be released for Drupal 7, if help is needed please ask.
In the end we all have to live with jQuery 1.6.1+ and the separation of .attr() and .prop() anyway.
A quick search shows 72 occurences of .attr() in Drupal 7.7 (external jQuery libraries, plugins and jQuery UI not counted).
.attr('checked' : 9 times
.attr('id' : 12 times
.attr('action' : 3 times
.attr('target' : 5 times
.attr('href' : 7 times
.attr('tabindex' : 6 times (one { 'tabindex': -1 } use and one .removeAttr() use)
.attr('disabled' : 6 times
.attr('title' : 7 times
.attr('name' : 3 times
.attr('class' : 5 times
.attr('style' : 2 times
.attr('value' : 2 times
.attr('src' : 1 time
.attr('autocomplete' : 1 time
.attr('aria-autocomplete' : 1 time
.attr('role' : 1 time
.attr('maxlength' : 1 time
Comment #15
pbuyle CreditAttribution: pbuyle commentedThat's a huge and probably unsolvable blocker for any update to jQuery 1.6+. On a single project, I get more than 25
something.attr('disabled'[, <boolean>])
, some in major modules such as CTools, OpenLayers, Five stars.Looking at #1085590: Update to jQuery UI 1.9, it doesn't seems like a jQuery 1.6+ update is to be expected soon in an official release of Drupal 7. jQuery Update already has a mechanism to replace incompatible core's .js files and, if I remeber correctly, had already done so for Drupal 6. I guess the best option would be to work on replacement files in jQuery Update. This could help and be helped by #1085590: Update to jQuery UI 1.9 until but the D7 and D8 versions of the .js files start to diverge too much.
Comment #16
minorOffense CreditAttribution: minorOffense commentedLooking at the list in the changelog for 1.6.1 (thanks to ReneL for pointing that out, not sure why I didn't check there too...) the list of changes might not be too bad as just the 1.6.0 release would have made things:
http://blog.jquery.com/2011/05/12/jquery-1-6-1-released/
If you look at the list of items where they recommend one function compared to the other the list of items that should ONLY be used through prop isn't that long. Where you see two checkmarks that means both will work but prop is preferred. This however doesn't cover all cases, for instance the "autocomplete" attribute on form elements, I can't decide which to use.
I'm trying my hand at patching core to see if a dozen or so changes will work. I'll post the patch if it doesn't cause Drupal to implode on itself.
.attr()
.prop()
Comment #17
pbuyle CreditAttribution: pbuyle commentedGreat. But be careful, my understanding is that core patching should done on D8 as part of in #1085590: Update to jQuery UI 1.9. Only a D8 patch will get in. Once accepted, it can be back-ported to D7. Since contribs modules are also affected, I could take a long time before the update is accepted for D7. A comprehensive guide on what should be done to comply with the changes intoduced in jQuery 1.6+ would certainly help there. The other solution would be to replace the offending files with alternate versions provided by the jQuery Update module. But off course, patching core to test the changes is ok.
Comment #18
minorOffense CreditAttribution: minorOffense commentedYeah, I'm only testing things out and getting some feedback on whether I've patched all the correct items. I don't expect this particular patch to make it into Drupal.
If we get stuff working, then we can get a proper Drupal patch ready :-D
Comment #19
tmsimont CreditAttribution: tmsimont commented<aside>yikes! I'm surprised that this is the case. I love drupal, but D6 has been agony lately with it's old out-dated Jquery, even with the update module it's only 1.3.2 or something, which is embarrassing! Now D7 is out, and although I still don't consider it ready for deploy, because so many important modules haven't caught up, it only ships with 1.4.x?? And can't be upgraded past 1.5.x??? Weak! Perhaps in D8 some kind of bridge or adapter could be implemented between JQuery and the core js files to make swapping out JQuery versions a little smoother... in a perfect world... </aside>
How long would you expect it to take for d8 core to be patched and released with jquery 1.6.2 compatible files, and then be subsequently back-ported (just an estimate would be nice, not looking for a solid answer)?
Comment #20
berenddeboer CreditAttribution: berenddeboer commentedTim, get:
What's up?
Comment #21
minorOffense CreditAttribution: minorOffense commentedStill working on a patch to Drupal, and patches to other modules to work with 1.6.2
Running into odd UI bugs but they're easily fixed. I've also manually updated jquery_update to use jquery ui 1.8.15 and (obviously) jquery 1.6.2.
I think the best way to help move modules over to using .prop would be to include a sub module like "jquery_update_prop" which adds a jquery extension for 1.4.x and 1.5.x users. Allow them to start calling .prop in their code so the move over to full 1.6.x and beyond is smoother.
I'll do my best to package all this up into patches or as a sandbox project for people to have a look at and help out. Probably not until next week however.
More on all fronts soon...
Comment #22
klonosGreat news Mathew! Let us know ;)
Comment #23
pbuyle CreditAttribution: pbuyle commentedA patch for Drupal 8 has been proposed in #1085590: Update to jQuery UI 1.9 #88. D7 and D8 JavaScript are still pretty much the same so this patch is probably of some use here too.
Comment #24
c4rl CreditAttribution: c4rl commentedSubscribe
Comment #25
orendain CreditAttribution: orendain commentedSame issue checking out via git as #20.
Would love to help sync with the progress being made at core if we could get a working repository going.
Comment #26
minorOffense CreditAttribution: minorOffense commentedI've been playing with the patches from http://drupal.org/node/1085590 and they mostly work. There is a problem with the Field UI ( see http://drupal.org/node/1085590#comment-4962594) but it does work. A lot of other module UIs stop working though (Views, CTools, Panels) since the attr changes aren't reflected.
Their patch out-does the patch I had started, so I've been basing my work on that. I haven't found a good way to incorporate the patch changes into jQuery Update somehow though.
Comment #27
krem CreditAttribution: krem commentedAn update to the patch has been published http://drupal.org/node/1085590#comment-4990888, thank you minorOffense for the work you've done on it !
Just a question, when you say "A lot of other module UIs stop working though (Views, CTools, Panels) since the attr changes aren't reflected." does it means that those modules need to be patched or the jquery patch will be enough ?
Comment #28
pbuyle CreditAttribution: pbuyle commentedThe other contrib modules needs to be patched for Drupal 8 and jQuery 1.6+ to support the .attr/.prop changes. That's why "We must update the JavaScript update documentation to mention the new use of attr()/prop()" is a remaining task in #1085590: Update to jQuery UI 1.9.
Regarding usage of the incorporation of the patch in jQuery Udpate, because jQuery 1.6+ will not be in Drupal 7 core, jQuery Udpate will have to replace the JavaScript files from Drupal core and contrib modules with patched version.
jQuery Update already implements
hook_library_alter
to replace jQuery and jQuery UI. The same mechanism can be used to replace core and contrib JavaScript libraries. For non-library JavaScript files, I guess an implementation ofhook_js_alter()
could be used.The issue with this approach, is that jQuery Update will starts to contain a lot of JavaScript files that will need to be kept synced with the contrib modules they originate from.
Another solution would be to have jQuery Update expose a simple hook to implement by other modules willing to provides updated versions of JavaScript files with support for jQuery 1.6+.
Comment #29
MacRonin CreditAttribution: MacRonin commentedFrom my reading of #1386294: Release jQuery 1.7 for Drupal 7 it looks like there was a jump directly to 1.7.x Do you know if 1.6.x was also included (as an option)? I ask because Adobe's new software Edge (Preview release) seems to generate its code based on the assumption that you are running 1.6.2
Comment #30
alexweber CreditAttribution: alexweber commented@MacRonin I've been watching that thread pretty closely and as far as I can tell there is not going to be a 1.6.x release.
There have recently been some backwards-incompatible changes from jQuery 1.5+ for pretty much every big release (1.6, 1.7) and it's too much trouble to support every individual version. Latest and greatest only!
Comment #31
MacRonin CreditAttribution: MacRonin commentedThats's what I thought but figured it couldn't hurt to check
Thanks
Comment #32
klonostitle change to be in tandem with:
#1901672: Offer latest jQuery 1.9.x as an option (currently 1.9.1).
#2023789: Offer latest jQuery 1.10.x as an option (currently 1.10.2).
#1974482: Offer latest jQuery 2.x as an option (currently 2.1.0) - Fall back to 1.x for IE6/7/8.
Comment #33
klonos...assigning to the proper component after (part of) #2048923: Create separate entries for each jQuery and jQuery UI version in the project's "Component" drop-down. was implemented ;)
Comment #34
markhalliwellNot sure if this was done... needs to be checked.
Comment #35
markhalliwellSo apparently 1.6 was actually never added to this project and was skipped entirely... le sigh...
Comment #37
markhalliwell