Get ready for 1.4

Not that this is a good long term solution, but http://github.com/jquery/jquery-compat-1.3 offers backwards compatibility for 1.4 from 1.3.x. So you should be able to make 1.4 work very easily at least in a non clean sense.

jQuery 1.4 officially released!

http://jquery14.com/day-01/jquery-14

Can we just drop 1.4 into the module and run, or is there any other modifications needed to the module?

subscribing

Subscribing

subscribing

subscribing

subscribing

+1

+1, thanks

subscribing

have looked at 1.4 in detail and it is fantastic. But regarding this module, it seems to me that it may be better to wait for UI 1.8 and to let the dust settle a little. Also, I use JQuery Tools and may want to see if they update based on 1.4. Still, would love to see / hear other (braver) people's experience before I switch over.

S

Before upgrading to jQuery 1.4, it would be nice to have a stable release for jQuery Update 6.x-2-x with jQuery 1.3.x.

+1 #15

subscribe

subscribing

subscribing

subscribing

subscribing

subscribe

What jQuery Update module should offer is a hook_jquery_update_replacements($version), or something along that line so that modules can offer alternative versions of their JavaScript files so that compatibility can be kept.

@Rob Loach, I'm pretty sure I had a patch somewhere from a long time that did that...

/me looks...

Ah, here it is: #426764: Allow other modules to alter the replacements

Actually, now that I look at it though, it doesn't pass the version, so it would need some work to use it as you describe..

UI 1.8 is out, and requires jquery 1.4. additionally, at least one component (slider) seems to be broken under 1.7, so I would love to see this supported here...

subscribing++

subscribe, need that for 6.x too

subscribing

+1

Subscribing.

This is on my radar. I'll probably use the reverse compatibility plugin at http://github.com/jquery/jquery-compat-1.3

subscribing

Subscribing

JQuery 1.4.2 is out : http://docs.jquery.com/Downloading_jQuery

subscribing

I changed my 2 JS files in JQuery_update directory, with 1.4.2 version:
sites/all/modules/jquery_update/replace/jquery.min.js
sites/all/modules/jquery_update/replace/jquery.js

For the moment it works well.

