Introduce hook_jquery_version_alter()

Is this related? #1524944: Allow different version for administrative pages

I needed functionality like this so I ended up adding another setting so that certain paths will be excluded entirely from update.

Here's a patch.

ok. That was a little hasty. I decided to throw in the classic choice between either excluding a set of paths or only including that set. Here's the updated patch.

Although #2 is related, #4 gives the eventual result in a much simpler way.

Excellent patch @markisatacomputer - +1 to get this into dev version of jquery update.

#4 Perfect, I really think this is how this module should be for 6.x

Here's the patch for D7, totally based on #4

don't forget to change the path
--- L:/LASAC/DEV/SITES/sites/indepressie.localhost/

patch which will give an admin setting so user can set path to exclude 1.7

patch which will give an admin setting so user can set path to exclude 1.7

Is there a way to only update jQuery for one particular theme? A Mobile theme? I'm working on a site that is stuck on Drupal 6, and I'm using theme switcher to provide the mobile experience http://examplesite.com?theme=mobiletheme. The Mobile theme version, does not need to have admin functionality or even node creation (for this particular site). They just want a really slick interface for searching and displaying content, so to run jQuery Mobile I would like to update only the version of jQuery when that theme is active? Could this be achieved with this module by adding something like active theme? Although I'm using theme switcher, there are other use cases for wanting jQuery to be updated different based on the theme, jQuery mobile being one of them.

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

Patch in #8 with correct paths.

This is a great addition to jquery_update. I vote for it being included.

I combined both #11 and #4 together in this patch, adding an exception that the exception paths may still be an empty string, in case someone wanted to only specify fallback paths and not exclude updating jQuery altogether.

This patch may not seem like an important one at first, but let me just say this issue has frustrated me for awhile now. Drupal 6 is still running several sites but there are many cool plugins out there that need jQuery 1.7, so there had to be a way to use jQuery 1.7 when you needed it and keep 1.3 when you don't need it, or just exclude updating altogether. This also solves many issues experienced at #1067290 At least these two features give Drupal 6 developers easier control to fix jQuery through this popular module.

I believe this issue is still relevant, as the patch in #16 has never been applied to the jquery_update repository.

I can see this patch is against D6. Do we need to roll it against D7?

An alternative approach for D7 is available at #2181095-2: Disable jquery update for admin path option in settings.

I had issues with aliases but the change is minor (look at line 11)

$excluded = drupal_match_path($current_path, $update_exceptions) || drupal_match_path($alias_path, $update_exceptions);

So now if you have a content type where it's alias is post/* like on our sites this will still work.

I needed to add the alias path.

Just modifying the title to prevent misunderstanding with #1548028: Make the default jQuery version (1.4.4) for D7 an option

is there a patch for the latest version? i need to disable it on the node/add path, as it's conflicting with hierarchical select

Is there a patch for 2.4 ? i wanted to disable jquery update in the front page

We are moving in a different direction.

Actually I closed this one prematurely, sorry. There is specific use cases: #2309163: Exclude alternate jquery version for certain pages.

Forget this patch, I added duplicated stuff and didn't work for me. I'm gonna create a new one.

Attached a new patch that solves the issues. Now you can exclude an administrative path from the alternate version and use the selected default. In frontend, if the path it's excluded then 'default' will be used.

Just a crazy idea here, so bear with me. There are so many different types of modules that break because Module A was built on 1.7 and Module B was built on 1.8. Module C was built on 1.4 (core) and it doesn't matter what version one chooses, if you have a ton of modules that all work differently, they certainly don't always work together.

Now my immediate "solution" would be to just say to Module A, B and C: "Update your module to work with the latest jQuery version". How realistic is that though?

The patch is pretty straightforward. Based on the toggle, it will either only include or explicitly exclude matched paths. That is an all or nothing approach.

What if we simply had a way to support any version for multiple paths? For example (I do not actually know off the top of my head what jQuery versions these modules support, FYI):

/**
 * Implements hook_jquery_update_paths_alter().
 */
function views_jquery_update_paths_alter(&$paths) {
  $paths['admin/structure/views/*'] = 'default';
}
/**
 * Implements hook_jquery_update_paths_alter().
 */
