michaek [michaek]

As there is a feature request for jQuery Update, why didn't you create a patch for that project?

What does the proposed module to assure the compatibility between the jQuery library that comes with Drupal, and the jQuery library hosted on Google?
When a new version of jQuery is released, there is also a compatibility file that needs to be loaded in order to assure compatibility with the JavaScript code that uses the previous version of the library.
The problem is that a module built for Drupal 6, in example, knows the version of jQuery included with Drupal, and it uses JavaScript code compatible with that version; if the jQuery version can change, modules for Drupal 6 that use JavaScript code could stop to work.

The module doesn't attempt to insure compatibility with Drupal's jQuery - yet.

That is probably the reason jQuery Update doesn't use the version of jQuery hosted from Google; it is difficult to insure compatibility without to know the version being used.

The fact the module doesn't insure compatibility with the existing code is the main reason the proposed module would create issues with the existing code.

I'm not sure I follow - the purpose of jQuery Update is to use a different version of jQuery than the one shipped with Drupal - not to maintain compatibility with all other modules.

That is not exact. jQuery Update loads the jQuery file, and it loads also a file that assure compatibility between the version of jQuery shipped with Drupal, and the version of jQuery used by the module. The included file is the compatibility file released from the jQuery team.
Of course, it loads it if such file has been provided; not all the new versions of jQuery required that file to be retro-compatible.

For example: administrators would be warned if they selected an incompatible version of jQuery. Does that sound like a good approach?

That is good approach too.

The module should warn the administrator user that he selected a version that creates problems with the modules currently installed. I am not sure how you accomplish that, but without that users would probably continue to use jQuery Update.

I am not convinced that there is the need to have such module, but if Drupal 7 would be able to load jQuery from Google servers, than the module could be seen as a back port of Drupal core code and that would make more sense.
I am not also sure that your module could be better of the code already implemented in jQuery Update.

There have not been replies from the OP in the past 7 days. I am marking this report as won't fix.

Displaying a warning for versions of jQuery that may be incompatible with other modules seems like a good idea. Not every site uses modules that would be effected, so loading compatibility plugin would be unnecessary overhead on some sites. And for those who are using modules where this would be an issue, the warning would make it clear.

The benefits and drawbacks of using Google-hosted jQuery are specific to individual site contexts, not something that can be determined for every Drupal site in this thread. I think I'm pretty familiar with the issues, and I would use this module on some sites, but not on others.

loading compatibility plugin would be unnecessary overhead on some sites

As Drupal uses the same JavaScript code in all the sites, it's more probable that or there is incompatibility with all the sites, or there are not incompatibility problems.

I am changing the status back to needs work as I have not seen yet new code.

As Drupal uses the same JavaScript code in all the sites, it's more probable that or there is incompatibility with all the sites, or there are not incompatibility problems.

That's a good point. I had assumed newer versions of jQuery wouldn't conflict with the relatively simple jQuery in Drupal core, but it's worth testing rather than assuming. I've tested this module on a Drupal 6 install with a few contrib modules enabled, and found nothing broken with jQuery 1.4. This wasn't a comprehensive review of all jQuery in Drupal core, so I'd encourage others to try it and identify actual problems this module can cause. We shouldn't assume there are problems any more than we should assume there aren't, as it's impossible to definitely solve hypothetical problems. (Maybe there's a problem the compatibility plugins don't catch.)

Another thought: this module in its current form is useful for testing contrib modules against different versions of jQuery without compatibility plugins, which is especially useful right now as we're testing against an uncertain version (without compatibility plugin) in Drupal 7. It may be valuable enough as a development tool to be worth keeping the compatibility plugins out.

Some versions of jQuery came with a compatibility file that allowed to code using the previous version of the library to still be working with the new version; some versions of jQuery didn't have such compatibility file, but that doesn't mean that such file should be needed in future.

