As discussed here, bringing the jQuery UI library into core would add a huge amount of usability enhancements to Drupal. It would also help bring in more jQuery standards as well as encourage more jQuery developer growth within both communities.

Some areas where it would benefit Drupal core are:

  • Replacement of unmaintained Farbtastic with the jQuery UI Color Picker
  • Drag and drop of physical blocks so you don't need to visit the block administration page

To get it started, here's a patch that adds a packed jQuery UI core to the misc folder, as well as attempts to replace Farbtastic with the jQuery UI color picker in the Color module. If you visit admin/build/themes/settings/garland, you'll see that clicking on the textboxes popup a color picker. Not very functional at the moment, but it's a good kick start.

It would be nice to bring elements of the jQuery UI Drupal module in.

#101 315035-jquery-ui.patch227.14 KBDamien Tournoud
Passed: 11618 passes, 0 fails, 0 exceptions View
#100 315035-jquery-ui.patch226.57 KBDamien Tournoud
Passed: 11635 passes, 0 fails, 0 exceptions View
#95 315035-jquery-ui.patch226.57 KBDamien Tournoud
Passed: 11618 passes, 0 fails, 0 exceptions View
#95 ui-images.tar_.gz5.3 KBDamien Tournoud
#93 315035-jquery-ui.patch406.36 KBDamien Tournoud
Failed: Failed to install HEAD. View
#93 ui-images.tar_.gz5.3 KBDamien Tournoud
jqueryui.patch131.97 KBRobLoach
Unable to apply patch jqueryui.patch View
Members fund testing for the Drupal project. Drupal Association Learn more


Anonymous’s picture

great start rob!

RobLoach’s picture

Some more ideas:

redndahead’s picture

This would be fantastic. I think this patch should just be the addition of jQuery UI. Other enhancements should come as separate issues. Maybe attach the farbtastic changes as a separate patch to this issue for testing.

quicksketch’s picture

I think all of jQuery UI is too heavy. Wouldn't it be possible to include only the pieces as we need them? I'm in full support of the following being added immediately:

- jQuery UI core
- Draggable, Droppable, and Sortable
- Date picker
- Colorpicker(?)
- Progressbar(?), afaik, jQuery's progress bar does not natively support incremental loading via AJAX.

But I'd prefer to see these split up rather than bundled together into one giant JS file. Unless these are loadable on a per-file basis, I'm strongly opposed to the effects jQuery UI adds, as they're mostly dead-weight that'll actually increase inconsistencies between the the way Drupal behaves on a per-module basis.

I also agree that this issue needs to be split up as soon as possible into separate issues. There's no way we can replace all of Drupal's legacy code with UI equivalents in a single patch.

RobLoach’s picture

Oh, for sure. There would be no way to manage the inclusion of all of these as one single patch. Should this issue then just track the inclusion of jQuery UI and the color picker for the replacement of Farbtastic? Seems like adding jQuery UI by itself, without any immediate benefit to Drupal core, is a waste.

dmitrig01’s picture

How about just getting jQuery UI in by itself, as well as an incremental loader, and then making core use it can come later.

redndahead’s picture

I agree with dimtrig01. This issue should stick with adding jQuery UI to core and the implementation of the incremental loader. Does anyone have an outline of how you would handle an incremental loader?

RobLoach’s picture

Status: Needs work » Postponed

Postponed for the #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries). This will allow us to create a registry of jQuery plugins, including the addition of jQuery UI in the hook_jq within the system module.

quicksketch’s picture

Good call Rob. I wanted to suggest we do that first but didn't want to be a total downer. :)

mikl’s picture

This is a great idea, and could really help give Drupal an edge when it comes to innovative UI.

Wim Leers’s picture

As long as each jQuery UI component is overridable, it's fine by me.