.unwrap() also needs 1.4... :(

Views doesn't work with JQuery 1.4.2
I have Javascript errors popup while setting different options in Views.

Do you have same problem ?

Subscribing.

Subscribing.

D7 is now released with JQuery 1.4.2 in drupal-7.0-alpha3 version.
See release notes : http://drupal.org/node/748690

But it needs more updates than just replace jquery.js and jquery.min.js files.
See #653580: Upgrade to jQuery 1.4

I think it couldn't be backported to D6 without core patch.

Any idea how to do it ?

[rant]
I think upgrading issues here would have to be coordinated by Drupal core maintainers. This module is critical enough, I think. Well, yes, someone else could help, but even then, this module seems to be abandoned by the maintainers. A stable version to upgrade jQuery in core to 1.3.x would have to be released before starting to think in jQuery 1.4.x. I think that could encourage others to help building the upgrade path from D6 to jQuery 1.4, and with critical modules such as Views, etc. as it happened to deal with jQuery 1.3.x.
[/rant]

Moving to Libraries API allows us to ask the user to put any jquery.js file in sites/all/libraries. We'll introduce a hook to manage which replacements become relevent depending on the version the user installed.

This patch is off of DRUPAL-6--2 and does a number of things:

1. Libraries API (sites/all/libraries/jquery.js)
2. Removes the administration since the user installs either the compressed or uncompressed via sites/all/SITENAME/libraries/jquery.js. Still not sure this is the best solution here. Would be nice to be able to specify to use either jquery.js or jquery-min.js.
3. Removes jquery.js from the module
4. Adds hook_jquery_update_replacements($version) so other modules can inject new JavaScript replacements when newer versions of jQuery are in use.
5. Add some static caching around jquery_update_get_version()

It probably needs some work, and possibly some variable_get() caching around jquery_update_get_replacements(). I'm not sure it's working for me, we need some mfer halp!

markus_petrux at #43:
Looking at the commit log, we see that mfer has been doing some heavy lifting on the module recently. Rather then updating Drupal 6 to run 1.4, we've been pretty busy getting it updated in Drupal 7. This does not mean that you can help out in getting Drupal 6 to run 1.4 though :-) . We just have to be careful as we should be able to support across different versions of jQuery. The patch I uploaded here introduces a hook that will allow version-based replacements, which seems like the first step in making this possible. Thanks!

With this patch we could use JQuery 1.4.2 without JavaScript errors in Views ?

I don't know if there are others problems.
But it's one when you just replace JQuery 1.3.2 by 1.4.2 in /jquery_update/replace directory.

Could you confirm this patch avoid this problem ?

@Rob: I think that all external libraries are supposed to create a subdirectory under ../sites/all/libraries/ and be placed in that directory. As it is now, jquery.js is placed in bulk under sites/all/libraries/. I think that a jquery subdirectory should be created first. In other words, the final path should be ../sites/all/libraries/jquery/jquery.js instead of just ../sites/all/libraries/jquery.js (or sites/SITENAME/libraries/jquery/jquery.js).

http://drupal.org/project/jquery

Cool!

I am already using all 4 of these modules and would love to know that their features are being ported in a single module (=less chances of conflicts once stable release is out). I've subscribed to the module's issue queue to see how it goes. Let us know when there is a dev version released.

I see you are asking for co-maintainers. Did you ask the developers of each individual module if they are interested? I can post a new issue in each of these modules to let people know. Want me to or prefer to contact them personally?

Thank you in advance sun. Let us know how we can help.

I didn't ask other maintainers, but I think I explained the idea to most of them already one year ago.

As I wouldn't want to introduce yet another module with custom detection and processing of its libraries, the work on jQuery module mainly depends on #719896: Add a hook_libraries_info() - however, with that in place, the module will merely register the libraries and eventually load support files.

This does not mean that we cannot or shouldn't continue here. Rob's patch looks pretty good already, though:

1) As mentioned before already, libraries should be placed into a subdirectory, i.e. sites/all/libraries/jquery/jquery.js. That directory may contain all variants that are contained in the download package.

2) The patch looks like it would load the entire jquery.js file into memory to determine the version. Should use fgets() to read the first, required lines only. (see Wysiwyg module's YUI editor implementation for example)

3) Lastly, this should go into a new 3.x branch.

ok, but one year is quite some time ;) still the offer remains... although I saw there were two people that offered already.

I agree on 1 (proposed it myself) and 3, I couldn't know about 2 (not that skilled yet).

+1 for contacting developers of mentioned modules + subscribing. :)

Subscribing. I need jQuery v1.4 to create multiple Nivo Sliders on one page: http://drupal.org/node/758844#comment-2843310 .

All suggestions are welcome.

subscribing

subscribing

subscribing

@Rob Loach, Re #44:

Sure, but there have been patches pending to commit for a while, and now there could be a stable release for 2.x with jQuery 1.3.x.

In the meantime, several projects that depend on jQuery 1.3.x can only provide imprecise instructions on how to get it, and the project page of jQuery Update shows a stable release which is obsolete because Drupal 6 already ships with jQuery 1.2.6!

Too much months with this module in not stable state... so instead of thinking about 1.4... I think it would be a must to clean up the state of this module a bit.

I'm one of those that tried to help on fixing issues related to jQuery 1.3.x ... now, what else can we do when we need a stable release of jQuery Update so that we do not spend more time than necessary giving support related to the lack of a stable release here?

Look at the usage stats of jQuery Update and compare 1.x with 2.x... there's a lot of sites running 1.x, and I would like to think they are not running earlier versions of Drupal 6 core where jQuery version was older.

Something in this module does not work as it should, I think. And I wanted to point this out here, because I think it is more important to clean things up, otherwise more confusion would be caused.

[EDIT] --> #723410: Create stable 2.0 release for jQuery Update

A workaround proposed here :
http://drupal.org/node/775924#comment-2928300

What do you think about it ?

@robert #58.

Note that my workaround isn't really a proposal. It's rather my personal tweaking to get the job done. I would never want any module to incorporate that.

Yes sure.
But I wondered if such idea couldn't be a temporary solution before right one available in BO and FO.
That's why I thought it could be interesting having JqueryUpdate maintainers opinion.

