Drupal CiviCRM Javascript Conflict

Installed CiviCRM in a fresh Drupal install, customized the CiviCRM and added data. The actual Drupal site was built separately in a separate install. Now that it is complete, I merged the CiviCRM with the new Drupal Site (files and database). Everything appears to work except when logged into CiviCRM: http://example.com/civicrm/dashboard it says:

"Javascript must be enabled in your browser in order to use the dashboard features."

And yes Javascript is enabled. The CiviCRM Menu is all broken and such. Chrome also reports the following errors:

Uncaught TypeError: Object # has no method 'menu' jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextArea开发者_StackOverflow中文版Resizer' main.js:6Uncaught TypeError: Object # has no method 'cycle' jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'

Javascript compression under performance is not enabled. Any ideas?

CiviCRM uses the jQuery object as cj instead of $ in order to avoid conflicts with the Drupal JQuery library. In theory, they are fine using different versions because they are namespaced differently (which jQuery supports officially using noConflict()).

The conflict you have probably comes from your modifications causing either Drupal or CiviCRM to load its jQuery library at a different point in the bootstrap, or making it try to load jQuery more than once. This would make the operation to convert $ into cj pick up the Drupal jQuery object after it has already been instantiated, rather than before, leaving Drupal and/or CiviCRM without the libraries it needs being attached to the $ object (are you using # instead of $?).

Search for all code that uses noConflict() everywhere on the page in question and its JavaScript includes. You should only find it in one place. Compare with the demo.civicrm.org pages to see the difference and you'll probably find an extra one in there somewhere. Best hope for fixing it is to adjust the load order of your custom modules in the Drupal system table, or else set the second noConflict() call to run conditionally on there not being a cj object already.

I've completed a bug report. Applying this patch resolved the problem for me in a seemingly clean way. This way the jQuery library does not get loaded more than once if not necessary.