For example jQuery Resizable (both 1.5.2 and 1.6rc1, because both are identical) is an utter piece of crap, as soon as you're trying to use it in an advanced way (e.g. apply it to a "grip" div that then applies the same scaling to >= 1 selects, see this issue). The code is also so incredibly ugly and inconsistent that I didn't even want to try to report my problems. (Because of those same reasons I couldn't be sure my hacks to make it work correctly were the right way to fix it anyway.)
So I want to be able to override it with a potential newer (more stable) version.

RobLoach’s picture

In the current state of the #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries) patch, if there are any plugin naming conflicts, it defaults to using the one the that has the largest version number. So, if Drupal shipped with jQuery UI's Resizable version 1.6 RC2 (ui.resizable 1.62), you could make a module that exposed a new "ui.resizable" with a larger version number in hook_jquery_plugins(), and it would use that one. "ui.resizable" version 2, maybe?

I believe Aaron is also planning to add a drupal_alter call so that you could swap out any part of the registry that you wanted (hook_jquery_plugins_alter?). If you have any other ideas, please let them be known!

John Resig’s picture

Thanks for the discussion guys - I'm just passing this on the the jQuery UI guys so that they'll be able to chime in.

ajpiano’s picture

this is a fantastic development.

Owen Barton’s picture

Thinking in terms of aggregation, loading them file by file on each page may be optimal for some files and less than optimal for others. Considering realistic latencies however, it is almost certainly better (in terms of client side performance) to load all the JS as one big blob as we do now or split it into a small handful of (ideally functionally related) blobs, along the lines of sf_cache.

mfer’s picture

@Grugnog2 I'd suggest getting jQuery UI in core first and then having a follow-up patch for optimization in the preprocessing/aggregation. It's a good idea. A simpler patch would just be easier to review/test and easier to get in.

RobLoach’s picture

If JavaScript optimization is enabled, it aggregates all the files into one based on what URL you're visiting. I believe there's an issue around to compress/pack the aggregated file even more, #210447: Introduce Javascript compression maybe?

mfer’s picture

@Rob Loach I think what @Grugnog2 is getting at is to have more than one file to have the js files aggregate to. Basically, intelligent grouping of files. Check out for ideas on the concept. There is potential, with browser file caching, to cut down the amount of bandwidth used by doing this.

dropcube’s picture


tonyn’s picture

I may have some bad news regarding the jQuery 1.6 colorpicker for farbtastic. I wanted to get it working with color.module however found this:

19:40 < ThrushAAX> skiquel: colorpicker is probably going to be dropped from
ui1.6 release because it doesn't work in iE

There has also been news on the list about it being recoded. I'll make a ticket on the UI list asking to make it more important.

RobLoach’s picture

Looking forward to the rewrite. IE dropped from the list of things I like 10 years ago. There are still loads of places where some jQuery UI widgets would play great parts in Drupal core.

mfer’s picture

If they are still up in the air about about what is going to be in jQuery UI 1.6 is it really a good time to introduce it to core? I use it daily and am not sure I consider it ready for drupal core yet.

If the issue comes down to color picker vs. farbtastic, I'll keep up the maintenance on farbtastic for the time being.

tonyn’s picture

I created a thread regarding jquery color picker here:

I'm having my fingers crossed for the rewrite here, as a long-awaited feature that was held back from 1.5

@RobLoach: Agreed, even without the colorpicker it's still substantial and a well made library to use. Unless there is a serious technical reason otherwise it would be very helpful to have in core.

Update Nov 27 3:49PM CST: according to the group thread color picker won't make 1.6. :( Think nothing of it, it's a good time to emphasise 1.6's many other strong points (and jQuery UI itself, of course).

webchick’s picture

As the maintainer of a Drupal release that realistically is going to be in use "in the wild" for at least 3 years (and realizing that whatever we get into it by then is going to be "frozen" for that length of time), I get real nervous about "locking in" libraries that are still undergoing major refactoring like this.

Had we put jQuery UI in core when this issue was first brought up, we would've replaced farbtastic with jQuery UI's colorpicker, only to have that removed under our noses in this new version. Not fun. It kind of implies to me that this thing isn't really stable enough yet, and although you could *definitely* make the same argument against jQuery itself (new versions of that broke all kinds of stuff until lately when it seems like it's started to settle down a bit), that is a much, much smaller bunch of code than jQuery UI within which to find bugs.

So, still not sold on this. I guess we'll see what happens once the various JS sub-system refactoring is done and we know what our options are.

mfer’s picture

@webchick - I use jQuery UI on an almost daily basis and I agree with you 100%. I'm happy with it in contrib at this point and when it's stable enough I would love to see it in drupal core. But, not yet.

tonyn’s picture

@issue - Robloach (and probably some others) made the mistake of thinking colorpicker (delayed in 1.5 and subsequently in 1.6) would make it in. Same with "autocomplete". jQuery UI isn't moving code into a major release unless it's stable. I had to update their documentation accordingly.

When it comes, let's take a look at the low and high level benefits of 1.6 stable from a technical perspective and see if it fits.

redndahead’s picture

jQuery UI 1.5 was released in June. 1.6 will probably release in December. If they continue on the same release cycle then 1.7 could arrive next June. I don't think that D7 will be released by then. So there is still a possibility that we can still work colorpicker and autocomplete in. Also I've seen an increase of contrib modules that depend on jquery ui so it would be useful to them also.

Wim Leers’s picture

I completely agree with mfer.

@redndahead: The problem is that if we ship with 1.7, there will be bugfixes in 1.8, 1.9 and so on that won't be in core. So you'd need a contrib module to override core's 1.7 version to a newer version. jQuery itself on the other hand is stable enough to develop with for years.

I think this is a wise decision of webchick. As much as I'd like to see jQuery UI in core and all the cool stuff that it enables, it simply isn't mature enough yet.

RobLoach’s picture

