New jQuery UI release system

What are the permissions on the jquery.ui folder?

Shouldn't the folder be sites/all/modules/jquery_ui/jquery.ui?

So, you extracted the file jquery-ui-personalized-1.6rc5.min which produced a directory called ui. Then, you renamed that directory to jquery.ui and put it in the jquery_ui folder. Is that correct?

I am also facing the similiar problem!
I am developing the site on localhost.

same problem here--localhost

Same problem here on localhost .. BUT it is user error... admittedly the docs are a bit ambiguous.

First Create the jquery.ui folder with the jquery_ui module directory
You need to unpack the entire jquery.ui-1.6rc5 package into the sites\all\modules\jquery_ui\jquery.ui folder
The entire pack containing other files most importantly the ui folder.
Do not rename or move the ui folder!
Most importantly make sure the ui folder is within the jquery.ui folder which is within the jquery_ui module folder

sites\all\modules\jquery_ui\jquery.ui\ui

Ah, the problem is that the jquery ui package from ui.jquery.com has changed it's contents since the last release of this module. Fixing the problem you describe is happening in another issue.

well it left me with a big mess ?
i could not turn of or do anything with the other module components
like gui / gui tabs / jquery ui
the only thing that i could deal with was the update module unmarked and uninstall
the rest only way to deal with it was to remove it totally with out being unmarked etc.
i can only hope that this does not leave me with probs that i can not see (yet) ?

so guess i have to do with out all of it for now
lol

p.s. ui directory / folder ?
no such number no such name

On jqueryui.com, they feature a new release system which selectively packages your downloads for you. This patch refers the user to the Google Code project, which packages all the files, instead of an all-in-one .js file.

A better approach would be to simply make the module work with the new release system.

The attached patch does exactly that, however it only supports the new system. While I think that is the way it should be, I would have no trouble re-writing it to support both methods if required.

#13 works for me

I prefer RobLoach's solution here, since the latter removes the entire possibility to load only certain components, which is plenty of overhead for the majority of sites.

However, the download URL should point to

http://code.google.com/p/jquery-ui/downloads/list?q=1.5

so it displays all "current releases" for 1.5, but still marking the featured one.

The reason I opted to allow the new packages is that the latest release (1.5.3) of the older style packaging does not work due to changes related to ui.core. #376325: ui.core.js not minified or packed in UI release

This solution would allow for the user to make the choice whether the wish to use the older or the newer packaging system, but ultimately the decision is yours.

I noticed the dependency removal for jquery update. jquery update provides the config form for change between minified, packed, and uncompressed.

@mfer: Thanks for mentioning this!

I guess, this means that jquery_ui could still work without jquery_update, but if jquery_update is enabled, it's not using the (to be defined - minified?) "default".

Also, we discussed in IRC today, that we want to merge RobLoach's and Deciphered's patch.

Updated the patch as discussed.

Changes are as such:
- Documentation in README.txt updated (with minor alterations).
- URL in Install error updated.
- Dependency on jquery_update removed.
- Support for new packaging system added.
- 'jquery.ui' folder automatically created with '.placeholder' file to simplify installation.

Note: Changed RobLoach's URL to http://code.google.com/p/jquery-ui/downloads/list?can=1&q=1.5.2 as the Google Code version of 1.5.3 does not work due to #376325: ui.core.js not minified or packed in UI release.

This worked well for me... Thanks for finding the correct link.

Minor update: URLs reverted to Rob Loach's previously supplied now that #376325: ui.core.js not minified or packed in UI release is fixed.

The UI team is up to 1.6RC6, which if you haven't read the blog will turn into 1.7 once it goes final, should be soon. Will this patch work with the 1.6RC or the new 1.7? Or will this only work with 1.5.3 final? Since 1.7 is almost final I'd like to use that instead as it brings in the support of the new jQuery 1.3.

smcguinness: It will only work with jQuery UI 1.6.x because jQuery UI 1.7 requires at least jQuery 1.3 (Drupal 6 comes with jQuery 1.2.6). To following Drupal 7's shipment of jQuery 1.3, take a look at #350275: Update to jQuery 1.3.2.

