Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 3.4.5
-
Fix Version/s: 3.4.7
-
Component/s: Core CiviCRM
-
Labels:None
Description
Attached is a working fix that resolves the awfully hackish jQuery noConflict() code for CiviCRM with Drupal 6. The right way to use multiple versions of jQuery is to load the newer version first, then run noConflict() and use the alias to access that newer version. CiviCRM does use an alias to attempt to do a noConflict, however it's doing it all wrong. It allows Drupal;s older jQuery to load first, then completely stomps it by just loading it's own jQuery and JQuery UI right on top. Then it assigns itself a no conflict references and releases control of $. This is pointless because it's already stomped in the built-in jquery. Finally it inexplicably calls noConflict AGAIN in the middle of the markup. Again no idea what this is for but it's not actually helping anything. This more or less worked for core drupal, but sites using the Drupal jQuery update or jQuery UI modules were doomed.
None of this is a problem with Drupal 7 because it gracefully noConflicts itself; as long as other apps leave the jQuery reference alone all is well.
This attached patch re-orders the scripts in page preprocess to load the Civi jQuery and jQuery UI libraries first, then calls noConflict() properly. It also removes the noConflict() reference in drupal.tpl as well as the CRM_Utils_String::loadJqueryFiles (or some such don't remember the function name). All Civi jquery that uses the cj reference (as all Civi jquery should) will continue to work just fine.
Two caveats that bear testing: I don't run Joomla so I haven't tested it. Since this patch affects the string utility method it may impact Joomla. Second, I haven't tested profile HTML snippits.
Attachments
1.
|
Fatal error accessing Drupal My Account | Done/Fixed | David Greenberg |
|