I noticed that jquery 1.4.2 also breaks panels and CCK filefields

subscribe

(note to self: I need jquery-ui 1.8.x to have http://jqueryui.com/demos/draggable/#visual-feedback behaviour)

Subscribing as well.

subscribe

subscribe

Subscribing.

subscribe

subscribe

subscribe.

I really hope the support of jquery 1.4 will be added on Drupal 6 and not only in the next Drupal 7! :-)

Thanks for the effort!

subscribe

subscribe

subscribe

+1,

Strongly agree jquery needs to be name spaced for drupal internal use and any version of Jquery should be usable by themers and loaded from the library section.

subscribe

I have a need for it so I'll roll something soon.

@gstout - jQuery cannot be tied into the libraries module. Between different versions of jQuery there are major internal api changes. In order for basic features in drupal (like the blocks page) to work we need to override and replace Drupal core JavaScript files and update them. Just changing the jQuery file is not going to cut it. So, each version of jQuery Update is very much tied to a version of jQuery.

Just changing the jQuery file is not going to cut it.

...though that is exactly what we want to achieve in the http://drupal.org/project/jquery project, using Libraries API as arbitrator.

@sun How do we propose to update the supporting files as well? Like, when the jQuery api changes and we need to update things like tabledrag.js to work in the alternate version of jQuery.

subscribing

Are we any closer to this for 6.x?

This patch provides working 1.4.2 in front end without breaking views/panels config or other admin etc http://drupal.org/node/775924#comment-3274706

subscribing as well.

Hi @all,

i needed for a current project jQuery 1.4.x in Drupal 6.x so i patched jquery_update with jquery-compat-1.3.js and jquery-1.4.1.js (1.4.2 currently cant be used with jquery-compat-1.3). The patch contains jquery + jquery compat. its more a workaround as a ready solution but it works. After patching the current dev release you can select the jquery version unter admin/setting/jquery_update. I have it tested with panels and views.

best regards
Dennis

sorry forgotten to change the status

If you want jQuery 1.4.2 in D6 without any hackery please review the following patch!

http://drupal.org/node/479368#comment-3198886

@ManyNancy: the patch at #84 likely does, please test and review in it's issue queue.

Note that the compatibility layer included in #82 is not enough. We had tonnes of things break. Everything from tabledrag to WYSIWYGs.

@dalin #84 is the key, we need people to review it!

Hi,

sorry currently i had no problems with the compatibility layer. I think its a good idea to merge both patches #82 to provide the jquery library with compatibility layer and #84 to fix the encoding problems. Both patches seems to be work fine.

best regards
Dennis

@Blackice2999: Dennis, these patches cannot be merged since #82 is for a contrib module and the one linked in #84 is for Drupal core. Too bad there is no way to mark issues as depended to one another :/

... #44162: Relationships between issues: support for parent issue and related issues

The patches don't need to be merged, once #84 gets into core you won't need a patch for jQuery 1.4.2 to work.. jQuery_Update would have a new release that included 1.4.2 instead..

Just go here and review it..
http://drupal.org/node/479368#comment-3198886

From Jquery FAQ:

You might be wondering why would you want to use different version of jQuery on the same page, why not just use the newest version, right? This is how it’s done…

1.

2.

5.

And this way when you want something made with the new version of jquery instead of the “$” use “$jq”.
Example:

1. $jq('.selector').live('click', function(){
2. //do something
3. });

$jq('.selector').live('click', function(){
//do something
});

BTW, another ways (scripts registering in DB, page spoofing by module etc) may cause serious problems with caching and performance.

From Jquery FAQ:

You might be wondering why would you want to use different version of jQuery on the same page, why not just use the newest version, right? This is how it’s done…

   1. <script type='text/javascript' src='js/jquery_1.4.2.js'></script>   
   2. <script type='text/javascript'>  
   3.  var $jq = jQuery.noConflict();  
   4. </script>  
   5. <script type='text/javascript' src='js/jquery_1.2.6.js'></script>  

And this way when you want something made with the new version of jquery instead of the “$” use “$jq”.
Example:

   1. $jq('.selector').live('click', function(){  
   2.     //do something  
   3. });  