What's up with jQuery UI brings up the determinate progress bar, which pwns Drupal's progress bar. I suggest you read that article....

starbow’s picture


RobLoach’s picture

redndahead’s picture

Also noticed that they would like UI 1.6 to be used with jQuery 1.3 and ui 1.5.3 to be used with 1.2.6. So this means #350275: Update to jQuery 1.3.2 should probably be committed before this.

Sharique’s picture

I prefer these Jquery UI features to be included in Drupal core.
- jQuery UI core
- Draggable, Droppable, and Sortable
- Date picker

For rest of Jquery UI features we should create a module because we need to change them to be adapted in Drupal.

babbage’s picture

Subscribing—drawing together threads in a domino-effect of postponed patch dependencies. :)

RobLoach’s picture

Title: Add jQuery UI to core » Add jQuery UI elements to core

News from the jQuery UI team regarding jQuery UI 1.7 ;-) .

webchick’s picture

/me tries really hard to stifle a scream of "TOLD YOU SO" about this not being remotely ready to lock into our CMS for 3+ years. :P

Anyway, we'll see what happens.

starbow’s picture

So whats our time frame here? Is there still time for them to stabilize or is jQueryUI off the table for d7?

webchick’s picture

@starbow: D7 code freeze has yet to be announced, so yes, there's definitely still time. However, given how absolutely hap-hazard jQuery UI has been traditionally been about releasees, I would really rather NOT include any of it in core until we have an easy way for site builders to swap it out for newer versions. That's why this is postponed on #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries). I'm not sure why that issue is postponed right now.

jQuery UI also requires jQuery 1.3.x, so this is also postponed on #350275: Update to jQuery 1.3.2. Right now that issue is blocked both on waiting for 1.3.2 to be released (which fixes a regression), and also because tablesort is completely broken in 1.3.

starbow’s picture

thanks for the clarification. I am still getting a feel for when you are expressing an opinion and when you are making an official proclamation :)

webchick’s picture

Ah. ;) I very rarely am making official proclamations. I am, however, always very opinionated. ;)

sun’s picture

Issue tags: +JavaScript
RobLoach’s picture

Status: Postponed » Active
Issue tags: +jQuery, +Patch Spotlight, +jQuery UI

#350275: Update to jQuery 1.3.2 was committed and jQuery UI 1.7 was released.

appel’s picture


rickvug’s picture

Mark and Lisa published a video of D7UX initial concepts & direction. If these ideas are to be implemented, parts of jQuery UI will be needed in core.

To add to the lists at #2 and #4, jQuery UI would also open up the doors to making interface elements "ThemeRoller" compliant. Supporting ThemeRoller would a huge win for themers and could expand color module's roll in Drupal core.

rickvug’s picture

Issue tags: +Usability

Adding "usability" tag.

markus_petrux’s picture

subscribing and wishing jQuery UI 1.7 is stable enough. It's hard to see how a new release of jQuery UI breaks whatever you've done with the previous version. But now, the documentation seems to be a bit more concerned about changes between versions, so that seems to be a good sign.

webchick’s picture

The decisions that need to be made include:
a) How much of jQuery UI to put into core?
b) If the answer is not all of it (which would be nice, because that's far fewer lines of code we need to be responsible for and related bugs we need to squash), how do we deal with the fact that people are going to need the "Squishable" library, which is not included in core, in their modules?
c) Most importantly, how do we deal with the fact that jQuery UI is not currently a stable library (it has had at least three releases since D7 opened for code thaw a year ago) and will thus need to be upgraded 5 or 6 times during the lifecycle of D7?

I would encourage people who want to see this in core to focus on #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries), so that we can abolish the requirement for modules like jQuery Update, jQuery UI, jq, jqp, and the 11,000 other modules in contrib that are all doing the same thing to make up for the fact that core doesn't provide central management of JS plugins. :P

This way we could put relatively unstable libraries such as this in core with a lot more confidence that people wouldn't be stuck with unsupported JS libraries for 3-5 years when Drupal 7 gets released.

webchick’s picture

it has had at least three releases since D7 opened for code thaw a year ago...

Hm. Make that four:

May - June 2009

* Stable: 1.8.1, 1.8.2, 1.8.3
* Preview: 1.9alpha, beta, rc
o New plugins: TBD

webchick’s picture

Might even be five, if you look at the aggressive timeline they have for going from 1.7 to 1.8. (3 months: March -> May) That'd make their target 1.9 release date pretty much exactly coinciding with D7's code freeze.

Then again, it's just a roadmap. ;) Who uses those things anyway? ;)

rickvug’s picture

In regards to jQuery UI's pace of development (#47 point C), I agree that a plug-in manager in core would make upgrading easier and more consistent. However, in the end core itself will still be tied to UI's aggressive schedule. While this isn't ideal, it is better than the alternative I see. What is worse: shipping with a (soon to be) outdated version of jQuery UI or Drupal's current piece-meal approach to JS UI elements? Even though jQuery was soon out of date in D5, using the library was the right choice. I feel the same about UI despite its rapid evolution.

