Libraries API

+    module_load_include('module', 'libraries');
+    module_load_include('module', 'jquery_ui');

That should probably just use drupal_load(). Aside from that, this looks ready to go.

Though - to commit this patch, we need a release of Libraries API first...

A dev release for libraries API is out since june 22.
What are we waiting for?

Having these big jquery libraries in my modules folder will slow down the modules page, unless I use a patch - so I rather don't use the module until this is fixed.
#546584: Modules or themes with too many files kill drupal_system_listing performances

Here's the updated patch. Still waiting on any kind of stable release for the libraries API...

Hi,

when applying the patch against jquery_ui-6.x-1.x-dev, I'm getting:

# patch < 489140-jqueryui-librariesapi-D6.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

Contents of jquery_ui.info.rej is:

# cat jquery_ui.info.rej
*************** name = jQuery UI
*** 3,5 ****
  description = Provides the jQuery UI plug-in to other Drupal modules.
  package = User interface
  core = 6.x
--- 3,6 ----
  description = Provides the jQuery UI plug-in to other Drupal modules.
  package = User interface
  core = 6.x
+ dependencies[] = libraries

Looks like a minor issue...

Greetings, -asb

Subscribing.
Hope it could be commited in next DEV release.

Subscribing.

subscribe

subscribe

I would love to see that in a near future :)

Subscribing. Thanks for the effort.

Here is a patch that works against 6.x-1.3 for those who want to use it now.

Here is the same patch as above but without needing -p so it can be used with drush make.

Thanks! Could you re-roll with diff -up, please?

Subscribing.

Forgive me to draw attention. Please revert back to 'by design' after the confirmation.

So what should I do best for live now? Wait for jquery get a release, use the jquery_ui, or libraries with the patch? Any confirmation for the future sake would be very much appreciated.

Thanks to all.

I suppose I should preface this with something like...

This is all my personal temporary work - I'm putting it here because the final applicable patch that I had to create myself to get things working was a modified version of the patch posted above
This patch needs work to even merit any real consideration - it should at least lose the dependency on JQuery_Update's admin options to set Development mode
This should all be superseded by the JQuery module when it is ready, I would STRONGLY recommend waiting for it - you've been warned!

WARNING: JQuery UI 1.8.x requires JQuery 1.4.x... and you WILL have trouble running JQuery 1.4.x on D6 without at least one core patch!

Now that I've said that... I had a fun time of getting this all working, and while the above patch for making things work with the Libraries API, it needed a bit of adjustment to work with JQuery UI 1.8.x

Because I know someone else is going to try it, I'll go ahead and outline all the problems I've run into so far:

http://drupal.org/node/775924#comment-2871902
- There is work being done on backporting D7's JSON encoding back to D6, but I'm unsure of its status at the moment... look for links to the relevant D6 issues in the issue above
- an alternate solution WHICH IS DEFINITELY A BAD IDEA! is to replace this function with its D7 equivalent
(I believe the requirement for this is PHP5 possibly 5.2.9? otherwise the backport patch works for D6 reqs I think?)

http://drupal.org/node/775924#comment-2928232
- JQuery_Update needs to be updated to work with JQuery 1.4.x, the patch to tabledrag.js from D7 can be applied to the tabledrag.js that JQuery_Update implements (in replace/)
- There may be more issues with this that have yet to be found, this is, after all, stuff from D7 - a VERY hacky workaround is discussed later in the above linked issue comments
- The D7 issue queue is linked in here this issue too, for the daring that are attempting this, I would strongly advise checking there! More problems probably lay in wait! :p

And finally... if against all odds, you've managed to get JQuery 1.4.x to some semblance of working... you will come to find that the proposed patch to JQuery_UI has some issues with JQUery_UI 1.8.x:
- If we want to use a non-single-file version of JQuery_UI, we need a few more includes in 1.8.x, at least 'ui.widget' and 'ui.mouse'
- JQuery 1.8.x uses a new naming structure in the default downloads, which needs to be supported unless you want to have to have several duplicate copies around to support old modules
- Feels like we need an admin option for the single file Libraries API type approach, vs the separated files JQuery_UI module expects