I got rid of the ".placeholder" file as it's not really Drupal standard to support dot files in the CVS. I replaced it with a README.txt as either package doesn't have a README.txt.

Please also understand that I still strongly suggest that we only support the developer package from http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.5 instead of the one .js file package as I only see providing two download URLs as confusing to people who want to install the module. Providing both methods will only give us support requests later on as well as more code to maintain. It also means that the jQuery UI module API could be used inappropriately as loading in any plugin will mean also loading in the whole jQuery UI framework. Again, that patch is at #11.

In the end though, I don't really care and just want to be able to use the jQuery UI framework again. It's really up to Daniel to do what he thinks is best. Thanks.

Whoops, wrong patch.

Good job. Slightly optimized patch attached.

However, I did not know that the packages from http://jqueryui.com/download are personalized/customized. That, we will not support. All we can support is the _full_ jQuery UI package, i.e. including ALL optional components. This means that there either has to be a download link for the full package, or we drop the support for the bundled package.

Bear in mind that if we can keep it, a smart developer will know how to trick a personalized/customized bundled package into the system anyway. Personalized packages, however, will lead to countless support requests - and I'm not speaking of jQuery UI's issue queue, but many other issue queues on drupal.org.

Note: We should incorporate some other URL changes into this patch, as noted in #372346: documentation link correction. Thanks.

I've got error applying patch:

jquery_ui # patch < jquery_ui-HEAD.download.patch
patching file README.txt
patching file jquery_ui.info
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file jquery_ui.info.rej
patching file jquery_ui.install
patching file jquery_ui.module
patching file COPYHERE.txt

Manually removed dependency.

- dependencies[] = jquery_update

Both these patches have fallen behind the release state of jQueryUI somewhat. Here's a summary with some suggested changes:

Documentation:
jQueryUI 1.5.x releases are no longer available from jqueryui.com, any references to 1.5.x should refer users to code.google.com. However since jQueryUI 1.6 should work with the jQuery 1.2.6 currently in core it's probably better to just refer to 1.6 and drop 1.5.x support.

State of and differences between packages:

The 1.6 and 1.7.1 packages downloaded from code.google largely keep everything where jquery_ui.module expects them to be, with the exception that the 1.7.1 package no longer has a 'packed' version of the scripts, only minified.