At the risk of being off-topic (and maybe even heretical), I'd also like to consider amending Drupal's stance towards minor updates. If core releases are going to be supported for 3+ years, maybe minor releases should incorporate new versions of external libraries if most developers are in favor. I appreciate Drupal's approach to API stability but jQuery UI updates could be appropriate considering the upside of staying current.

webchick’s picture

@rickvug: Given that their APIs tend to break every single time they do a new jQuery/jQuery UI version, I think this is not a very nice thing to roll out as a "surprise!" to module developers depending on a stable release of Drupal to be... well... stable.

Having dealt with a constantly changing API in SimplePie when I did early development on SimpleFeed module, this was a hair-ripping-out experience I hope to never have to deal with again, and wouldn't wish it on my worst enemy, let alone 100,000 Drupal developers. ;)

We still need answers to A and B regardless if we do C. I don't think it makes any sense to commit any of jQuery UI (or, at the very least, release Drupal 7) without C. However, I'm also not a JS person, but there are several JS people in this thread earlier who agreed.

markus_petrux’s picture

hmm... let me think about "a) How much of jQuery UI to put into core?". I guess it depends on "what's the benefit of doing so".

Now, Drupal javascript is built on top of jQuery itself and we already have a problem to keep in sync with new jQuery versions. Upgrading jQuery means rewriting/replacing a few Drupal components (jquery_update module). Here I would think about the cost of this operation versus the cost of being limited by out dated versions. I mean cost for Drupal itself, but also cost for those developing/investing on top of Drupal. Also, would it be easier to upgrade components that were based on jQuery UI?

Here I would add as a concern the fact that new jQuery UI versions may require latest jQuery versions, so if you need to write something on top of jQuery UI that requires latest version, you simply can't. You cannot install a new version of jQuery because you would be breaking your Drupal installation. So you cannot use latest jQuery UI. Your business is limited by Drupal during X months/years.

Being able to use latest versions of jQuery/jQuery UI can put you on top of your competitors, and it is good investment because that's the future. Sooner or later the world will move in that direction just because that's the very latest version. It looks like a bad investment to write on top of outdated versions as it will be broken for sure when Drupal is upgraded. If you do, you know you're increasing the cost of development and maintenance of your project.

On the other hand, let's say jQuery UI is like a high level API, so it seems it would be easier to deal with version changes as it would encapsulate the complexities of the low level API (jQuery itself). Upgrading drupal components based on jQuery UI would cost less to upgrade?

Not sure if I'm adding anything useful for the discussion, though.

SeanBannister’s picture


caktux’s picture

Gábor Hojtsy’s picture

Issue tags: +Favorite-of-Dries

Dries says he would support jQuery UI inclusion in core: Adding his tag, and hope is not offended :)

Dries’s picture

Tagging it is OK in this case. Thanks even. :)

webchick’s picture

Gábor/Dries: I'm pretty sure we all support putting jQuery UI in core. The questions left to resolve are:

a) How much of jQuery UI in core?
b) What do we do about the fact that this library is still very unstable, and a new major jQuery UI version is coming out about every 3 months, filenames changing willy-nilly, things that were "core" being removed out from under your feet, etc?

There are people doing work at #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries) to help make sure that whatever decision we make here don't screw people using Drupal 7 six months from now.

One alternative is just to put the whole damn thing in and kick it to something like jQuery UI Update module in contrib to deal with the issue. That's certainly the easiest. Are we comfortable basically doubling the size of core with a complex third-party library that none of us know how to support?

jrchamp’s picture

Why not just use the Google AJAX Libraries API? Then all you have to do is specify the version (however general or specific that is preferred) that the particular version of Drupal uses and the modules you need and let Google handle the headache and bandwidth. Plus, this means that it is significantly more likely that the (rather large amount of) JavaScript in question will be cached when you jump between multiple Drupal sites.

Gábor Hojtsy’s picture

@jrchamp: well, that would not work when you don't have an internet connection or you are in a firewalled intranet or somesuch. Whatever we use we distribute.

@webchick: note that Drupal 6 did not change much in how it includes jQuery, and neither it is including the latest jQuery if it breaks APIs (jQuery update still makes sense for Drupal 6). I don't think we need to include the latest and greatest at all times. If they have a bugfix release which does not include new/changed stuff, then that we can ship. I know jQuery is also notorious for bundling new stuff with bugfixes, so sometimes it might not be a trivial decision.

On the size of the codebase, it is a huge codebase if you count the tests, docs and all that, but if you only count the core jQuery UI files, it is around 600 - 700k as far as I've seen. Maybe I missed adding up some required stuff?

