Hi,

Please don't shoot me for this, but I have been tweaking around with jQuery 1.4.2 for the sake of experiment, and I actually need it as well. I adjusted the jquery_update module so that I have jQuery 1.4.2 everywhere except for users with 'administer views' permission. All things that need jQuery 1.4.2 work nice, and so do the other libraries (fancybox, jquery.jqtransform, etc). The only issue so far is that my ajax submit form doesn't work anymore. I used it for the simplenews subscription form. When submitting anything, a browser popup appears saying: 'an error occured'. Using jquery.form.js v1.2 provided by Drupal core has the same result as using jquery.form.js v2.43 provided by the jquery_update module.

The only issue I found about it is this, but it is not very helpful yet: http://forum.jquery.com/topic/jquery-1-4-1-problem-with-the-form-plugin . I might explain my issue there as well later.

Because I know I shouldn't touch jQuery 1.4.2 at all, I've set the priority to 'minor'. I just post this to share it and for future reference.

Tnx for your time and interest.
Cheers,
Danny

CommentFileSizeAuthor
#24 jquery_update_775924.patch375.51 KBdrewish
#20 jquery_update-775924.patch238.55 KBboztek
#15 jquery_update-775924.patch238.52 KBrealityloop
#1 an_error_occured.png41.3 KBDanny_Joris
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Danny_Joris’s picture

Danny_Joris CreditAttribution: Danny_Joris commented
FileSize
an_error_occured.png41.3 KB

The Drupal messages are not shown after submitting, nor are the javascript callbacks. Submitted email addresses do receive their confirmation mails. So i guess it is not an issue with jquery.form.js .

+ The result of using Firebug > Console on the form with jQuery 1.3.2 and 1.4.2 are the same for both. The results of Headers, Response, Post and JSON are the same.

The profile results on both versions are very different though.

Danny_Joris’s picture

Danny_Joris CreditAttribution: Danny_Joris commented

I think it is the JSON dataType call that is not working. I might try with dataType: 'html' instead...

From the jquery api:

dataTypeString
Default: Intelligent Guess (xml, json, script, or html)

The type of data that you're expecting back from the server. If none is specified, jQuery will intelligently try to get the results, based on the MIME type of the response (an XML MIME type will yield XML, in 1.4 JSON will yield a JavaScript object, in 1.4 script will execute the script, and anything else will be returned as a string). The available types (and the result passed as the first argument to your success callback) are:

* "xml": Returns a XML document that can be processed via jQuery.
* "html": Returns HTML as plain text; included script tags are evaluated when inserted in the DOM.
* "script": Evaluates the response as JavaScript and returns it as plain text. Disables caching unless option "cache" is used. Note: This will turn POSTs into GETs for remote-domain requests.
* "json": Evaluates the response as JSON and returns a JavaScript object. In jQuery 1.4 the JSON data is parsed in a strict manner; any malformed JSON is rejected and a parse error is thrown. (See json.org for more information on proper JSON formatting.)
* "jsonp": Loads in a JSON block using JSONP. Will add an extra "?callback=?" to the end of your URL to specify the callback.
* "text": A plain text string.

Danny_Joris’s picture

Danny_Joris CreditAttribution: Danny_Joris commented
Status: Active » Fixed

Hurrah! Solved, thanks to Heine on irc chat. He pointed me to a patch for drupal 7: http://drupal.org/files/issues/do-479368-u-escape-sequences.patch , discussed at #479368: D7: Create RFC compliant HTML safe JSON .

The only thing I had to do is replace one line in includes/common.inc of D6. In the function drupal_to_js($var) I had to replace this line (manually, because the patch is for D7):

     return '"'. str_replace(array("\r", "\n", "<", ">", "&"),
                              array('\r', '\n', '\x3c', '\x3e', '\x26'),
                              addslashes($var)) .'"';

With this one:

    return str_replace(array("<", ">", "&"), array('\u003c', '\u003e', '\u0026'), json_encode($var));

This means I don't need to use datatype 'html' and I don't need to change anything to ajaxsubmit.js.

Again, big thanks to Heine for helping me with this.

Marking as fixed.

Cheers,
Danny

Danny_Joris’s picture

Danny_Joris CreditAttribution: Danny_Joris commented

Ok, little update from Heine. :)