kiamlaluno, I think you maybe misunderstood my comment. I wasn't suggesting newer versions of jQuery should be allowed without compatibility plugins because that happens sometimes already. I was suggesting it should be allowed because 1) there's been no evidence presented that this causes a problem with Drupal core(and some limited testing suggests maybe it doesn't, and 2) there's an obvious use case for testing modules against incompatible versions of jQuery, i.e. preparing for whatever version might be in Drupal 7. You didn't really respond to either of those points.

there's been no evidence presented that this causes a problem with Drupal core

It's not just a matter of Drupal core; there are also all the third-party modules.

My point is that between this module, which doesn't include any compatibility files, and jQuery Update, it is still preferable jQuery Update.
To notice that jQuery Update provides compatibility files for Drupal 6, which are not provided by the proposed module (see the list of JavaScript files replaced by jQuery Update).

The choice is between a module that changes the jQuery library used from Drupal with one loaded from Google servers, and one that changes the jQuery library used from Drupal with one loaded from a local directory. I think that the similarity of purposes makes the proposed module a duplicate of the already existing module.

There are already plenty of modules in CVS that can't be used together with specific settings, and the community generally solves this problem with warnings in the modules about known incompatibilities. Why can't this module do the same thing?

There are already plenty of modules with some overlap, e.g. geo and location, mollum and captcha, global redirect and path redirect. The Drupal community has proven able to choose between these modules, despite the overlaps, because they solve distinct problems. Why can't we do the same here?

While there is some overlap, this module does something substantially different from what jQuery Update does: allow loading from a central server, and without the compatibility plugins that prevent jQuery version testing. The limited overlap should not prevent the community from using the differences.

Which module currently in Drupal CVS allows me to test my custom Drupal code against jQuery 1.4.1? Which module allows me to point to the URL for jQuery 1.2.6 most likely to already be in my visitors' browser cache, increasing load speed on my site?

I believe no module in CVS currently solves these problems, and these are problems some people in the community (e.g. myself and presumably michaek) want to solve on some of our Drupal sites. This module solves these problems. The community should be allowed to make that choice, not have it made for them.

Which module currently in Drupal CVS allows me to test my custom Drupal code against jQuery 1.4.1?

If you need to test your Drupal code against jQuery 1.4.1 (which should be done on a test site), it is enough you copy jQuery 1.4.1 into the directory were Drupal keeps its jQuery library (and backup the previous file).

I am not going to debate this any further. There are some criteria about the accepted CVS applications; whatever reason you can find, this module is duplicating another module functionality (considering that its purpose is to replace the jQuery library used from Drupal with another one version), and that case is listen in Apply for contributions CVS access.

kiamlaluno, I understand you think it's a duplicate module. I'm saying it's not, and that you have misunderstood the purpose of the module. But you don't seem to be willing to change your understanding at all, so there's nothing I can do to help here. Nonetheless, I'd still like to help add and improve this functionality in Drupal. Is there any process for appealing your decisions on CVS applications or do you have the final say over everything?

you have misunderstood the purpose of the module

I do not have any misunderstanding about the purpose of the module. The purpose of the module is clear, as it is the purpose of jQuery Update; from wherever the jQuery library is taken doesn't make any difference because for the final user the result is that the jQuery library will be replaced with a different version.

michaek, if you want to upload a copy of the module with version change option removed (defaulting to 1.2.6), that should make it easier to focus this review on the primary purpose of the module: loading jQuery from Google.

After it gets into CVS (when it's clear the work won't be wasted), I'd be happy to help re-introduce other jQuery versions hosted Google in a way that defers to jQuery Update for the actual version control, removing any concern about duplication.

There have not been replies from the OP in the past 7 days. I am marking this report as won't fix.

@michaek: As with other issue queues, you don't get any notifications, if you don't subscribe to your issues in this queue (the link is to subscribe to your issues in this queue).

As per requirements, the proposed project must not duplicate the work done by existing projects; by work, the requirements page doesn't mean the code.

@michaek I agree it's hard to understand what @kiamlaluno is objecting to, but please help improve the situation so other would-be contributors won't have to jump through as many hoops in the future. If you can upload your code with the changes you've described, that should remove any claim to duplication. And then you can change the status to "needs review", forcing a review of specific code rather than unclear objections.

I'd really like to use this module (enough to make the project myself if this doesn't work out), and I'm sure others would as well, but because Drupal.org is where people go to find Drupal code, any other host will never be found by many potential users.

@michaek I completely agree. Two things you may or may not already know:

1) Drupal is in the process of moving from CVS to git, with an eventual goal of more open sandbox access before moving into some sort of "recommended" status with an approval process like this, which would make it easier for more people to get involved in these reviews. So it's still important to improve the approval process by clearly demonstrating its flaws as you're doing here, but those flaws should be reduced in the future as a result of more people becoming involved.

2) This review process only applies to the first module. Once you have a CVS account, there is no required review for additional modules. That's part of the reason this is so restrictive, but also why it's kind of worthless, as there are other ways of getting CVS accounts which completely bypass this review, e.g. by becoming a co-maintainer on an existing project. Many leaders in the Drupal community never went through this process and aren't familiar with how it can discourage valuable contributions. That's part of why I'd really like you to force the issue by uploading modified code, as this thread is an excellent example of how the review process sometimes hurts Drupal more than it helps.

Oh, I didn't even notice you'd already uploaded new code. Awesome.

I have created a separate module (accidentally) that broadly does the same thing but is maybe more flexible, it can be found here:
#835794: chrism2671 [chrism2671]

I've reviewed this module and found no substantial issues.

Oh that's interesting. I can see why they might want to take that out- indeed my module is almost a line by line duplicate of yours! Congrats on getting a successful review, looks like it's going to go into the repository!

@chrism2671, if this does get approved, I suggest you open an issue under the new project requesting to be a co-maintainer, as you obviously have an interested in the project.

That said, "reviewed & tested by the community" status is no guarantee this will get approved. @kiamlaluno may still find some reason to reject it, and it's really only his review that matters, as no one else in this thread can actually create the CVS account.

The proposed module will likely not duplicate http://drupal.org/project/jquery_update, but will very likely duplicate http://drupal.org/project/jquery

That said, jQuery module is far from being ready. It may help to have such a (working) module as template for related jQuery module work (there's an issue about external CDN support already).

Seems kind of wrong to deny a CVS app because it might duplicate functionality described in a feature request created months after the CVS app was submitted to a module itself created months after the CVS app was submitted.

Seems kind of wrong to deny a CVS app because it might duplicate functionality described in a feature request created months after the CVS app was submitted to a module itself created months after the CVS app was submitted.

See my comments; this application has not been yet approved (which is different from denying it) because there is already a module that allows to replace the jQuery library given with Drupal with a different library version, which is the purpose of the proposed module.
From where the replacing library is taken doesn't make any difference, IMO; the library could be output from the module directly, but the purpose of the module doesn't change.

Access granted. Thanks Michaek for sticking with the idea.

I really agree with the perspective of sreynen in this issue.

Subscribed.