$jq('.selector').live('click', function(){
    //do something
});

BTW, another ways (scripts registering in DB, page spoofing by module etc) may cause serious problems with caching and performance.

Hi igorakulov,

i think its generally no good idea to load a second jquery framework... why you want this overhead ?

best regards
Dennis

And, of course, if you like "$" operator, you must use it in your code wit this simple wrapper:

(function($) {

// ... your code, for example
$('.selector').live('click', function(){
    //do something
});

})(jq);

This is main practic for Jquery extension developers.

Blackice2999, Overhead??? In real world, browser sucks static content such as jq frameworks from your street (by google CDN or other). Simply look that does drupal when uses modules such as jquery_update. It is real overhead. More over, permanent cache invalidation by module loads is not good idea for real hosting. Drupal's hooks spaghetti is Real Overhead.

Simple try to load your jquery.xxx.js from http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js (<10 ms)
and load the same jquery.xxx.js through jquery_update hooks by module from your site and sense of difference. Easy.

I suggest that if loading the Google version rather than the version stored on your site is what you are after, then open a new issue.

My message is simple - it is necessary to put drupal in rest. At all. With frameworks, Jquery etc. But Your application in Your page need Jquery 1.4.2 for Your application. Yes? Simple load it and use it. Basic WEB 2.0 message - as many static as possible in static content. Of course, basic css, basic page layout and basic frameworks of your site is static content by definition. Don't generate static content, don't pass it through Drupal's hook's spaghetti. In many cases this simple technique should increase speed of page loading with compare to hook-based generation. Next, i dont look any problems in my applications with CDN-based frameworks. If you don't like CDN, you must simple locate this frameworks as static content under your apache/nginx. I don't understand, why this siple, robust and fast Why practice is worse than hook-based? The Yslow says that it is very fast. Certainly, you can move further by empiric hacking of jquery_update, but in my opinion, it is the most unpromising and unreliable way.

When using jQuery 1.4 you will need this core patch or a LOT of modules using AJAX features will break with it: http://drupal.org/node/479368

@igorakulov #93

This worked great for me. I added those lines here (ignoring the extra overhead) and it worked like a charm:

page.tpl.php:

print $language->language; " lang=" print $language->language; " dir=" print $language->dir; ">

<head>
  <title><?php print $head_title; ?></title>
  <?php print $head; ?>
  <?php print $styles; ?>
  <link type="text/css" rel="stylesheet" media="all" href="/sites/all/modules/jquery_ui/jquery.ui/themes/cupertino/jquery-ui-1.7.3.custom.css?y">
  <script type="text/javascript" src="/sites/all/themes/bright/js/jquery-1.4.2.js"></script>   
  <script type="text/javascript">  
  	var $jq = jQuery.noConflict();  
  </script> 
  <?php print $scripts; ?>
</head>
<body class="<?php print $body_classes; ?>">

Now a

Hi,

this ways is indiscutable if you want to go the drupal way. Your Browser need to load and work throught two jquery frameworks. Why you not use the patch from #82 to get jquery 1.4.2 in jquery_update and use the patch from #84 to work with it. It´s work fine without problems. And no overhead.

best regards

Dennis

Subscribing

subscribing

Patch #82 breaks views as far as I can tell. All Ajax actions get this error on the ajax.views.js using jquery 1.4.1:

'Drupal.Views.Ajax.handleErrors' [undefined] is not a function.

@seezee: Patch 82 does not appear to modify anything except the jquery_update module.

Also, when I applied this patch it did not copy the jquery files into the replace folder. After upgrade the errors I got pointed to all these files not being present inside the "replace" folder. Putting in that folder took away that error.

subscribe

I have better luck with my test:
- Patch from the link at #91
- jQuery 1.4.2
- jquery_ui 1.8.2
- previously views 2, now testing views 3 (both fine)
- patch to tabledrag.js somewhere (forgot the link)
- active_tags
- imagecrop breaks, epsacrop fine
- colorbox
- endless_page, then views_infinite_scroll (both fine)

The only modules break or behave strangely in my install are taxonomy_manager and draggable_views. Will report any more findings with jquery related modules.

Thanks