Heine suggested that I could replace the contents of the entire drupal_to_js function with the contents of the drupal_json_encode function which is new to D7. I don't know how, but it works fine. Json_encode can deal with array, objects and other types. I know God will kill some kittens for this, but this will be backported to D6 core soon.

So

function drupal_to_js($var) {
  switch (gettype($var)) {
    case 'boolean':
      return $var ? 'true' : 'false'; // Lowercase necessary!
    case 'integer':
    case 'double':
      return $var;
    case 'resource':
    case 'string':
      return '"'. str_replace(array("\r", "\n", "<", ">", "&"),
                              array('\r', '\n', '\x3c', '\x3e', '\x26'),
                              addslashes($var)) .'"';
    case 'array':
      // Arrays in JSON can't be associative. If the array is empty or if it
      // has sequential whole number keys starting with 0, it's not associative
      // so we can go ahead and convert it as an array.
      if (empty ($var) || array_keys($var) === range(0, sizeof($var) - 1)) {
        $output = array();
        foreach ($var as $v) {
          $output[] = drupal_to_js($v);
        }
        return '[ '. implode(', ', $output) .' ]';
      }
      // Otherwise, fall through to convert the array as an object.
    case 'object':
      $output = array();
      foreach ($var as $k => $v) {
        $output[] = drupal_to_js(strval($k)) .': '. drupal_to_js($v);
      }
      return '{ '. implode(', ', $output) .' }';
    default:
      return 'null';
  }
}

becomes:

function drupal_to_js($var) {
   
  // json_encode() does not escape <, > and &, so we do it with str_replace().
  return str_replace(array('<', '>', '&'), array('\u003c', '\u003e', '\u0026'), json_encode($var));
  
}

It is not recommended to use this on production sites!

bstoppel’s picture

bstoppel CreditAttribution: bstoppel commented

I decided to try this patch. I am really looking forward to jQuery 1.4.2 as well as jQuery Tools 1.2.

From what I can tell, everything works except drag and drop reordering doesn't work anywhere in the Garland Theme (views, cck, etc.) Actually, reordering doesn't work period. With this patch, there is not even the gracefully degraded form text boxes.

bstoppel’s picture

bstoppel CreditAttribution: bstoppel commented

If the patch referred to in comment #8 of this post, http://drupal.org/node/653580 , is applied to tabledrag.js, draggable reordering works with jQuery 1.4.2.

Here is the aforementioned patch http://drupal.org/files/issues/jquery_1_4_653580_1.patch

Danny_Joris’s picture

Danny_Joris CreditAttribution: Danny_Joris commented

Hi bstoppel,

I didn't mention that I tweaked the jquer_update module for this. I added a separate jquery 1.4.2 and added/replaced the jquery_update_jquery_path function in jquery_update.module. Any role with permission to 'administer views' can only use jquery 1.3.2 . All the others - anonymous users - get to use 1.4.2 because I only needed the latest version for the front end.

<?php
/**
 * Return the path to the jQuery file.
 */
function jquery_update_jquery_path() {
	if (user_access('administer views')) {

	$jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
	}
	else {
	$jquery_file = array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
	}

}
?>

Hope this helps. Or let me know if I'm doing something terribly wrong... :)

What do you mean with patch in comment #8?

srobert72’s picture

srobert72 CreditAttribution: srobert72 commented

@Danny_Joris #7
I exposed your solution here : #685060: Get ready for 1.4

bstoppel’s picture

bstoppel CreditAttribution: bstoppel commented

The patch in comment #8 refers to the other issue queue not this queue. That patch makes tabledrag.js aka "drag and drop rearranging" or "drag and drop resorting" work with jQuery 1.4.2.

Status: Fixed » Closed (fixed)

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

jsims281’s picture

jsims281 CreditAttribution: jsims281 commented

@Danny_Joris #7

That's fantastic! Thanks for the inspiration! I tweaked it a little to this, which just loads the old jQuery when you are in the admin section

<?php
/**
* Return the path to the jQuery file.
*/
function jquery_update_jquery_path() {    
    $curr_uri = request_uri();
    if (strpos($curr_uri,'admin')>0){
    $jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
    }
    else {
    $jquery_file = array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
    }

}?>
chromaloop’s picture

chromaloop CreditAttribution: chromaloop commented

@ jsims281 + @Danny_Joris

Thanks for providing these solutions. I was searching for hours and was about to give up until I found your posts. Both worked like a charm!