My approach to solving this was as follows:
- Without JQuery_Update providing the compression (none) option (ie using the Libraries API patch to JQuery_Update which removes this option), it will default to merged file implementation
- When an applicable JQuery_Update variable is available, if set to Development (compression: none) it will use split file implementation and attempt to correct for JQuery UI 1.8.x includes
(WARNING: I've probably missed some required includes! I'm far from experienced with JQuery UI, and only got things working for core Drupal and my personal configuration! See, don't use this ;)

And finally the patch, with one more reminder... don't use this! I needed to document my work and figured someone might benefit from this, but you've been warned, repeatedly!

Any timeline on when jquery ui will incorporate the Libraries API? I'd do it myself, but I'm not there yet.

Libraries module is still alpha, and I would not like to install it only because of this module dependency, if you do commit this, I hope you will keep optional.

Maybe a starting point would be to accept that sites/all/libraries is A Good Place(tm) to put external dependencies like this and just make sites/all/libraries/jquery_ui the default location? Then maybe work on having optional libraries.module support?

+1 to DamienMckenna's suggestion.

This Just Makes Sense.

Let's please go with #24 now rather than waiting for a non-alpha version of Libraries. WYSIWYG has been doing this for at least a year, and it's a pretty big deal because anyone using Drush will see the jquery.ui folder completely wiped out any time they do an update if it resides inside the module's folder.

I guess I agree. However, jquery_ui should look up both locations, i.e., when supporting sites/all/libraries (and only sites/all/libraries, no other conf paths), then still support to put the files into the module folder. Or in other words, maintain BC.

That's most probably going to be all that will happen regarding Libraries API within this project. http://drupal.org/project/jquery is the place to discuss and integrate everything else.

While I would really like to use libraries API for jquery_ui (and have been running a modified version of the patch above for a few weeks), this issue becomes a little problematic because date module's date_popup expects to find a jquery.ui folder inside the jquery_ui module.

To me, the best solution seems to be to abstract the jQuery path determination into a function that other modules could use... and convince maintainers of other modules, specifically date, to use it.

There have been several references to http://drupal.org/project/jquery -- however, the code there is very old and the issue queue not very active. Is there something happening off-site or behind the scenes related to that module?

You can already place the folder extracted from jquery.ui-1.6.zip ("jquery.ui-1.6") into the sites/all/libraries directory right now, without having to wait for official support of that path or the Libraries API module (which has already an alpha1 release). Then just rename the "jquery.ui-1.6" directory to "jquery.ui-1.6", go to the module's directory (sites/all/modules/jquery_ui) and symlink:

[root@www jquery_ui]# ln -s ../../libraries/jquery.ui .

subscribing

While the new jquery module is released, this patch adds the BC required by sun, working with or without the libraries module.
It even allows the use of a new jquery_ui_get_path() function in contrib modules (like the date popup module) when they need to know about the jquery ui path.

Looks good to me. With a confirmation from someone else this should be RTBC.

How about adding an extra check to jquery_ui_get_path() to see if "sites/all/libraries/jquery.ui" exists, i.e. the path it would be under given the libraries API standards? That way we don't have to have an alpha-level module in use but can still benefit from a clean directory structure?

function jquery_ui_get_path() {
  static $jquery_ui_path;

  if (isset($jquery_ui_path)) {
    return $jquery_ui_path;
  }

  if (function_exists('libraries_get_path')) {
    $jquery_ui_path = libraries_get_path('jquery.ui');
  }
  elseif (file_exists('sites/all/libraries/jquery.ui') && is_dir('sites/all/libraries/jquery.ui')) {
    $jquery_ui_path = 'sites/all/libraries/jquery.ui';
  }
  else{
    $jquery_ui_path = drupal_get_path('module', 'jquery_ui') . '/jquery.ui';
  }

  return $jquery_ui_path;
}

Less duplication of a fixed string:

function jquery_ui_get_path() {
  static $jquery_ui_path;

  if (isset($jquery_ui_path)) {
    return $jquery_ui_path;
  }

  if (function_exists('libraries_get_path')) {
    $jquery_ui_path = libraries_get_path('jquery.ui');
  }
  else {
    $fake_path = 'sites/all/libraries/jquery.ui';
    if (file_exists($fake_path) && is_dir($fake_path)) {
      $jquery_ui_path = $fake_path;
    }
    else {
      $jquery_ui_path = drupal_get_path('module', 'jquery_ui') . '/jquery.ui';
    }
  }

  return $jquery_ui_path;
}

There was a missing space after the "else" in the patch from #31 above.

Here's a proper patch for my code from #34 above.

Added the great idea from @DamienMcKenna, but swapping the order as the most usual it would be the standard default libraries directory, saving a more expensive libraries_get_path() call.

Subscribing.

Subscribing

This would make my workflow SO much easier. Subscribe.

subscribe

sub

Please, please please just allow sites/all/libraries as an alternate location. Every time I do a $drush pm-update jquery_ui, this library is wiped out... and I don't realize until a few days later, when users complain none of their widgets are working!

Any word on then libraries support will be added to jquery-ui ?

subscribe

Over 1 year gone on this one and people on d.o. still complain about the numbers of forks happen....

... or people stopping to provide help or patches due getting frustrated over exactly this.

Just chose other maintainers or co-maintainers if your are to busy to do this.

This module already has three maintainers - are you volunteering?

It would vastly help if there was a solid and valid patch.

Thank you sun.

subscribe

Thanks for reporting, reviewing, and testing! Committed to 6.x-1.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Awesome, awesome. One less module to have in my 'needs special update procedure' notes.

Well, attention: Obviously, the patch has not been tested at all. If committing entirely untested patches is the only way to get any feedback other than complaints or subscribes, then be it.

Sun, DamienMcKenna, and other who have worked on this -- thank you for patching. I hadn't seen your contribution until now. I've implemented the latest patch. While it is functioning correctly, there is a residual error in the error message of the /admin/reports/status page. When the library directory 'jquery.ui' is misnamed or misplaced, the error message still says "The JQuery_UI plugin is missing Download and extract it to your jquery_ui module directory". (See attached image.)

It might be better if it said something like: The JQuery UI plugin is missing. Download and extract it to your /sites/all/libraries directory. Rename the extracted folder 'jquery.ui'.

With this patch, jquery.ui is no longer recognized in the modules directory. While I'd rather have it default to the libraries directory, others have asked for automated detection of jquery.ui in both the module directory and the libraries directory.

I hope this is helpful. Again, thank you for patching this. I'll be watching this issue a little more closely.

...
For those of you who would like to help with patching, here is a quick recipe for testing this patch and other similar module patches. Also, check out add1sun's great video on patching here:
http://drupal.org/node/132745
You'll need to be familiar with bash, using something like putty.exe if you're on a shared hosting solution, but anyone can test a patch and the more help we get the better:

$ cd ~/mysite.com/sites/all/modules/jquery_ui
$ wget http://drupal.org/files/issues/jquery_ui-DRUPAL-6--1.libraries.48.patch
--2010-11-12 11:22:48--  http://drupal.org/files/issues/jquery_ui-DRUPAL-6--1.libraries.48.patch
Resolving drupal.org... 140.211.166.6, 140.211.166.21
Connecting to drupal.org|140.211.166.6|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3200 (3.1K) [text/plain]
Saving to: `jquery_ui-DRUPAL-6--1.libraries.48.patch'

100%[===========================>] 3,200       --.-K/s   in 0.03s

2010-11-12 11:22:48 (108 KB/s) - `jquery_ui-DRUPAL-6--1.libraries.48.patch' saved [3200/3200]
$ ls
CHANGELOG.txt  README.txt  jquery_ui-DRUPAL-6--1.libraries.48.patch  jquery_ui.install  translations
LICENSE.txt    jquery.ui   jquery_ui.info  jquery_ui.module
$ patch < jquery_ui-DRUPAL-6--1.libraries.48.patch
patching file jquery_ui.module

Next, get your jquery library.

$ cd ../../libraries
$ ls
dompdf      htc       ckeditor       ie-css3   pie        fckeditor      iepngfix    tinymce
$ wget http://jquery-ui.googlecode.com/files/jquery-ui-1.8.6.zip
--2010-11-12 12:08:44--  http://jquery-ui.googlecode.com/files/jquery-ui-1.8.6.zip
Resolving jquery-ui.googlecode.com... 72.14.213.82
Connecting to jquery-ui.googlecode.com|72.14.213.82|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1327579 (1.3M) [application/x-zip]
Saving to: `jquery-ui-1.8.6.zip'

100%[=======================================>] 1,327,579   1.62M/s   in 0.8s

2010-11-12 12:08:45 (1.62 MB/s) - `jquery-ui-1.8.6.zip' saved [1327579/1327579]

$ unzip jquery-ui-1.8.6.zip
... [listing of all unpacked files]
$ mv jquery-ui-1.8.6 jquery.ui
$ ls 
dompdf      htc       ckeditor       ie-css3   jquery.ui     pie        fckeditor      iepngfix    tinymce
$ pwd
/home/user/mysite.com/sites/all/libraries

Refresh your /admin/reports/status page on your website. You should now see JQuery UI is properly installed.

With this patch, jquery.ui is no longer recognized in the modules directory.

...which makes this a critical bug and prevents a new release.

Attached patch fixes the status report help text only.

This patch works as designed for me.

I notice that the latest featured stable release of jquery library is 1.8.6:
http://code.google.com/p/jquery-ui/downloads/list?q=1.8.6
I'm sorry for not catching this with previous correspondence.
Since I'm not yet set up to patch, I would be grateful if you would consider the change.

According to your comment, we still have to fix the regression that the library is no longer found in the module's directory. In other words: Current code in CVS breaks thousands of sites.

Note that I didn't verify the bug report.

Got it. Thanks. I'm learning a lot here. I'm rolling back my patches and symbolically linking to the libraries from the sites/all/modules/jquery_ui directory instead for now.

Cheers!

With necessary patches applied (to core, jquery_update & jquery_ui) the following is my statement for drush_make to install the jquery.ui library in the proper location:

    libraries[jquery.ui][download][type] = "file"
    libraries[jquery.ui][download][url] = "http://jquery-ui.googlecode.com/files/jquery-ui-1.8.6.zip"
    ; jquery.ui location required because of http://drupal.org/node/489140#comment-3362794 (date module)

drush_make will automatically put the library in sites/all/libraries/$NAME/ according to what you specify in libraries[$NAME].

subscribing

thanks for this patch. when will it make it into jquery ui?

sub

Oh my. No movement on this for half a year already? Anyhow, I was just reminded of this problem looking over my directory structure. I applied sun's very nice patch from #48, which basically fixes the problem and seems to be in 6.x-1.x-dev already. Unfortunately there are two issues which gr33nman already mentioned (didn't find any additional ones). The first one (wrong status message) is fixed with sun's patch from #55, which I also applied. The second issue (jquery UI not found in modules directory) applies to people who already have Libraries API installed, in which case the modules directory check is skipped. I slightly adapted the code (one else to an if) to fix that. So here's the consolidated patch against 6.x-1.x-dev, requesting review.

+

Thanks for reporting, reviewing, and testing! Committed #63 with tiny adjustments to 6.x-1.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Glad to see that happening, esp for the D6 branch due to the 1.2 / 1.6 "age old2 releases :) Thanks sun

Thank you, oneoftwo, sun!
+2

Thanks!
I am using the -dev release, seems to work.
I did not do much with it, though. Mostly external dependency for date_popup module.

Correct URL to Libraries