Subscribing

So what is the best way to integrate jQuery 1.4? The patch from the link @91 does the job?

The best way would for the core issue to be resolved, please test and review the d6 patch:
http://drupal.org/node/479368#comment-3410894

I'm moving this over from #775924: Issues with jQuery 1.4.2 and marking it as a duplicate.

The attached patch simply updates jQuery to 1.4.2 and backports the following fixes from D7:
- #653580-127: Upgrade to jQuery 1.4
- #737632-15: tabledrag: menu children take top of left region or not at all in IE
- #737596-5: tabledrag.js: $(".indentation", testCell).get(1) is undefined

As realityloop notes, you'll need to apply #479368-89: D7: Create RFC compliant HTML safe JSON to core (though PressFlow seems to be working for me at the moment).

I'd propose creating a new 6.x-3.x branch and committing this patch to it.

that last patch was against alpha1. here's one for dev.

Hi,

why not use the UI part of my patch ? So the user can choice between 1.3.x and 1.4.x ... ?

best regards from germany

+1

I am +1 to the idea of being able to switch versions used through the UI. It will help a lot with testing too!

PS: I'm not sure where jQ is stored for the core (I think under ../misc), but it was agreed that external libraries required by contrib modules are to be moved to ../sites/all/libraries (of course gracefully falling back to the contrib module directory if this directory is not present) and let the Libraries API manage the various versions of the same library. (if there is an issue already filed for this to be done in core too, please let me know - thanx)

Hi klonos,

this is so not makeable, because you need some patches for core elements. The patch von realityloop is necessary and you need some patches like tabledrag.js for example. The using of jquery 1.4.2 in Drupal is a part for developers because you need these patches.

best regards
Dennis

Hi,

So which patches should be used with which Version? Its getting a little bit confusing... An short overview would be good for testing... Does anyone have this overview?

Thanx in Avance...

Blackice2999, i don't think it makes any sense to have them choose. my proposal was to have 2.x be compatible with jQuery 1.3 and have 3.x be compatible with 1.4.

patrickroma, #113 and #114 are for 6.x-2.0-alpha1 and 6.x-2.x-dev respectively. as was stated in #113 (and several times before that) you'll also need to apply a core patch.

#113 Pressflow working here too, +1 for a 6.x-3.x branch

yep, the 3.x branch seems like a really good idea. +1 too.

subscribing

subscribing.

Tested #113 in a Pressflow install (did not apply the core patch). No problems with core functionality. However, in Views2, I was getting 404s on the some of the AJAX requests. Reverting jquery_update stopped the errors. Will investigate more when I get a chance.

I (in general) recommend to read the as duplicate closed, as it might contain other valuable info than the latest patch:

Issues with jQuery 1.4.2 - http://drupal.org/node/775924

drewish, could you upload zip for testing? Thanks.

with the patch from #114, I have problems with the edit panels form, where you can rearrange panes etc. I can only drag the panes, but I cannot drop them.

The regular drag and drop/rearranging support in other modules works fine. I know panels uses its own handler for the grabber class, but maybe this place is more suitable to mention it, as there were also some fixes for the normal tabledrag routines here.

subscribe

The patch at #114 applies cleanly again current dev.
The only issue I could find was with the block configuration page.
While the blogs would 'drag', they wouldn't 'drop' on click release.
Another click was required to 'drop' them, however the block order setting wasn't saved.
Tested on FF3.6, Mac

just a quick FYI: JQ 1.4.4 has been released

Subscribing

Been using #113 for a few weeks now, and haven't as yet seen any issues that I can recall.

This is set to NW since #87. I am not sure what still remains to be do though (other than perhaps upgrading it to 1.4.4). Shouldn't it be set to needs review?

"to be do"? ...meant "to be done"

Someone PLEASE release this damn thing! It's embarassing that we're this far behind with jQuery!

I second @RavenHursT

Release only after ahah file upload has been fixed.

skolesnyk: can you link us to the relevant issue please?