mfer’s picture

@jrchamp in addition to what Gábor pointed out, some countries block google apis so it's not a realistic solution.

@Gábor The minified jQuery UI is just over 600k (with i18n). The base theme is about 160k. We may want our own here but this gives us a rough size.

For the stuff we are talking about with core we could even choose something other than jquery ui like jquery tools ( - which is a whole lot smaller.

For core drupal stuff what are we considering using from jQuery UI?

Gábor Hojtsy’s picture

@mfer: Well, so far only a little bit of jQuery UI was discussed to be possibly used via some form of the popups module or modal frame api being integrated into Drupal 7. So jQuery UI dialogs mainly.

mfer’s picture

@Gábor we maintain a bunch of custom JS to do what's in jQuery UI. If we can get jQuery UI in we would want to bring more of it over to remove our own stuff. It would be less maintenance for us. For example, resizable text areas and table sorting.

markus_petrux’s picture

One of the pros I see in jQuery UI is the fact that it shares code between its own components. I cannot see jQuery UI included only with just one component.

Maybe jQuery UI developers could somehow get involved in this decission for D7, at least to know a little bit more about their plans for future jQuery UI versions. I think something like this has been done with jQuery itself?

mfer’s picture

@dries and @webchick What do we need to bring jQuery UI into core beyond a patch that does it?

sun’s picture

If we want to add jQuery UI to core, we should simply add it and conditionally load the files where needed just like we load any other JavaScript.

That will already allow us to replace various custom UI implementations like others have mentioned. But also move forward with CCK UI / Form Builder in core.

#315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries) mainly adds a layer of indirection; nothing that couldn't be achieved using hook_js_alter() already.

Gábor Hojtsy’s picture

Agreed with @sun.

RobLoach’s picture

The problem I see with just sticking it straight in is that hook_js_alter() in the jQuery UI Update module will be huge. It also wouldn't work for the skins because there isn't a hook_css_alter() yet, so we couldn't update the jQuery UI themes to newer versions. For that, we'd need #92877: Add numeric weight to drupal_add_css so that the alter becomes manageable.

We added hook_js_alter() for things like localization where we want to add the JavaScript translations, or those weird times when you want to change the way the JavaScript is added. jQuery UI is much more then just a bunch of JavaScript files though, as it comes with CSS and a dependency tree. We need a way to manage how it's used and added to the page. This was the problem I ran into when working on the first patch last year. Angie addressed it at #38.

sun’s picture

Which means we simply need another issue that's marked critical and titles "Add hook_css_alter()". The issue you referenced has been bumped equally now.

hass’s picture


starbow’s picture

It seems to me that the question should be - is jQueryUI, as it exists today, good enough to build core effects on? And it seems like the best people to give feedback on that, are people that have been using it to build real sites. Anyone have real world experiences to share?

If you do include it, seems silly to not include the whole thing (all the elements, not necessarily the tests and stuff).

rickvug’s picture

One of the primary concerns raised in this issue is the frequency of jQuery UI releases. I'm not involved in jQuery so I do not know the roadmap for 1.8+. The best information I have is the list of Trac's release blockers at Looking at the list, I'd assume that 1.8 isn't coming out for a while. The previous wiki information must have been overly optimistic.

Looking into this issue just a little bit, it looks like past problems were mostly associated with UI's 1.6 release release cycle. The code underwent significant changes while in RC status. RC2 became the 1.6 legacy branch and the newer 1.6 code become 1.7. See for the whole story. Based on the explanation, I would assume that the release cycles from 1.8 onwards will be more structured. Here is the best release UI release timeline that I could put together:

- 1.0 September 2007
- ??? A quick Google search didn't turn up much. Trac doesn't show these releases.
- 1.5 June 9 2008
- 1.6 April 24, 2009 (legacy release, made after 1.7)
- 1.7 March 6 2008

The conclusion that I've drawn is that jQuery UI's past release cycles should not be used as a guide for future releases. 1.7+ brought new version/release pattern. It could very well be that the 1.7 release will be in use for a time to come. There still is the issue of point releases containing a mix of bug fixes and new features. If existing APIs/features remain stable these additions shouldn't be problematic. Obviously that is a big if.

It would be helpful if those involved in the jQuery community could chime in regarding the current/future length of jQuery UI release cycles as well as their policy towards API changes in maintenance (1.7.x) releases. The release manager is Richard D. Worth (@rworth) but he is not online for the next few weeks.

RobLoach’s picture

I just asked some of the jQuery UI people about their policy on API changes:

There should be no api changes throughout 1.7. In 1.8 the api won't change, but some plugins are being refractored and may have new/different options.

Gábor Hojtsy’s picture

I've been involved with updating jQuery UI based solutions from Drupal 5 (with a pretty old jQuery UI version) doing drag and drop and that kind of stuff to Drupal *7* with the latest jQuery UI. It was a pretty simple update. I admit I did not use any great internals from jQuery UI, so I might just touched the compatible parts, but my experience so far is that it was not a groundbreaking problem.

kkaefer’s picture

I read through this issue and I'm currently a bit unsure what holds back adding jQuery UI. I looked at the jquery_ui module and I'd even say that we could commit this module as is. Pages that use a certain feature just call jquery_ui_add() and choose the parts they need (this could be streamlined with, but I don't think that issue should hold this back. If no module/page uses a certain jQuery UI widget -- so what?

Gábor Hojtsy’s picture

I think many people are just afraid of depending on external libraries because of their release schedules and possible bugs. There is a certain "let's implement it ourselves" kind of approach even if we cannot take on the support burden or bugfixing in that case either. For jQuery UI, we'd definitely not implement it ourselves, but there are efforts to get things into core like modal dialogs or formbuilder, where jQuery UI is pretty much a requirement, or we need to reinvent the wheel to an enormous extent.

webchick’s picture

Yeah. My concern comes from being one of the co-authors of jQuery UI module, and had the lovely experience while writing that of the file names, included libraries, APIs, etc. totally shifting out from under our feet at least 3 times in as many months.

We're basically in another situation like we found ourselves in in Drupal 5: the version of the external library we ship with is going to end up being totally obsolete by the time Drupal core becomes stable enough to ship, making something like jQuery UI Update module in contrib an absolute requirement in order for Drupal to remain competitive, since the jQuery plugin authors don't tend to support "ancient" versions of libraries. The difference being that "ancient" to us is 3-4 years, and "ancient" to them is more like 6-8 months. It's always been interesting relying on third-party libraries with an even faster "Drop is always moving" than us. ;)

So, my thought was to couple this issue with a centralized, alterable, plugin registry/manager so that we we wouldn't need stupid hacks like jQuery UI and jQuery Update module in contrib anymore, and also because while writing jQuery UI module, jjeff and I desperately looked for "the" solution to adding additional libraries in contrib so we wouldn't have to write a wrapper module for jQuery UI and create "yet another way" of adding some JS to a page. Therein we found 4-5 different modules that all did the same thing and decided that it was easier to write yet another one than leverage the existing solutions.

Therefore, the time seemed ripe to push core to take on this responsibility, rather than kicking it to contrib to deal with. However, I wasn't counting on said issue ballooning into like 200,000 replies, being so contentious within the larger JS developer community, and taking over a year to complete. And the fact is that we need the jQuery UI stuff in *now* in order to proceed on D7UX work.

So if we choose to keep with the status quo, which is "making Drupal able to stay agile with what happens with development of our external JS libraries is the job of contrib to somehow figure out," then I guess what we should probably do is just dump the entire library (excluding tests) into misc/jquery/. After that... not sure. I'm not thrilled about adding Yet Another Way To Add Certain JS On The Page, so I'd rather *not* have both drupal_add_js() and jquery_ui_add(). But there are dependencies in jQuery UI land, so you can't just add Draggable without also adding some of the core libraries.

Gábor Hojtsy’s picture

Just worked on form_builder to Drupal 7, another module enjoying dependence on jQuery UI. Looks like updating the module from jQuery 1.2 to 1.3 and jQuery UI 1.6 to 1.7 did not took any considerable JS changes. I think we had only one JS change due to how draggables connecting to sortables changed. Other JS changes where how clear-block changed to clearfix in Drupal or how Drupal enforces ($)(jQuery) wrapped code now. I think this underlines again that it might not be that scary to include jQuery UI and not update it later.

#404818: Port form_builder to Drupal 7

sun’s picture

Steps to proceed:

1) Mark #92877: Add numeric weight to drupal_add_css as critical. (done)

2) Agree on the library variant to add to core: source, minified, or packed. (My vote would go for minified for various reasons, also for misc/jquery.js)