function context_jquery_update_paths_alter(&$paths) {
  $paths['admin/structure/context/*'] = '1.6';
}
/**
 * Implements hook_jquery_update_paths_alter().
 */
function features_jquery_update_paths_alter(&$paths) {
  $paths['admin/structure/features/*'] = '1.9';
}

We could even provide a message to users warning them when multiple modules have defined the same path that have conflicting versions. This would be a better indicator that these two modules should work together or at least one of them should update their minimum supported jQuery version.

#30 works for me. Thanks.

Patch on #30 works for me too. However I see a big problem: If I want to exclude paths for administration pages, I cannot have different jquery version for admin pages and for frontend pages. So I'm forced to select "Defaul jQuery version" on administrative pages select.

Maybe we could have two different exclusion fields: one for admin and another for frontend pages.

@rcodina see my configuration in screenshot. It works for me.

Seems to me that #31 is the beginning of a good solution. But the hook should be implemented by each modules themselves.
jQuery Update would give access to the different versions and continue to give essentially the sames options it has been giving (front-end, back-end and updates), taking care that the default versions are drupal core safe. While each modules and theme would call the specific version in their implemented path.

#30 works for me as well. Thanks.

I'm really not in favor of #30, especially now that #1969244: Specify jQuery version per theme has been committed. Has anyone taken a look at the proposal in #31 aside from @paean99?

But the hook should be implemented by each modules themselves.

Agreed and my example shows that (context, features, views) these would all be provided by the module themselves. If it were jquery_update providing them, it would look like jquery_update_jquery_update_paths_alter() since the hook (module name) is HOOK_jquery_update_paths_alter().

I would, however, suspect that for certain modules, like Views, we would need to provide initial support until an actual patch for the module can be made, committed and then released. Given that Views is in core now (D8), the contrib version seems (to me) like it's taken a back seat in D7... so I'm not entirely sure this will happen?