The 1.6 (legacy), 1.7.1 (stable) direct download links and customized versions you can create on jqueryui.com:
- don't contain packed (which means they'll break if 'packed' is selected in jquery_update)
- do have uncompressed modules in a development-bundle subfolder
- do have version.txt in the development-bundle subfolder (which means jquery_ui.module currently fails to install if you try to use these packages as is)
- don't have per jquery module minified versions, instead they have a single monolithic minified file at, for example, js/jquery-ui-1.7.1.custom.min.js
- (note that the patches above refer to 'personalized' packages, looks like they're now 'custom'.)

Assuming (as per IRC discussion) two branches, and the need to support custom packages from jqueryui.com:

6.x-1x-dev
would be for jQueryUI 1.6
would not need to depend on jquery_update module
would need documentation updates for the correct package to download
would need logic to differentiate between the code.google and jqueryui.com packages:
- is packed available
- is minified monolithic or per jQueryui module
- is version text at jquery.ui/version.txt or jquery.ui/development-bundle/version.txt

6.x-2x-dev
would be for JQueryUI 1.7.x
would depend on jquery_update 6.x-2x-dev
would need documentation updates for the correct package to download
would need to allow for that fact that 'packed' is no longer available (just use minified?)
would need logic to differentiate between the code.google and jqueryui.com packages:
- is minified monolithic or per jQueryui module
- is version text at jquery.ui/version.txt or jquery.ui/development-bundle/version.txt

Much of the code is in place in the patches above, but needs some tweaking, and IMO this does need two branches as described.

I inherited a real hairy monster here. I see the new release system in action. For a lot of things it looks great. But, these modules need a rewrite. There is the development branch with the different files and then the one custom file with everything in it.

I've updated jQuery Update 2.x branch to only have the minified and uncompressed versions.

The 6.x-1.x-dev branch still depends on jQuery Update for the form to choose the compression type.

Thanks for the update, adrinux.

My vote is still to just use the latest stable 1.6 legacy release. Then you get every individual file, and let Drupal aggregate it correctly for us. Still the original patch at #11, with an update from "1.5" to "1.6"....... K.I.S.S.

@Rob Loach Any thoughts on moving forward when we can't grab the release from google code?

And my vote is still to add support for both release types.
It's never wrong to give the user the choice, and it would just be silly not to support the official (legacy) release from the official website. Plus, as my patch has proven, it's really not that difficult to do.

The only reason, IMHO, to not support the jqueryui.com release would be if you implemented the ability for the code.google.com version to be automatically downloaded and extracted on install.

Cheers,
Deciphered.

As long as http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.6 allows to download jQuery UI in the way we want/require it there's no need to think about alternatives.

Compared to #25 and #11, I'm not sure whether I did additional optimizations in my patch in #26. By removing the added logic for the personalized package (we won't support) and updating the version number in the download link it should be good to go.

@Deciphered:

I did not know that the packages from http://jqueryui.com/download are personalized/customized. That, we will not support. All we can support is the _full_ jQuery UI package, i.e. including ALL optional components. This means that there either has to be a download link for the full package, or we drop the support for the bundled package.

Plain simple reasoning: You download module A, which requires ui.draggable. Fine, you build your personalized package and are done. Later on, you install module B, which requires ui.sortable. But hey, jQuery UI tells everything is alright and properly setup, so WHY IN HELL IS IT NOT WORKING!?... — jquery_ui module has no idea which plugins are contained in the personalized package, but other modules may rely on it.

All we can support are two different packaging types – the entire library with all plugins bundled in one file or all files separately. The former makes only sense for sites that use at least more than 50% of all jQuery UI plugins and effects. All others are better served with the usual JavaScript aggregation.

We can argue both ways as much as possible, and neither sides are likely to budge, but I will try once more to make my point with a lot of generalizations.

User experience:

• Users will not read the readme file, nor should they be expected to, and will likely not read the error on the screen, they will just expect the module to work out of the box, as it should.
• When they discover they have to download the jQuery UI, they will think to go to jqueryui.com - the official site - or google 'jQuery UI', not goto code.google.com, even when told to do so.
• Supporting the official release will mean less confusion for the user and less support requests for the developer.

I was talking to someone in the IRC support channel the other day, he'd spent over an hour trying to figure out why he couldn't get the jQuery UI module to work.
He'd spent time reading over the Issue queue, getting frustrated, spent time downloading multiple different versions of jQuery UI, etc. By this time it didn't matter that someone could help him by pointing him in the right direction, he'd already decided that the module was too much work and not worth it.

I understand that from the developers point of view the official jqueryui.com release is not nearly as efficient as the code.google.com release, but if people can't even get the module working it doesn't really matter which is more efficient and which isn't.

I honestly hope that someone who hasn't set their mind on ignoring other opinions will take my thoughts into consideration.

Cheers,
Deciphered.

@sun

Plain simple reasoning: You download module A, which requires ui.draggable. Fine, you build your personalized package and are done. Later on, you install module B, which requires ui.sortable. But hey, jQuery UI tells everything is alright and properly setup, so WHY IN HELL IS IT NOT WORKING!?... — jquery_ui module has no idea which plugins are contained in the personalized package, but other modules may rely on it.

I'm not denying this is an issue, but to base that as the reasoning not to support the official version of jQuery UI seems short-sighted, it simply needs to be taken into account while searching for the perfect solution.

Just a thought, not backed up by research, but how about we go about that issue like this:
If it is detected that they are using the official release a few checks are performed, the checks will determine the particular packages in the personalized package. If a module requests a package that is not installed, information will be provided to the user and the module informing them of the issue.

Example: jquery_ui_func_exists('ui.core')

@mfer Any thoughts on moving forward when we can't grab the release from google code?
When is that ever the case? Surely it's always available there?

@Deciphered I was talking to someone in the IRC support channel the other day, he'd spent over an hour trying to figure out why he couldn't get the jQuery UI module to work.
#29 above was the result of an entire morning trying to get it to work! I eventually succeeded. And yet I'd still side with Rob Loach and Sun on this - a single right way to install leads to clear instructions on the module download page, in the readme and in error messages. I think we should point directly to the right download on code.google and not support the bundled versions on jqueryui.com.
Building in support (and proper error messages) is certainly possible, it just makes the jquery_ui.module much more complicated for little apparent gain.

Taking in the recent comments, a revised list of what needs doing to get this module back into shape (I plan on working on this today).

6.x-1x-dev branch
would be for jQueryUI 1.6
would need documentation updates for the correct package to download
(basically Rob's #11 patch updated for 1.6)

6.x-2x-dev branch
would be for JQueryUI 1.7.x
would depend on jquery_update 6.x-2x-dev (which has jQuery 1.3)
would need documentation updates for the correct package to download

These small changes should make the module easy to install again, and keep up to date with jQueryUI development. I should have patches done this afternoon.

Ok, here are two minor patches:

The first (jquery_ui_6.x-1.x-dev-version-docs-update-1.patch) is for the 6.x-1.x-dev branch (and hopefully a quick 6.x-1.3 release) and makes the following changes:
-- Correct the link* for jQueryUI library download (in readme, and installation error message).
-- Hopefully clarifies the installation directory name
-- Corrects the link to the API documentation
* I've linked specifically to jQueryUI 1.6 since I believe it'll be the final release in 'legacy' 1.6.x series.

The second (jquery_ui_6.x-2.x-dev-version-docs-nopack-update-1.patch) is for the suggested new 6.x-2.x-dev branch (partners with jQuery_update 6.x-2.x-dev) for jQuery 1.3 and jQueryUI 1.7, and makes the following changes:
-- Correct the link* for jQueryUI library download (in readme, and installation error message).
-- Hopefully clarifies the installation directory name
-- Corrects the link to the API documentation
-- Removes the 'packed' compression case, since that's no longer provided by jQueryUI and has been removed from jquery_update-6.x-2.x-dev
* the link lists the most recent releases in the 'stable' 1.7.x series

The module project page would also need updated to reflect these were they committed.

Let me just point out that I already investigated whether there would be any way to auto-detect which exact plugins are contained in a personalized/customized library when I posted #29. Back then, there was no way - aside from loading the entire file into memory (_the entire_) and doing some nasty regular expression magic to try to determine plugins on very certain *function* strings _somewhere_ in the file - an approach that is very likely to fail and would need an enormous amount of time to code and maintain.

Cross-posted.

Btw regarding module releases: jquery_update and jquery_ui modules are closely tied, so I would suggest to jump from 1.x to 3.x in jquery_ui's major version (for jQuery 1.3 compatibility), so the major versions are in-line with jquery_update — see #442998: Fix the project release mess.

I once needed to make a similar major version decision (for modules depending on Wysiwyg API) and did not go with correlating major version numbers. Something I regret today. It's much easier for users to understand that jQuery UI 3.x works with jQuery Update 3.x.

Alright, I'll concede for the time being, it's clear that arguing is not going to speed up this much needed work.

@sun,
While I didn't look into auto-detection, I would have thought something like the following would work:

if ($.isFunction($.draggable())) {
 //
}

But as I said, I haven't tested it, and it's beside the point anyway, just simple curiosity.

Cheers,
Deciphered.

@Deciphered: The issue with that approach is that it runs/works on the client-side. Other "consuming" scripts can't safely rely on jQuery UI -- and all other scripts would have to wrap their code into this condition to prevent JavaScript errors in the first place. We have to ensure that jQuery UI is available on the server-side already to determine whether requirements are met.

@sun

That does make sense. While technically you could have the client side check run on install of jQuery UI and set variables via AHAH to determine which plugins are available, I can understand that client side is never as reliable as server side.

After looking around I think we should NOT use the prepackaged scripts from jqueryui.com. If we use the packages from Google Code we can control what files are included. For us, with the JS aggregator, it's not that big of a deal because we end up with one file in the end anyway.

This means we need documentation on whey we are grabbing it from one place and not another. We might want to include some code to detect the version from jqueryui.com and let them know they need the other version.

This would be more straight forward. Trying to support the jqueryui.com packaged releases will be a nightmare all around drupal.org. There are bound to be more issues. In the interest of support I would think we don't support them.

Updates to jQuery UI 1.6, as well as provides links to the development bundles instead of the unsupportable customized packages. Also provides instructions on how to use jQuery UI 1.7.

@Rob Loach: I have granted you commit access.

Just one minor nitpick before you commit:

-2. Download the "Development bundle" of jQuery UI from
-   http://ui.jquery.com/download.
+2. Download the latest jQuery 1.6 development package from:
+     http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.6
 
 3. Extract it as a sub-directory called 'jquery.ui' in the jquery_ui folder:
-
      /sites/all/modules/jquery_ui/jquery.ui/

Let's use blank lines before and after those "values" (i.e. leave 3. as is):

+2. Download the latest jQuery 1.6 development package from:
+
+     http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.6
+

Aside from that, push the button. I'm not sure about the current branches in jQuery UI, but it would be good to make sure that all affected branches are updated.

In case we're not yet co-maintaing something (sorry, no time to look that up currently), please follow http://drupal.org/node/363367 - especially regarding commit messages and changelog (for this issue). Thanks!

I got something for you guys to update for your next release...if you're not too lazy ;)

In your README, you tell people who want to add a single file to pass a string as the argument, like this:
jquery_ui_add('ui.sortable')

And then, in your module file, in the source for jquery_ui_add, you have this:

// Convert file to an array if it's not one already, to compensate for
// lazy developers. ;)
if (!is_array($files)) {
  $files = array($files);
}

@nrgamble,

That has nothing to do with this issue, while it may be a valid request it belongs in it's own issue.

Cheers,
Deciphered.

http://drupal.org/cvs?commit=214894

I have been trying to do thgis for 4 hours... I dont know... its feb 2010.... What Am I missing? Im using 1.7x...

why does the this require the module directory to be installed in the site directory? Thats what messed me up for hours. Out of all the modules I have installed in Drupal... this is the only one so far with that requierment. Shouldnt this module follow the standard drupal module and include the module in sthe standard druppal modules directory!@!@!@!@!@!???????

AntiNSA,

All drupal modules should be installed in /sites/all/modules unless you are running a multi-site configuration or you have specific reason to place them elsewhere. You should never install a contrib module in the /modules directory, that is for core modules only.

For more information, refer to http://drupal.org/getting-started/install-contrib/modules

Also, as your issue seems to have nothing to do with this particular issue, I am re-closing the issue and would be grateful if you could open a new support issue if you are still unable to get the module to work.

Cheers,
Deciphered.

Hello
I need the module JQuery for my site, but I can't download the latest jQuery UI 1.6 development package from:
http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.6
because I don't have access.
I need that somebody send me this file to my email beacuse within this module, I can't work with my web site.

Thanks

You can, but by default the featured downloads are selected, so version 1.6 doesn't show up...

change that option or try this link:
http://code.google.com/p/jquery-ui/downloads/list?can=1&q=1.6&colspec=Fi...

So the difference is the 'can' query parameter that needs to be fixed in the README.txt:

http://code.google.com/p/jquery-ui/downloads/list?can=3&q=1.6 is empty (current link)

http://code.google.com/p/jquery-ui/downloads/list?can=1&q=1.6 works

You're right, I didn't look to the whole link to spot the differences.

I don't know if a new issue is in order to correct this, nevertheless here is a patch, fixing the link to version 1.6 and 1.7.

Added patch to #879446: Updated link for jquery 1.6 since is a clean issue, marking this as a duplicate.