Stan.Ezersky’s picture

Stan.Ezersky CreditAttribution: Stan.Ezersky commented

Good, but we must disable jQuery 1.4.2 on add/edit pages

Fixed jsims281's solution

/**
* Return the path to the jQuery file.
*/
function jquery_update_jquery_path() { 
  $curr_uri = request_uri();
  if (strpos($curr_uri,'admin')>0 || strpos($curr_uri,'edit')>0 || strpos($curr_uri,'add')>0){
    $jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
  }
  else {
    $jquery_file = array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js');
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
  }
}
jsims281’s picture

jsims281 CreditAttribution: jsims281 commented

Aha you're right there Stan.Ezersky, good fix thanks for that. Without it, ajax won't work on any add or edit pages!

realityloop’s picture

realityloop
he/him
CreditAttribution: realityloop commented
FileSize
jquery_update-775924.patch238.52 KB

Patch for #13

Creates jQuery 1.4.2 files as well

realityloop’s picture

realityloop
he/him
CreditAttribution: realityloop commented
Status: Closed (fixed) » Needs review

Reopening for possible inclusion in jQuery Update

JohnnyX’s picture

JohnnyX CreditAttribution: JohnnyX commented

So jquery 1.4.2 isn't available for wysiwyg editors? Editors are used in edit mode. Or I'm wrong?

realityloop’s picture

realityloop
he/him
CreditAttribution: realityloop commented

JohnnyX, once the following patch get added to core we'll be able to use 1.4.2 anywhere in the site:
http://drupal.org/node/479368

Déja’s picture

Déja CreditAttribution: Déja commented

I've applied the patch in #15 above in conjunction with the drupal_to_js patch at http://drupal.org/node/479368#comment-3198886

After testing and use for about a week, I look forward to this being included in jquery_update as soon as the bug is fixed in core.

I've written more about this issue at http://echodittolabs.org/blog/2010/08/drupal-6x-jquery-142-new-possibili...

boztek’s picture

boztek CreditAttribution: boztek commented
FileSize
jquery_update-775924.patch238.55 KB

Patch in #15 wasn't applying to dev so I recreated.

ClearXS’s picture

ClearXS CreditAttribution: ClearXS commented

Hi; I don't know how to get the + away from >1600 lines, except manually... Do you have a file without the >1600 pluses?

Edit (Sep 24): I have a Cpanel host account, so the procedure mentioned by next poster, doesn't seem to work for me? Should I install Eclipse? Maybe I should fax my photo ID to the hoster requesting SSH/Shell access?

srobert72’s picture

srobert72 CreditAttribution: srobert72 commented

See this procedure
http://drupal.org/patch/apply

jsims281’s picture

jsims281 CreditAttribution: jsims281 commented

It's probably easier (in your case) to apply the patch using your desktop machine rather than via ssh.

You can apply patches using a Windows machine in a variety of ways, explained in a bit more depth here: http://drupal.org/node/60179
If you are on Mac OSX there is information here: http://drupal.org/node/60818

edit: this looks like a very easy solution for Windows users: http://drupal.org/node/75790#comment-2615716

drewish’s picture

drewish CreditAttribution: drewish commented
FileSize
jquery_update_775924.patch375.51 KB

I think the approach taken of conditionally choosing a jQuery version based on URL will cause more headaches than it solves.

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

drewish’s picture

drewish CreditAttribution: drewish commented
Project: Ajax submit » jQuery Update
Version: 6.x-1.x-dev » 6.x-2.x-dev

Realized this is totally in the wrong queue. Probably should be marked as a duplicate of #685060: Get ready for 1.4 but the comments over there are a wasteland of subscribes and +1s.

drewish’s picture

drewish CreditAttribution: drewish commented
Status: Needs review » Closed (duplicate)
johncionci’s picture

johncionci CreditAttribution: johncionci commented

Im very new to drupal dev in general so im not sure of this is even possible but from solution provided in #13,
can you add something like this.

if admin or.... use core version...
else if use googles cdn versions... (for faster jq)
else use 1.4.2... (for users without access to google)

thanks.

Tommy Kaneko’s picture

Tommy Kaneko CreditAttribution: Tommy Kaneko commented

For the benefit of Googlers looking for a solution to and Ajax error in Panels because of using Jquery 1.4.2, I can confirm that the solution in comment #13 worked a charm.