Sorry, you are right.
I misunderstood your post and it was sufficiently clear :(

There is a related module at https://www.drupal.org/project/jqueries

This module allows multiple versions of jQuery instances loaded on the same page. Maybe some of its code could be adapted to the needs of this ticket. To change jQuery Update for specific paths.

Any volunteer? We would be happy to contribute Quality Assurance and documentation.

Just ran into this issue myself on a project. While #30 resolves the immediate issue, #31 is a more flexible solution. I think it's a great idea.

Attaching a patch that implements #31 with a drupal_alter(). This should allow other modules to change the jquery version by path. Note that this setting will still defer to the theme setting that is new in 7.x-3.x.

Hmm, looks like there's not much sense in making a path override if it doesn't also override the theme setting (since the theme setting would always override the path setting).

Here's an updated patch that addresses this.

Here is a properly formatted patch (the precedent one had the full path hard-coded) and add a test for "current_path" so an internal path scheme may be use.

@majorrobot, thanks for your patch. Next time you may follow drupal.org guidelines to supply a patch.

Hmm, looks like there's not much sense in making a path override if it doesn't also override the theme setting (since the theme setting would always override the path setting).

Correct. If a module implements hook_jquery_update_path_alter and it still doesn't work for a theme, then the theme can also implement the alter to override what the module already provided since theme alters are always invoked last.

I think we should simplify the alter hook, it should just override the version number, and all the logic with paths should be somewhere else.
If the jQuery Update provide a field to set versions by path, this code could be somewhere in this module. But if it's not a feature of the module for the moment, altering the version is enough and could be committed very soon.

In my case I would like to set a version regarding the Content Type of the current node, so using this hook I have to provide the path of the current node through the alter hook, so in my case it's a weird usage of this alter hook...

And of course, the alter hook should have another name if it's not based on path.

Given that this is introducing just an alter hook, I would say that this is CNW.

It's generally considered "Best practice" to only introduce an alter hook for a generic hook implementation for modules (e.g. calling module_invoke() for jquery_update_paths, hook_jquery_update_paths() and then the alter after).

That being said, I actually envisioned this issue also tackling what I said in #31. Specifically around providing some sort of conflict resolution and/or, at the very least, a message stating that one or more modules are in conflict.

Also, I semi-envisioned a module being able to declare a minimum (perhaps even maximum) jQuery version directly from their .info file. Granted, that wouldn't be specific to paths, but we could possibly introduce that as well via .info. Thoughts?

Suffice it to say, I believe this issue needs a lot more thought and work behind just a simple alter hook.

---

Re #47:
This issue is strictly about specific paths. I'm not sure opening it up to any arbitrary criteria is the best course of action ATM. I could be wrong, however from my experience opening up an issue to include everything but the kitchen sink makes for a very long issue.

That being said, perhaps I misread your comment and what you're saying is that we should also provide a generic "alter"? One that is executed after all the above logic is said and done? If so, that should definitely be a separate issue.

Yes, it's what I mean, of course a separate issue is required ;)

But behind that, an alter hook to provide a list of path is, as you will agreed I think, not very compliant with the usage of a alter hook. I mean, an alter hook is made for altering something, like some data provided to the hook, and here we pass an empty array and treat it right after that. An alter hook should be use to alter an existing behaviour, not creating a new one. It doesn't make sense to alter a feature which do not exists in the module, don't you think? Is this what you meant when you say that an alter hook should alter an existing generic hook? That's why I thought that the jQuery version number could be more suitable to be altered, than an empty array...

What do you mean about the minimum version in .info? It means that every path provided (through a hook_menu) for this module will use this jQuery version? Why not, but it sounds weird for me, I don't see any use case where it could be really useful.

Here's a patch that can be used to create a hook to alter the jquery version. I used this and a custom module doing jquery_update_version_alter and added this code inside that:

  $path = current_path();
  $path_alias = drupal_lookup_path('alias', $path);
  $patterns = 'node/add/*' . PHP_EOL . 'node/*/edit';

  // If page path equals node/*/edit or node/add/* change version to 1.9.
  if (drupal_match_path($path, $patterns) || drupal_match_path($path_alias, $patterns)) {

  $path = current_path();
  $path_alias = drupal_lookup_path('alias', $path);
  $patterns = 'node/add/*' . PHP_EOL . 'node/*/edit';

  // If page path equals node/*/edit or node/add/* change version to 1.9.
  if (drupal_match_path($path, $patterns) || drupal_match_path($path_alias, $patterns)) {
      $version = '1.9';
  }

This checks to see if the node is either being edited or it's a new node being created and if so it sets that page to jquery 1.9.

Here's an updated version of the patch that moves this in front of the ajax portion of the code so that ajax will pull from the hook for it's version of jquery first instead of overriding the value we're supplying in the hook.

I'm still not convinced this is actually necessary. The above example indicates that the node edit page is different from the "default theme" (i.e. node view). Thus, this is a change that can be easily made on a per theme basis.

That being said, I would say that this issue has evolved as it's no longer really about "paths" at all, but rather a generic alter hook.

What logic one decides to do in that alter hooks is really up to them, even if it doesn't really make sense to me...

---

Regarding the actual patch:

1. This is going to need some API documentation so IDEs can link the alter hook properly.

2. +++ b/docroot/sites/all/modules/contrib/jquery_update/jquery_update.module
   @@ -94,6 +94,9 @@ function jquery_update_library_alter(&$javascript, $module) {
   +    drupal_alter('jquery_update_version', $javascript, $version);
   

   Passing $javascript is completely unnecessary. This is only about altering the jQuery version that will be used.

3. I think the hook should really be jquery_version instead of jquery_update_version, e.g. hook_jquery_version_alter(&$version), as this isn't about altering the jquery_update module version, but the framework version itself.

4. moves this in front of the Ajax portion

   Historically speaking, alter hooks are always at the end of "X", because you are altering whatever original logic determined the value to provide. This would/should include the ajax version here.

   If this needs to be accounted for, I would say that we should also pass $context = ['ajaxPageState' => $ajaxPageState] along with the alter hook so users can utilize this information however they need to.

Whoops, wrong title

#52 still needs to happen...

Explicit title

This patch should resolve #52.1, #52.2 and #52.3.

See #3312045: Plan for jQuery Update 7.x-4.0 release.