3) Extract jQuery UI into misc/jquery-ui, remove its tests, companion files, and not used library variants (depending on 2)), and commit.

4) Open new issues to replace a few custom scripts in core with jQuery UI effects (the original intent of this issue).

webchick’s picture

For 2), I'm pretty sure we don't want 192K of JS loaded on every single page, no? (well. more than that. 192K is the packed version.)

I don't see a packed/minified version of the development bundle that has each file in there separately so a module can selectively load certain ones on the page, unless I'm missing it.

kkaefer’s picture

We don't automatically include them on every page, just on those pages that specifically request it.

Gábor Hojtsy’s picture

Agreed with @sun (#78). I think we should follow the same pattern as with jquery.js in terms of the type of the library, so we ship with the same.

sun’s picture

Of course, we don't use the big, monolithic, customizable package from We follow the installation instructions for jQuery UI module:

webchick’s picture

@sun: Ok. Then the answer to #2 seems clearly to be "the source version," and we'll let Drupal's built-in JS aggregator/compressor handle packing/minifying?

Also, we can't call this issue "fixed" until modules have a way to add jQuery UI elements. Or are we just going to make modules do:

Gábor Hojtsy’s picture

@webchick: As said above multiple times, jquery.js in core is not a "source" version either. Also, why supporting jQuery UI via drupal_add_js() is not fixing "adding jQuery UI" to core? The core/contrib JS files already have this dependency problem, so solving it might be something you set out to put a requirement for this issue or to consider as an independent issue which is a task regardless of jQuery UI in core or not.

Damien Tournoud’s picture

I have to agree with Gabor here:

- the packaging type of jQuery UI should be the same as jquery.js (ie. "packed"), the Devel module could use hook_js_alter() to load another version during development if required
- just use drupal_add_js() for now, and load the dependencies explicitely

webchick’s picture

Gabor: Sorry, really not trying to be difficult here... just trying to impart things we learned from writing the jQuery UI module.

1. jQuery UI is fricking big: something like 25 separate possible components.
2. But, you don't want to tell people "Our content management framework ships with jQuery UI 1.7.2" without giving them ALL of jQuery UI 1.7.2 at their disposal. Otherwise you have to say "Our content management framework ships with select, arbitray parts of jQuery UI 1.7.2 that we needed for core's specific purposes. If you want anything else than that, you're on your own."
3. jQuery UI only provides a packed/minified version of the *entire* library, which is 192K. They do not provide packed/minified versions of specific components.
4. On a given page, you do not want ALL 192K of jQuery UI. You want maybe 4 files. So you should be able to say the ones you want individually.

I don't know of a way to achieve #4 without keeping the individual files separate, which means shopping with source versions unless I'm wrong about #3.

tic2000’s picture

@webchick #76 "I'd rather *not* have both drupal_add_js() and jquery_ui_add(). But there are dependencies in jQuery UI land, so you can't just add Draggable without also adding some of the core libraries."

You don't need to have jquery_ui_add. Adding the files is the job of the developer using them. If I add functionality to core or in contrib that needs Draggable is my job to add the right files for it to work.

webchick’s picture

Ah-ha. :) Sun has informed me that the development bundle over on Google code - NOT the full version available on their website as it was the last time I looked - has the individual files as minified version. /me needs to not assume instructions she wrote 6 months ago still apply in jQuery UI today ;)