I am having this same problem (as #128) with JQuery update and panels... Has anyone come up with a workaround/solution to this yet?

Currently to reorder panels I am having to delete them and recreate them in the correct order!

subscribe

Subscribing.

Would be a wonderful update to drupal system because 1.4 definitely runs faster than older versions and can do more with it.

subscribe

@realityloop: check this issue http://drupal.org/node/806500

@realityloop Check attached screenshot. I'm using 6.x-2.0-alpha1 with patch http://drupal.org/files/issues/jquery_update_775924_0.patch

subscribe

igorakulov's solution is far superior to this conversation that has been going on for almost a year and apparently still hasn't shown up in Drupal core. If the series of patches worked reliably, one would assume that they would've been applied by now, as keeping people from using other libraries that depend on jQuery 1.4+ is Kind of A Big Deal. We saw releases of Drupal 6.18 and 6.19 almost simultaneously. This conversation started in January, yet I'm still having issues integrating 1.4 with Views in December.

CDNs are a web standard, and a Drupal web application has bigger problems than a "performance hit" from this restrictive attachment to dated versions of powerful frameworks that evolve far faster, and these inconvenient modules that can at best get one to 1.3. If the CDN is not available, that means The Internet is Down...meaning that a Drupal web application has bigger problems.

The Libraries API is a good idea, taking a lesson from the Groovy/Grails (with Grapes) and RoR community and removing external libraries maintained by other efforts from the core and providing dynamic loading support. But for something like jQuery--that's a fundamental dependency-- the logical approach is to refactor the core to remove explicit dependencies on the older versions, slap a link to the CDN in page.tpl.php of a base theme and call it a day.

amen

subscribe

We really need to move on with this, so here is some sort of summary (some facts to be considered + things that need to be done/decided):

- Drupal 7 will ship with jQuery 1.4.4 -at least- (#944308: Update to jQuery 1.4.4). Perhaps all we'll have to do in 7.x is simply maintain future releases (1.5.x +).

- Should we have the 6.x-2.x branch maintain jQuery 1.3.x releases & updates and a new 6.x-3.x for 1.4.x as Andrew suggests in #120? (I vote yes).

I have previously suggested (#117) that we should follow the new 'trend' and use the Libraries API module in order to handle external libraries. This would solve this + also allow switching 1.3.x & 1.4.x back and forth as required during testing/production. There already was a patch in #82 by Dennis offering a way of doing this in the UI. I have not tried that myself though, so I cannot say how it worked. It surely would be a very handy addition though!

@Dennis: care to reroll this against latest dev? You'd have to use #144 and simply add your UI for switching. I'd love to see that!

Nick in #147 added the suggestion of using CDNs as an alternative to the Libraries API or even as an additional option.

Both of the above two suggestion though require that we use jQuery libraries as they come. There is one catch regarding this though:

- We cannot use the jQuery library straight up in drupal without some -minor perhaps but required nevertheless- changes. This was made clear after comment #118 by Dennis and the fact that even the most current solution available (patches in #113 & #114 by Andrew) still depends on #479368: D7: Create RFC compliant HTML safe JSON being fixed in d6 + includes fixes from at least three other related issues. This could be resolved only if these changes could somehow be applied during runtime, thus overriding the 'vanilla' jQuery library (Is this even possible at all? -I couldn't know).

PS: let me know if I missed to mention anything important.

Subscribing.

Should we have the 6.x-2.x branch maintain jQuery 1.3.x releases & updates and a new 6.x-3.x for 1.4.x as Andrew suggests in #120? (I vote yes).

Provisioning jQuery Update 6.x-2.x for jQuery 1.3.x and 6.x-3.x for jQuery 1.4.x would be a maintenance nightmare (Modules can't depend on a version of jQuery Update, just jQuery Update). We should just have jQuery Update update to whatever jQuery version we end up using, and swap out the files accordingly. Either that or ditch it all and remodel everything "the right way" in http://drupal.org/project/jquery .

Subscribing.

@skolesnyk Do you have Any linkifying Greasemonkey scripts enabled? if so disable them.

To those subscribing, check out post #93. Better yet, read all of the posts on this page by igorakulov. He has some very good points.

Let me know if this is too off topic for this thread, but does anyone have a good/easy way to serve jquery 1.2 to admin pages and 1.4 to public pages? I generally need an updated version of jquery for fancy custom stuff on the public facing side of the site, but don't want to break the features of the administrative side of D6, which is built for jquery 1.2.

Add 1.4 to your theme like this:

<head>
  <title><?php print $head_title; ?></title>
  <?php print $head; ?>
  <?php print $styles; ?>
  <script type="text/javascript" src="/sites/all/themes/bright/js/jquery-1.4.2.js"></script>   
  <script type="text/javascript">  
  	var $jq = jQuery.noConflict();  
  </script> 
  <?php print $scripts; ?>
</head>

Then, to execute code with the new version of jquery you simply need to use "$jq instead of "$":

$jq('.selector').live('click', function(){
//do something
});

Then set a different theme under admin/settings/admin. Make sure you check "Use administration theme for content editing".

So, when is it time to open the "Get ready for 1.5" issue? :D

#158 seems to be working for me. I only need 1.4 for some animations for the front end like .delay(). I guess the only downside is the bandwidth of having to load jquery twice. Having said that, if i don't use the standard scripts.js for my external js file, then I think their automatically not loaded when not needed.

I guess the native JavaScript solution setTimeout(function(){ ... }, milliseconds); would be your primary choice.

Ive used js based modules before but ive only been writing simple jquery for a few weeks, i have no previous javascript experience.

Update on my last post, if i remove the scripts.js (so drupal's default jquery isnt loaded), then my 1.4 jquery written with $jq stops working aswell. Ive no idea why this is happening.

Also, forgot to thank csdco for his fix, cheers!

If you are concerned with too many scripts loading, call jQuery 1.4 from Google:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>

and enable JavaScript and CSS compression at admin/settings/performance.

Thanks Csdco, but if i did both of those things, it would still be even better if I could only load 1 jquery library. I dont know how big drupal's inbuilt jquery library is but 1.4 is 82kb, so its not a massive deal for me but not completely irrelevant either. Im assuming loading the file from google is faster? But there still must be some delay?

Your workaround seems to allow both 1.4 and 1.3 libraries to work on the same page, right? But 1.4 wont work without 1.3 also being there. Could the workaround be changed slightly so $jq would work when both 1.4 and 1.3 were on the page, and also when just 1.4 was there? This way you wouldn't have to always load 1.3, which is the drupal version so cant be loaded from google.

Sorry for the length of this post, you've essentially fixed my problem and now im just being fussy! I dont understand what the last step in your workaround is for:

'Then set a different theme under admin/settings/admin. Make sure you check "Use administration theme for content editing".'

I am not following all of your questions 100%, but let me run through them. My apologies if I was not clear on the function of the steps.

it would still be even better if I could only load 1 jquery library ... Im assuming loading the file from google is faster

It's ~ 80K, so decide whether the jQuery functionality is worth the load time. I can't imagine ever sacrificing something I wanted to do in a website because of 80K. Also, it's probably safe to assume a big chunk of your visitors already have the Google version cached on their machine.

But 1.4 wont work without 1.3 also being there... and also when just 1.4 was there

This is where using a different theme for administration pages (and content editing) comes into play. If your admin pages are all using Drupal's jQuery then there are no conflicts. the modern jQuery (1.4) in the rest of your site is only for the front end, correct? I can't imagine otherwise.

I do need 1.4 so ill include it in my site whatever. Using your jq selector everything is working fine. My question was weather I can stop drupal's version of jquery (1.3) loading aswell when its not needed?

It seems drupal is clever enough not to load jquery when its not using it on the page. However if you put a script.js in the theme folder then it will load jquery on every page.

Using your jq selector the jquery ive written (which uses features only in 1.4) is working fine when drupal is loading its version aswell. However if I remove the script.js from my theme folder, and drupal stops loading jquery 1.3 on some pages, then my code stops working.

So, your workaround solves the issue of 2 versions of jquery conflicting, but code written for 1.4 wont work when 1.3 is not also being loaded.

Thanks

Drupal does not just automatically load a file named "script.js". Your theme is explicitly telling Drupal to load that file. Look in your theme's .info file (sites/all/themes/my-theme/my-theme.info) and you will most likely see a line like this:

scripts[] = script.js

This means any time you have a page.tpl.php (or page-whatever.tpl.php) in your theme folder and you are using this line in the header:

<?php print $scripts; ?>

Drupal is printing all of the scripts -- from Drupal core, core modules, contributed modules, and your themes directives.

You may want to remove this line from your theme's info file and manually include the script file as needed in your template files.

Im using the zen theme. My script.js is actually empty, I just realized that including it made drupal load its jquery on every page, and without it it only loads it when it needs to. I guess the reason is that drupal doesn't know whats in the script.js file, so their may be code there that requires jquery.

If I load 1.4 before $scripts, then on the pages that drupal loads its jquery my code stops working, even if its just the alert action which should work with all versions. On the plus side views works normally.

If I load 1.4 after $scripts, then even on pages where drupal loads its jquery my code still works. However views doesn't work.

So, I can either load 1.4 after $scripts but use conditional php not to load it on admin pages, or i can load 1.4 after $scripts so long as dont need to write any js myself on pages where drupal is loading its on jquery.

It seems to me the 2nd method will be less problematic. The only page that currently loads drupal's jquery where i dont want it to is the 'create new account page'. Im guessing it uses some sort of ajax on this page? Can I turn off drupal's jquery for certain pages and see if it still works? I guess I could do this by removing the $scripts on those pages, but I dont know what else im removing with this method.

Thanks

More info on the method from #158 here:
http://blog.nemikor.com/2009/10/03/using-multiple-versions-of-jquery/

I have chosen to use the same theme but instead simply not include the jQuery 1.4.4 when the first argument from the url has "admin" in it.

<?php if (arg(0) != "admin") { ?>
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
    <script type="text/javascript"> 
      var $jq = jQuery.noConflict(); 
    </script> 
<?php } ?>

Thanks to #170 and #158, it's working apparently without any problem. But anyway, i'm using Garland for the backend.

I guess now I don't need jQuery Update, true?

subscribe

Using jquery 1.4 with the Views module, as many people will do, and ajax enabled in block regions will break the ajax form functionality, because jquery 1.4+ will take JSON validation into account. There for you have to patch the drupal_to_js function in common.inc, cause it returns invalid JSON Output.

A working jQuery 1.5 Version of jquery_update can be found here http://drupal.org/node/1067290 or in the attachements. Tabledrag and ajax form (ahah) also with views are working, so far i found no issue. But you have to patch the core common.inc (patch is included) to make it working.

As some have mentioned, #113 as recommended by Unifrom breaks all draggable tables as far as I can tell. Core blocks administration (admin/buid/block), Nodequeue, and draggable views. Does anyone know of a solution? Should there be a warning on the Uniform page, install at your own risk?

You can use the method described in detail here to avoid breaking ANY Drupal functionality: http://drupal.org/node/1058168

sub

!subscribe for jQuery 1.4 !

...btw, 1.5 final is out for some time now and we are heading for 1.6. I think the issue's title doesn't make sense any more (the "Get ready" thing I mean).

jquery support for drupal 6 is decent indeed. i'am working on a similiar module, that is taken up the flag to provide better drupal 6 support (with google cdn support and local fallback). as soon as i'am done, i will inform you

@fatcrobat: instead of creating (yet) another jQuery module can you please consider helping Daniel with this?: #1131920: Co-maintainer(s) for the jQuery libraries module

If more people join forces on a single 'one-ring-to-rule-them-all' type of jQuery module, we'll progress much faster and have a solid solution for lots of issues troubling lots of people. Google CDN support with local fallback seems like a legit feature that could be implemented in jQuery libraries.

klonos++

Perhaps we should close this issue and try to get a patch uploaded in #1067290: Fix jQuery 1.7 for Drupal 6.

+1 to closing this issue -- closed (won't fix). The question of this issue is "What is the plan to get jquery update ready for 1.4?", answer exists in this thread or in the future of http://drupal.org/project/jquery.

Edit: I wasn't aware I clicked on the status dropdown menu ... not sure why it says "active" at the top of this post.

Haha :-) ........ Links to other issues be at:

• #1067290: Fix jQuery 1.7 for Drupal 6
• http://drupal.org/project/jquery
• #1085590: Update to jQuery UI 1.9

...most reasonable decision. Rob++

+1

+1