It is a very good workaround of using jquery 1.4.2 on most of your pages while keeping your admin section using 1.3.

lawx01’s picture

lawx01 CreditAttribution: lawx01 commented

I just patched jquery_update with #13, although it is not yet a 'core' solution, it works like a charm and saved me a lot of time.
Thanks Stan.Ezersky

aspedia’s picture

aspedia CreditAttribution: aspedia commented

Subscribe

Stan.Ezersky’s picture

Stan.Ezersky CreditAttribution: Stan.Ezersky commented

Short and graceful code:

    function jquery_update_jquery_path() { 
        $jquery_file = preg_match('/(admin|edit|add)/', request_uri()) ?
            array('none' => 'jquery.js',       'min' => 'jquery.min.js') :
            array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js');
        return JQUERY_UPDATE_REPLACE_PATH . '/' . $jquery_file[variable_get('jquery_update_compression_type', 'min')];
    }

jQuery1.4.2 is disabled for admin, edit, add pages

jsims281’s picture

jsims281 CreditAttribution: jsims281 commented

#31 Great job, this is working great for me.

Using 1.4.2 still causes issues with some other modules though - I found issues with XML Sitemap, as it a "batch" URL in it's sitemap generation page, instead of add/edit/admin.

For this reason, I wonder if it would be worth being able to choose a set of URLs to ignore in the administration area for jQuery Update module rather than adding them to the code each time a new one crops up?

giorgio79’s picture

giorgio79 CreditAttribution: giorgio79 commented

Why are you saying "Good, but we must disable jQuery 1.4.2 on add/edit pages"

Everyone should or your team has some specific requirements? Will those pages stop working?

dmcgrew’s picture

dmcgrew CreditAttribution: dmcgrew commented

I've tried a few solutions from this thread but none of them seem to work in Firefox or IE. No problem with Safari/Chrome though. Weird! Any ideas??

trickyricky26’s picture

trickyricky26 CreditAttribution: trickyricky26 commented

Thank you Stan.Ezersky ! This worked perfectly. #31

llbbl’s picture

llbbl CreditAttribution: llbbl commented

jquery 1.4.4 breaks views and CCK for me using drupal 6

trungonly’s picture

trungonly CreditAttribution: trungonly commented

Why don't we create an hook / api for hook_jquery_path() so we can define any custom paths in our custom modules?

Macronomicus’s picture

Macronomicus CreditAttribution: Macronomicus commented

All this talk of upgrading only to not use it during most of the site usage /admin/edit/etc I found these instructions to be the best option for now. http://drupal.org/node/1058168

claar’s picture

claar CreditAttribution: claar commented

 

darkknight7’s picture

darkknight7 CreditAttribution: darkknight7 commented

Thanks a lot Stan, I'm quite new to Drupal, and i think this issue was making me question if Drupal was the right way to go, but those doubts are long gone now, there is definitely a great community here.
Thank you again!

madhusudan’s picture

madhusudan CreditAttribution: madhusudan commented

I am using pressflow. and right now facing lots of issues with jquery!.
Do i need to apply this patch..? will this work for pressflow.?

gumol’s picture

gumol CreditAttribution: gumol commented

Code from #31 doesn't work for draggable fields in Webform form components page.

careym86’s picture

careym86 CreditAttribution: careym86 commented

Hey Guys, I also had some issues with wanting to have a different jquery version for a particular page only. I am running D6 with jQuery 1.3.2 courtesy of jquery update module.

I wanted to use the NivoSlider library ONLY for the frontpage, which requires a jQuery minimum version of 1.4.2. When using the code snippets from #7 and #11, it worked, however, I noticed that the node content forms were playing up as a result of changing the jquery version and filtering on the strpos ('admin').

Here's my version of the jquery_update_jquery_path function, which lets me call the function from my template.php file, (see below for code snippet and example use): Please note that the jquery files still need to be put in the jquery update module directory, in the 'replace' folder.

Code Snippet:

<?php
# file: sites/all/modules/jquery_update/jquery_update.module - line 166
function jquery_update_jquery_path($jquery_file = NULL) {
	if ($jquery_file == NULL || !is_array($jquery_file)) {
		$jquery_file = array('none' => 'jquery.js', 'min' => 'jquery.min.js');	
	}
	
    return JQUERY_UPDATE_REPLACE_PATH .'/'. $jquery_file[variable_get('jquery_update_compression_type', 'min')];
}
?>