Gábor Hojtsy’s picture

@webchick: Even if they are not shipping it in a certain format, we could still always do the conversion and ship that way ourselves, no? I don't believe it is against some rules or that it would be rocket science.

Also, jQuery UI comes with minified versions. At least the package I download and use from as suggested by the jQuery UI contrib module (also said by @sun above).

webchick’s picture

One other thing to note about minified vs. source is that all of the files will have .min.js as their extension. This means that the code above would actually be:


That seems right nasty to me. We could also rename the files prior to commit, but that's also a pain. I'm not sure how it works with using JS compression on an already minified file, but I'm assuming it's ok since we compress jquery.js?

Gábor Hojtsy’s picture

We only aggregate JS, don't compress. There was some development period in Drupal 6 where we did have compression, but it did not work well, so it was removed before release. Help text quote:

CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed).

webchick’s picture

@Gábor: Right, sorry. Learning on the fly here. :D

Ok. So it sounds like the only remaining question is shipping with minified vs. source. While source is easier for debugging:

a) We already ship a compressed version of jQuery and jQuery Forms (although it's packed, not minified, but sun has informed me that minified is faster so we should likely change even those to minified in another issue)
b) We should optimize for end users, not developers.
c) It's always possible while debugging to "hack core" to replace a copy of the code with unpacked versions if you're having troubles.

So it sounds like the plan of attack is:

1. Create misc/jquery-ui
2. Copy the contents of jquery-ui-1.7.2/ui/minified there.
3. Remove misc/jquery-ui/jquery-ui.js (since that appears to just be a smooshed together copy of everything else)
4. Go through and rename all of the files from *.min.js to *.js
5. Commit.

Outstanding question: Do we ship with the i18n folder? Does anyone know what that does?

Damien Tournoud’s picture

Status: Active » Needs review
5.3 KB
406.36 KB
Failed: Failed to install HEAD. View

Here is a first patch, extracted from

- moved minified version in misc/ui
- removed the i18n files (only used by the date picker, those are not compatible with our translation framework)
- moved the base jquery-ui.css into misc/ui

For committers: please extract ui-images.tar.gz into a new misc/ui/images directory.

sun’s picture

Status: Needs review » Active

IMHO, we should leave the decision about the compression type/mechanism to the site builder and hence, only add source files to core. However, not being bold on this issue, because jquery_update module is able to alter the files to use uncompressed variants anyway.

Damien Tournoud’s picture

