I'm often getting into trouble with jquery update on Drupal sites, so one of the important features of that module is that it allows me to use old versions for specific modules, e.g. views.

Had you considered something similar here, or is that too complicated? I think most of the time, the trouble comes with administrative interfaces, so your goal of reducing the page load time and number of copies of jQuery on public facing pages is still meaningful and valuable.

Alternatively, is there another approach to the problem whereby you turn off the civicrm inclusions of jquery and leave jquery_update to be correctly configured with the right version? Or for real bonus points, how about civicrm checks if the right version of jquery has been/is going to be included by Drupal and doesn't if that's the case?

I think it's a bit more complicated than this because of the different namespaces, but you probably know how to work around that issue already.

Comments

adixon created an issue. See original summary.

colemanw’s picture

colemanw CreditAttribution: colemanw commented

Sigh, Drupal and CiviCRM both have some interesting ways of making things a lot more complicated than they need to be, don't they?

CiviCRM, to its credit, is at least fully compatible with the latest version of jQuery. Drupal core is too (except for the overlay module, but I worked around that with a shim). That same shim might help a few other modules not crash, but you're right there's still a large gap.

In my ideal world, the solution would be to update those old modules to be compatible with jQuery 1.10. Anecdotally, I tested this module out with webform-civicrm and it took about half an hour to update its jQuery compatibility. So if there's just one module crashing with this one, might be possible to submit a patch to fix it?

colemanw’s picture

colemanw CreditAttribution: colemanw commented
Status: Active » Closed (won't fix)