Example Use:

<?php
function exampletheme_node_preprocess(&$vars) {
    if ($vars['nid'] == 897) {
  	
        // Overwrite node template with custom template
        $vars['template_files'][0] = 'node-897';

        // Initialize the jquery file array and set version number, then pass array to the function.
  	$jquery_file = array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js'); 
  	jquery_update_jquery_path($jquery_file);
        
        // Load NivoSlider js and css
        drupal_add_js(drupal_get_path('theme', 'exampletheme') . '/js/jquery.nivo.slider.pack.js');
  	drupal_add_js(drupal_get_path('theme', 'exampletheme') . '/js/slider.js');
  	drupal_add_css(drupal_get_path('theme', 'exampletheme') . '/css/nivo-slider.css');
}
?>

I hope this helps someone else. Also, this is my second post ever on drupal.org, so please give me feedback on if the way of posting is good/bad/clear/unclear, etc so I know what to do in the future.

Goodluck.

btully’s picture

btully CreditAttribution: btully commented

subscribe

Stan.Ezersky’s picture

Stan.Ezersky CreditAttribution: Stan.Ezersky commented

careym86, Thanx!

Solution for frontpage (not node content!)

function MYTHEME_preprocess_page(&$vars, $hook) {

  if ($vars['is_front'] == TRUE) {

		// Initialize the jquery file
        $jquery_file = array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js'); 
        jquery_update_jquery_path($jquery_file);
      
		// Load Slider js
		drupal_add_js(drupal_get_path('theme', ' MYTHEME') . '/js/coin-slider.min.js');
	}
}

Example from page.tpl.php

<?php if($is_front) : ?> 
  .......My sliders code is here......
<?php endif; ?>
polmaresma’s picture

polmaresma CreditAttribution: polmaresma commented

I'd modified this to solve problems on webform edit page.

 function jquery_update_jquery_path() { 
        $jquery_file = preg_match('/(admin|edit|add|webform)/', request_uri()) ?
            array('none' => 'jquery.js',       'min' => 'jquery.min.js') :
            array('none' => 'jquery-1.4.2.js', 'min' => 'jquery-1.4.2.min.js');
        return JQUERY_UPDATE_REPLACE_PATH . '/' . $jquery_file[variable_get('jquery_update_compression_type', 'min')];
    }

jQuery1.4.2 is disabled for "admin, edit, add, webform edit" pages

tea.time’s picture

tea.time CreditAttribution: tea.time commented

Regarding the edit to jquery_update_jquery_path() in comments #13 and #31:

The condition

if (strpos($curr_uri,'admin')>0 || strpos($curr_uri,'edit')>0 || strpos($curr_uri,'add')>0)

became problematic for me because I have a front-end page that happens to use 'edit' in its path alias. I adjusted to:

if (strpos($curr_uri,'admin')>0 || (arg(0) == 'node' && (arg(1) == 'add' || arg(2) == 'edit')))
tea.time’s picture

tea.time CreditAttribution: tea.time commented

Also, I ran into a case of drewish's comment (#24) about URL path not being the best condition to check:

I am using core's tabledrag.js for a custom form on the front end (via drupal_add_tabledrag()). Now, jquery_update 6.x-2.0-alpha1 provides its own version of tabledrag.js, updated to work with the version of jquery that it provides. So I needed to check whether tabledrag.js was being used on my front-end page, and if so, don't use a newer version of jquery than provided by the module.

I added an optional argument to the path function: jquery_update_jquery_path($force_older = FALSE) and checked it as another condition for not updating beyond module version:

	if (strpos($curr_uri,'admin')>0 || (arg(0) == 'node' && (arg(1) == 'add' || arg(2) == 'edit')) || $force_older)

Finally,

function jquery_update_preprocess_page(&$variables) {
  ...
      $force_older = (isset($scripts['core']['misc/tabledrag.js']) || isset($scripts['module']['misc/tabledrag.js']));
      $new_jquery = array(jquery_update_jquery_path($force_older) => $scripts['core']['misc/jquery.js']);
  ...
}

Obviously this only checks a very specific condition; jquery_update also provides patched versions for a small bunch of files -- see jquery_update_get_replacements() -- but I didn't experiment to see if any of those others would conflict with a later version of jquery than the module's version.