Option to limit Jquery Update scope to front end only

+1

Is it possible to only perform jQuery update to the front end?

This would amount to jQuery Update settings per theme. On sites that don't use Drupal's built in jQuery UI and ajax features, replacing with the latest jQuery on the front end theme could be nice. There would be a performance hit for site owners/ authenticated users though, having to download two versions of jQuery. Couldn't hurt as an option though.

Great idea. This has to be an option.

A workaround

/**
 * Implements hook_module_implements_alter().
 */
function hook_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'library_alter') {
    // Move jquery update to the end. This will make sure our hook_library_alter
    // is always called before the jquery_update.
    $jquery_update = $implementations['jquery_update'];
    unset($implementations['jquery_update']);
    $implementations['jquery_update'] = $jquery_update;
  }
}

/**
 * Implements hook_library_alter().
 */
function hook_library_alter(&$libraries, $module) {
  // If it is an admin path all we want to do is change the global $conf
  // variable so when jquery_update runs right after us it will use 1.5.
  if (path_is_admin(current_path())) {
    // Modifying global $conf variable, can be dangerous. Be carefull.
    global $conf;
    $conf['jquery_update_jquery_version'] = '1.5';
  }
}

gagarine,

Cool technique! Works well for me.

Thanks for sharing,
Chris

cpliakas, I toke the time to write a blog post about http://antistatique.net/blog/2013/01/04/drupal-use-a-different-jquerys-v... hop that's help some peoples.

Cool, thanks gagarine, this works for me.

Hi, I'm using this to allow block-like path selection for replacement

Updating status

Note: The patch in #8 works for me

Marking this as a duplicate of #1524944: Allow different version for administrative pages

I've pushed #1524944: Allow different version for administrative pages back to Needs Work so the path functionality from this issue can be merged into it.

The workaround in #4 works pretty good for me, but we ran into fatal errors when deploying this to the test server combined with features and drush -fra, because the hooks were invoked before jquery_update was enabled. Here is an improved version of the workaround which prevents that problem with module_exists('jquery_update').

/**
 * Implements hook_module_implements_alter().
 */
function hook_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'library_alter' && module_exists('jquery_update')) {
    // Move jquery update to the end. This will make sure our hook_library_alter
    // is always called before the jquery_update.
    $jquery_update = $implementations['jquery_update'];
    unset($implementations['jquery_update']);
    $implementations['jquery_update'] = $jquery_update;
  }
}

/**
 * Implements hook_library_alter().
 */
function hook_library_alter(&$libraries, $module) {
  // If it is an admin path all we want to do is change the global $conf
  // variable so when jquery_update runs right after us it will use 1.5.
  if (path_is_admin(current_path())) {
    // Modifying global $conf variable, can be dangerous. Be carefull.
    global $conf;
    $conf['jquery_update_jquery_version'] = '1.5';
  }
}

@muka Thanks for the patch! The workaround posted in #12 did not work for me

workaround in #12 works great, but only if placed in a custom module, not in template.php

@muka Thank you for the patch! works!