Status: Active » Needs review
5.3 KB
226.57 KB
Passed: 11618 passes, 0 fails, 0 exceptions View

Better version:

- removed the jquery-ui.js (that contains everything else)
- removed jquery-ui.css, and remplace that with per-element css files.

Still needs to extract ui-images.tar.gz into a new misc/ui/images directory.

Gábor Hojtsy’s picture

@sun: if we ship with the source versions, then we are not really giving options to the user, since there is no compression of JS in Drupal core, so they cannot choose the right version. So we should put the user in front and ship witht he minified version. Then as Damien echoed above, we discussed here that devel module could ship with source versions of whatever we have minified, so developers can debug their JS code. The altering of JS is open to devel, so it can provide a more developer friendly version of the code.

RobLoach’s picture

Allowing different types of JavaScript aggregation/compression is here: #352951: Make JS & CSS Preprocessing Pluggable.

hass’s picture

// $Id: tags are missing in the patch. How are we able to solve the i18n issue?

webchick’s picture

Once #98 is addressed, we can probably proceed with committing this.

Damien Tournoud’s picture

226.57 KB
Passed: 11635 passes, 0 fails, 0 exceptions View

And here with #98 addressed.

Damien Tournoud’s picture

227.14 KB
Passed: 11618 passes, 0 fails, 0 exceptions View

And the correct patch.

webchick’s picture

Status: Needs review » Fixed

Ok. Committed to HEAD, along with a CHANGELOG.txt entry.

For the i18n stuff, we decided to leave that out for now, since we ideally want this integrated with our own translation system. Will have to address this when we get around to looking at Datepicker, which is currently the only translated script in jQuery UI.

xmacinfo’s picture

What are the follow up tasks for this?

Can we list those tasks here even if they are opened with new issue number? For example, is there a task to replace Farbtastic and the jQuery UI Color Picker?

As for translation, which tasks are required? I would definitely offer my help in translating this library in French.

xmacinfo’s picture

Edited. Removed the double posting.

Owen Barton’s picture

Let's use the "jQuery UI" tag (although listing them here is obviously not bad either)

RobLoach’s picture

moshe weitzman’s picture

Status: Fixed » Needs work

I would think that this merits an entry in both the theme and module upgrade pages.

webchick’s picture

Issue tags: +Needs Documentation

GOOD point! :)

starbow’s picture

Laissez les bon temps roulez

yched’s picture

er - what ? ;-)

tic2000’s picture

Let the good times come (I think) :)

starbow’s picture

Let the good times roll :)
It's New Orleans speak for "Yay! Let's party."

Gábor Hojtsy’s picture

Status: Needs work » Fixed
Issue tags: -Needs Documentation

To start the party, I've added these docs following Moshe's suggestion:

jQuery UI (1.7) was added into core.

(issue) jQuery UI 1.7 was added into core. You can find the jQuery UI files in misc/ui and can add Javascript and CSS files from there to your pages with the regular drupal_add_js() and drupal_add_css() calls, no special function calls required. If you are migrating a module or custom code which was previously dependent on the jquery_ui contributed module, the difference in usage is:

Drupal 6 with jquery_ui module:

jquery_ui_add(array('ui.draggable', 'ui.droppable'));

Drupal 7 core:

drupal_add_js('misc/ui/ui.core.js', array('weight' => JS_LIBRARY + 5));
drupal_add_js('misc/ui/ui.draggable.js', array('weight' => JS_LIBRARY + 6));
drupal_add_js('misc/ui/ui.droppable.js', array('weight' => JS_LIBRARY + 7));

Note that you need to make sure that the weights are set appropriately for dependent elements and that component dependencies are included on the page.

Drupal ships with the minified versions of jQuery UI files, just like we do in case of jQuery itself.

Also added to the theme docs:

Added jQuery UI (1.7) to core

(issue) jQuery UI 1.7 was added to core. You can find the jQuery UI files in misc/ui and can add Javascript and CSS files from there to your pages with the regular drupal_add_js() and drupal_add_css() calls, no special function calls required. If you are migrating a theme which was previously dependent on the jquery_ui contributed module, see the module update guide on the topic, which provides examples.

Damien Tournoud’s picture

RobLoach’s picture

Please note that #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries) needs a final review so that it's easier to add jQuery UI libraries to the page.

Status: Fixed » Closed (fixed)
Issue tags: -jQuery, -Favorite-of-Dries, -JavaScript, -Patch Spotlight, -Usability, -jQuery UI

Automatically closed -- issue fixed for 2 weeks with no activity.

Status: Closed (fixed) » Needs review
Issue tags: +jQuery, +Favorite-of-Dries, +JavaScript, +Patch Spotlight, +Usability, +jQuery UI

mpa3b requested that failed test be re-tested.

webchick’s picture

Status: Needs review » Closed (fixed)

No need for re-testing. This issue has long been committed to core.