Here for the community? On May 9th, we'll be in New Orleans. Don’t miss out!
No option for jquery 1.10 in the config page. Don't know if you planned on supporting this since its on the front page.
...well we first have to fix #1901672: Offer latest jQuery 1.9.x as an option (currently 1.9.1)., then this one here and then perhaps #1974482: Offer latest jQuery 2.x as an option (currently 2.1.0) - Fall back to 1.x for IE6/7/8..
...and this of course is either a task or a feature request - not a bug.
This is now fixed. Tested with Drupal Core, Overlay, Views UI, Field UI.
Panels, and Admin Menu issue.
admin_menu.js:223 TypeError: 'undefined' is not an object (evaluating '$.browser.msie')
panels.js:6 TypeError: 'undefined' is not an object (evaluating '$.browser.msie')
$.browser has been removed from 1.9.
I think that can be "fixed" by including the jquery migrate plugin... https://github.com/jquery/jquery-migrate/
We could add jquery-migrate but I mush rather fix those issues. I simple extra if ($.browser && ...) would fix that problem.
#2114587: Check if the browser object exist before trying to access property in it. (jquery 1.10 issues) This is the admin_menu fix.
Looking at panels now.
Panels -> #2114599: Stop using $.browser.msie without checking for $.browser.
Any other issues we can probably fix them rather easily.
Automatically closed - issue fixed for 2 weeks with no activity.
1.11.0 is out:
PS: I'm not sure if we need a new "jQuery 1.11.x" component entry (#2048923: Create separate entries for each jQuery and jQuery UI version in the project's "Component" drop-down.), so I'm sorta hijacking this 1.10.x issue for now. If we decide to keep all 1.1x.x versions under a single "umbrella", then perhaps rename the "jQuery 1.10.x" component to "jQuery 1.1x.x" component.
@klonos that deserves its own issue. This one has been fixed.
Yeah, I thought we'd (re)use these "Offer latest jQuery x.y.z as an option" issues for the life cycle of each major version in order to keep the "noise" in the queue down. So re-open when a new minor/patch version of a major version is released and then close once we update the stable or dev to include it. Re-open as more minor/patch versions are released and re-close once we include them and so forth...
Let me know if you still insist in having separate issues even for patch version increments and I'll do that.
PS: sorry for re-opening this one; I don't mean to piss you off, it's simply that I don't know if you filter closed issues out of your queue and I'm afraid you might miss my reply. Anyways, as I said let me know and I'll file separate issues in the future.
Different module maintainers handle things differently, but usually one issue will result in one patch being committed (with perhaps a small followup if there was a mistake in the first patch).
Changing the meaning of an issue (from add 1.10 to add 1.11) can make it confusing to read, as historical comments no longer make sense (e.g. #4 on this issue). It's also confusing when people refer to issue numbers, e.g. I found this issue from #2111061: Tag a 7.x-2.4 release which listed this as an issue that needed to be fixed before it could be released - but that's obviously not true if the meaning of the issue is changed.
Sorry for taking long to open a new issue. Here it is: #2197249: Offer latest jQuery UI 1.11.4
Drupal is a registered trademark of Dries Buytaert.