There has been a lot of comments back on forth on this one for Drupal 6: #1067290: Fix jQuery 1.7 for Drupal 6

I think its time Drupal 7 got the same kind of attention, 1.5.2 is good but jQuery is at 1.7.1 now and we shouldn't fall too far behind! :)

CommentFileSizeAuthor
#4 jquery_update-1386294.patch2.24 MBalexweber
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexweber’s picture

Just out of morbid curiosity I hacked the module to include the most recent versions of jQuery, jQuery UI and jQuery Form plugins and it is working without a hitch so far. I've tested draggables, Views UI and file uploads.

JohnAlbin’s picture

Would be nice to get this in, so I don't have to use innershiv and/or a monkey patch to get HTML5 elements to work with jQuery. #1389060: Update to v3 of HTML5 shim and remove InnerShiv

RobLoach’s picture

Priority: Normal » Critical

Pushing to critical as we most definitely need to push this forward. Now that jQuery 1.7 is in Drupal 8, we could easily just port those changes over to Drupal 7's jQuery Update. We should probably take the same approach for Drupal 6 too, as it would be nice to sync the differences between the branches.

alexweber’s picture

Status: Needs work » Needs review
FileSize
2.24 MB

Attached is a patch with updates of the following components:

  • jQuery to 1.7.1
  • jQuery Form to 2.94
  • jQuery UI to 1.8.16
mgifford’s picture

It's a pretty large patch, but it applies against the git repository pretty nicely. Mostly whitespace issues:

$ git apply jquery_update-1386294.patch
jquery_update-1386294.patch:5190: trailing whitespace.
return !!selector && (
jquery_update-1386294.patch:5194: trailing whitespace.
POS.test( selector ) ?
jquery_update-1386294.patch:5203: trailing whitespace.

jquery_update-1386294.patch:8000: trailing whitespace.

jquery_update-1386294.patch:8036: trailing whitespace.

warning: squelched 163 whitespace errors
warning: 168 lines add whitespace errors.

Now this would make it way easier to bring jQuery Mobile into Drupal. Probably useful for a lot of other stuff too.

Thanks for rolling this patch!

damontgomery’s picture

I attempted to swap in jQuery 1.7.1, jQuery UI 1.8.16, and jQuery Form 2.94 into the module and ran into a few problems. We are using Drupal 7.8 (I updated all of our code to 7.10 and modules as well and still had the problems described below). What versions are other users using?

These updates have broken the file upload in node/edit. If I update the three components above, I get an error when I click "Upload" "An error occured while attempting to process /file/...: Component returned failure code: 0x80460001 (NS_ERROR_CANNOT_CONVERT_DATA) [nsIDOMFormData.append]" If I update only jQuery and jQuery UI, I click on the "Browse" button, and when I click "Remove" the wheel just keeps spinning.

I am using Firefox 8.0.

RobLoach’s picture

I ran this through QUnit and it's looking pretty good! Had one failing test, but that was failing with jQuery 1.5 too. We could probably backport the file upload/form stuff from Drupal 8 to get the file upload fixed.

RobLoach’s picture

Status: Needs review » Reviewed & tested by the community
RobLoach’s picture

Status: Reviewed & tested by the community » Needs review

Whoops, didn't mean to do that :-P .

alexweber’s picture

Any pointers on what to improve, I'd love to get a patch in! :)

nylin’s picture

It seems I can't pach jquery_update 7.x-2.2 with the attached patch, is the patch still relevant? I get errors like:

patching file ./replace/jquery/jquery.js
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 11.
Hunk #3 FAILED at 37.
Hunk #4 FAILED at 47.

and this continues down to Hunk #214, don't know if I do anything wrong. Has anyone of you guys applied this patch successfully?

alexweber’s picture

Patch is against 7.x-2.x dev, I've managed :)

nylin’s picture

Oh thank you very much, I tried against the wrong version I guess. Finally I will be able to add jQuery Mobile to my site!

JohnAlbin’s picture

Status: Needs review » Needs work

The patch is full of cruft like this:

diff --git a/replace/ui/ui/i18n/jquery.ui.datepicker-zh-TW.js b/replace/ui/ui/i18n/jquery.ui.datepicker-zh-TW.js
old mode 100644
new mode 100755

Which means the jQuery zip files weren't unzipped properly. All the files are incorrectly getting the UNIX execute permission.

Also, the patch doesn't seem to include Rob's suggestion:

We could probably backport the file upload/form stuff from Drupal 8 to get the file upload fixed.

lathan’s picture

Patch also breaks stuff in the views ui...

namely when selecting the option "Rewrite the output of this field" that input field does not display.

nylin’s picture

Patch breaks:

• Select elements in Content Types > Manage Fields > Select Widget, they start of disabled state and stays disabled even though you change the field type.

• Admin module's menu, but that's an easy fix for all with some jQuery knowledge.

• Image upload files, image thumbnail is not being updated after upload is completed, getting weird AJAX error in an alert() box.

• I have not be looking into this so much, but it also seems to do weird stuff to the select elements rendered through the FAPI, it displays some kind of weird label next to every select box that's.

Just some stuff I've noticed.

alexweber’s picture

Yup, back to the drawing board with this one.

RobLoach’s picture

Title: jQuery 1.7 for Drupal 7 » Fix jQuery 1.7 for Drupal 7

I've committed the initial support for this, while keeping it in line with #1067290: Fix jQuery 1.7 for Drupal 6. It supports using either 1.5 (default) or 1.7, but is definitely just the beginning. I combined a bunch of code I found from both the attached patches and sandboxes. Thank you to all who have been involved so far!
http://drupalcode.org/project/jquery_update.git/commit/ce5b379

Let's get the other stuff in there, like the jQuery Form update, jQuery UI, etc!

lathan’s picture

Any pointers where to start looking to fix..
- Views UI
Thats my main issues with this right now, so ill lend a hand here if can figure out where to start looking to aid here.

File upload is fixed in FF now Ajax error gone.

klonos’s picture

The list in the project's page needs to be updated to reflect this change. From:

Drupal 7 to jQuery 1.5.2 and jQuery UI 1.8.11

to something like:

Drupal 7 to jQuery 1.5.2 (by default - or 1.7.1 through config option) and jQuery UI 1.8.11

alexweber’s picture

That's awesome Rob, hopefully we can get a stable version soon! :)

DerekL’s picture

My god, I feel so cutting edge right now.

Same Issue.

How can I help?

shaneforsythe’s picture

Using the dev, certain logic for checkbox toggles seems to be reversed. (IE, if this box is checked, do something or make something visible, etc)

I initially noticed in the Omega theme configuration , and mistakenly posted ticket there (http://drupal.org/node/1416888) but realize now this is more core drupal functionality (I believe).

The chunk of code in the omega template form declaration here ... [alpha/includes/theme-settings-general.inc :51]

'visible' => array(
':input[name="alpha_responsive"]' => array('checked' => TRUE),

, but not sure where to check in drupal to see where that logic is.

shaneforsythe’s picture

Off the drupal-7.x-dev , I modified these two files and it fixed my specific issue. On a larger scale, what/where would be correct place to submit an issue to try to get incorporated into core ... or at least have this module patch/replace those two files.

Changed .attr to .prop

/misc/states.js

  252:      return this.prop('checked');
  389:      $(e.target).prop('checked', e.value);

/modules/field_ui/field_ui.js

93:    $(this).html(html).prop('disabled', disabled );
246:      $(ajaxElements).prop('disabled', true);
alexweber’s picture

Nice catch!

You should probably create 2 issues, in field module and core.

However, since core isn't broken with the jQuery verison it ships with, this probably won't get fixed in 7.x so its gotta go in 8.x-dev

emarchak’s picture

There are errors with jQuery versions pre-1.7 that logs an alert every time focus is given to an item. I'm noticing that it's a pretty big performance hog. There's definitely some benefit to including this patch for the 7.x releases.

damontgomery’s picture

The layer.X and layer.Y issue was one of our main reasons for attempting an upgrade. Our image uploads do not work in Firefox with jQuery 1.7 however. Others have reported success, so it's possible it's an issue with our set up.

UPDATE:

I tried to update using the most recent dev branch of jquery update with jquery 1.7.1. Unfortunately, the image uploads do not work. Clicking "upload" just spins the wheels and on "save" we get an error page. Without the clicking the "upload" button, hitting "save" does work, but then we are not able to remove the image using the "remove" button.

There may be other issues, but this is a show stopper for us.

There is a very good chance this is a result of other modules, but this is still a problem using the non-overlay version of a simple page creation screen.

My set-up:
Drupal 7.12 (fully updated including all installed modules)
Ubuntu Linux 11.10
Chrome (latest non-dev release)
Firefox (latest non-dev release)

ericduran’s picture

I'm running jquery_update on Drupal 7.12 without any issues.

I'm running jquery 1.7 and have yet to run into anything.

Also because 1.7 is really needed to build proper websites with new html5 elements I've updated html5_tools to depend on jquery_update. Well at least on it's dev version. I want to be sure there's a jquery_update for jquery 1.7 stable before pushing that release live.

I have yet to run into any issues yet.

So I'm all for 1.7 on the stable branch :)

klonos’s picture

...did you try adding a new field in a content type while using jQuery 1.7? You'll see that the second drop-down where you select the widget type is locked! Please confirm, because this might be because I'm using Field Group.

ericduran’s picture

Yep, that is indeed an issue. For now I'm still keeping 1.7 being that I'm more concern about the front-facing part of the site and not so much the Admin UI. Also I usually have field_ui disabled in prod. So for now I can set up dev to keep 1.5.

Should we open separate bugs to fix each issue or keep this one open.

I did manage to get it working by making the changes in #24.

Here's what I'm thinking for these fixes (feedback welcome):

The Field ui, we just need to add a field_ui.mod.js In here we can specifically overwrite specific parts of the script instead of replacing the whole thing.

Example:

Drupal.fieldUIOverview.AJAXRefreshRows = function () {
// Make our changes to this function.
}

Same with jQuery.fn.fieldUIPopulateOptions

This will allow for what I think is the simplest management going forward. Sadly we can't just hook_library_alter on the field_ui js because it's added manually from the form :(

We could do the same for the state changes by just overwriting the specific functions.

Any feedback?

damontgomery’s picture

Update on my problem with image uploading. Short of it is that it works, but there is an issue loading multiple copies of jquery.form.js.

Basically, a bunch of modules such as ctools (modal, some others), imce (used in WYSIWIG), and others load the js library with a line similar to this,

drupal_add_js('misc/jquery.form.js');

By commenting out that single line in the ctools modal file, I was able to get image uploads working with no problems.
Does anyone have any suggestions? I don't understand if that drupal function checks the registered library file (which jquery_update changes?) or simply loads that file directly. Maybe it's a precedence thing, where the other modules like imce load after jquery_update and the ctools modal loads before. I'm not really sure here since I don't really understand the process.

Either people need to update their modules to work with jquery_update, jquery_update needs to take care of those issues, or we can write our own functions to handle it. I really don't want to hack core or other people's modules since it becomes a huge hassle during updates.

Any thoughts?

Drupal Version: 7.12
jQuery Version: 1.7.1

ericduran’s picture

We should start filling bugs in those module to use drupal_add_library instead. I haven't ran into this issue myself but i'll investigate.

damontgomery’s picture

UPDATE: Looks like ctools dev branch already has some of these fixes. May be good to suggest people use that so they don't get similar issues. (see http://drupal.org/node/1377332).

Here is a list of the modules I found that we use that use drupal_add_js:

  • ctools (ctools_export_ui.class.php, page_manager.admin.inc, modal.inc)
  • imce (imce.page.inc)

Can this be swapped with drupal_get_library(module_name, file_name) or drupal_add_library(module_name, file_name)? devel_themer and views uses drupal_add_library('system', 'jquery.form'), so I'm inclined to think that is correct. (http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_g...)(http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_a...)

Additionally, for forms, it looks like $form['#attached']['js'] = array('misc/jquery.form.js') should be something like $form['#attached']['library'][] = array('system', 'jquery.form'). You can see an example in the views module in views/includes/admin.inc (http://api.drupal.org/api/drupal/developer!topics!forms_api_reference.ht...)

In the mean time, it may be a good option to add checkboxes in the config page for all of the added updates. That way, we can simply uncheck the option to load jquery.form.js and avoid hacking modules and this module.

I'm going to go make issues in the ctools and imce modules.

alexweber’s picture

@pandaeskimo, would you mind explaning this a bit better please? I got kinda lost halfway through the discussion...

Basically what you're saying is that all calls to drupal_add_js() should be replaced with drupal_get_library(module_name, file_name) or drupal_add_library(module_name, file_name)?

Thanks! :)

damontgomery’s picture

Sure,

My understanding is that if you don't let Drupal manage the libraries, you can potentially load libraries several times on the same page which causes issues. The main issue we had was uploading / removing files.

The way adding JS libraries should be done as far as I know is to use drupal_add_library(module_name, file_name) when you are able.

drupal_add_library('system', 'jquery.form');

This can only be done if the library is part of a module, many of which are part of core in a system.module file. If you cannot link to an existing library, my understanding is that you do one of the following: create the library and then link it, or run,

drupal_add_js('file.js');

If it is only your file and there is no chance of duplication, I don't see any reason not to use the easier drupal_add_js method.

To create a library, I believe you call hook_library() in your module in order to create that library and list the version and location of the file to use. Below is the code from system.module that can be a framework (I believe) for adding this library. You can see that libraries include information about dependencies.

hook_library(){
  // jQuery Form Plugin.
  $libraries['jquery.form'] = array(
    'title' => 'jQuery Form Plugin',
    'website' => 'http://malsup.com/jquery/form/',
    'version' => '2.52',
    'js' => array(
      'misc/jquery.form.js' => array(),
    ),
    'dependencies' => array(
      array('system', 'jquery.cookie'),
    ),
  );

  return $libraries;
}

For a form, there is also a way to include a JS file which mimics functions above,

$form['#attached']['library'][] = array('system', 'jquery.form')
$form['#attached']['js'] = array('misc/jquery.form.js')

I believe the library method (first) is better if possible for the same reasons.

Modules with issues:
ctools has an issue which is mainly resolved in the dev branch. I have also submitted a patch which I believe may fix other issues that deal with exporting content and the page manager.
IMCE uses a unique version of jquery.form.js and the maintainer believes this does not present a problem. I found that we do not actually use IMCE, so I'm not sure if this is the case or not.

As time goes on, Chrome will have issues with jquery versions under 1.7 and a lot of people will likely want to update. This module is a great way to do so, and hopefully other modules will easily be able to adapt to the changes.

alexweber’s picture

@pandaeskimo, thank you very much for taking the time to clear this up!

I was wrongfully under the impression that drupal_add_js() already prevented the same script from being added twice.

*runs off to update a bunch of code*

damontgomery’s picture

As far as I know drupal_add_js does prevent duplicates unless the script is in a different location, such as one in the jquery_update module and one in misc/. These also happen to have different file names, jquery.form.min.js and jquery.form.js.

Also, I'm no expert on all this. I've just looked through examples in big modules such as ctools, views, and this one along with the documentation and tried to make sense of it. By changing some of the functions for our site, we have gotten around loading multiple versions and the problems that causes. It seems like drupal_add_js is the easier and mostly ok way to do things, but drupal_add_library is the more flexible solution.

alexweber’s picture

Gotcha! :)

OnkelTem’s picture

Great effort, thank you!

cluke009’s picture

Tried applying this to 7.x-2.x-dev 2012-Jan-18 and received the following error.

error: while searching for:
name = jQuery Update
description = Updates jQuery to jQuery 1.5.1 and jQuery UI 1.8.11.
package = User interface
core = 7.x
files[] = jquery_update.module

error: patch failed: jquery_update.info:1
error: jquery_update.info: patch does not apply
Checking patch jquery_update.module...
error: while searching for:

  // Replace jQuery.
  jquery_update_jquery_replace($javascript, $cdn, $path, $min);
  $javascript['jquery']['version'] = '1.5.1';

  // Replace jQuery UI with CDN or local files. If from a CDN include all of jQu
ery UI.
  jquery_update_jqueryui_replace($javascript, $cdn, $path, $min);

error: patch failed: jquery_update.module:65
error: jquery_update.module: patch does not apply
OnkelTem’s picture

CKEditor Drupal module doesn't work: #1447018: No text at all with jQuery 1.7

EDIT: CKEditor in WYSIWYG module works fine. See below.

damontgomery’s picture

Cluke009, This work is already in the dev branch, you don't need to apply the patch.

OnkelTem, I responded to your linked thread. TLDR: We don't have problems with WYSIWYG and CKEditor as a library, so it's likely an issue with the CKEditor module. Probably best to keep discussion about this on that modules section.

ericduran’s picture

The way I see it, this issue should be mark as fixed. All other issues related to jquery 1.7 should be in separate issues where we try to fix one issue at a time :)

1.7 is already on the dev version. So lets just open up an issue for the only problem i've ran into so far which is mention above and it has to do with states.js. Besides that everything looks good.

I won't mark the issue as fixed being that I'm not a maintainer so I'll leave it up to them. For the time being I'll be opening up a separate issue related to states.js and working on a fix over there.

OnkelTem’s picture

@pandaeskimo

Probably best to keep discussion about this on that modules section.

And this is how it goes now, so thers nothing to worry about :)
I posted it here to inform those who will search for issues with CKEditor/1.7 here.
I will edit my previous post to emphasis that the issue relates to that module, not WYSIWYG.

ericduran’s picture

FYI, I created two separate issues.
One for fixing states.js #1448490: Remove the states.js overwrite as it was fixed upstream
Another one for fixing field_ui.js #1448494: jQuery 1.7: field_ui.js use attr for property

Honestly any other issue with 1.7 should probably deserve is own issue :)

alexweber’s picture

Agreed.

rbeton’s picture

Both Chrome and Firefox are reporting an error with JQuery 1.5.2

Error: uncaught exception: Syntax error, unrecognized expression: [href=/]

This has probably been around for quite some time. I'm looking forward to the 1.7.1 update.

Rick :-)

fletchgqc’s picture

To confirm and further the sentiments of others, here are the action points I feel are now required:

1) Mark this issue as fixed. Any new bugs found require their own issue. Otherwise this will become a massive catch-all issue for everything on the dev branch.

Then either:
2) Make 1.7 the default JQuery version in the dev branch.
3) Update the project page, adding the following sentence to the bottom of the list:
The 7.x-2.x-dev and 6.x-2.x-dev branches currently update to jQuery 1.7.1 and jQuery UI 1.8.11.

or

2) Release the dev branch as 7.x-2.3
3) Update the project page adding ". Experimental jQuery 1.7.1 support is available through a config option" to the Drupal 7 point.

klonos’s picture

Branching would help us test latest changes with ease (commit fixes to dev and follow a try-break-revert process) while keeping the rest of the users on the safe side with previous, well-tested versions. If we don't branch, then we'll need to *absolutely* make sure that changes don't break core and *every* possible combination of contrib out there before we commit *anything*. This will most likely put off people that want to help testing (myself included) because we'll need to be constantly applying patches and keeping track of them too.

As for closing this issue and filing separate ones for each problem we spot, yes let's please do so! Let's all agree on a tag we'll be using (like "broken with jQuery x.y.z" for example) or alternatively use some issue title prefix (like "[broken with jQuery x.y.z]: ").

gagarine’s picture

Status: Needs work » Fixed

This one is fixed as we have now jQuery 1.7 in 7.x-2.x-dev.

Please open separate issue if you find a bug with jQuery 1.7 or if you want to discuss about branching or any other subject.

For the field problem follow: #1448494: jQuery 1.7: field_ui.js use attr for property

imp7’s picture

Its working well here and I agree with moving the form to its own page separate from performance.
Hope to see this in the stable version soon :)

Status: Fixed » Closed (fixed)

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

RobW’s picture

Has this been rolled back? 7.x-2.x branch from git is still giving me jQuery 1.5.

teflo’s picture

Is it possiblle to downloads the files with the patch applyed?

damontgomery’s picture

The dev branch has this as an option. Download this from the project page, or from drush.

robhoward79’s picture

Hi all... I am getting this error on my drupal 7 site and the module no longer seems to be working... anyone else run into this?

The requested page "/sites/all/modules/jquery_update/replace/jquery/1.7/v=1.7.1" could not be found.

orenroth’s picture

@pandaeskimo - same problem here with firefox... Did you found any solution for that?

orenroth’s picture

Ok Ok Ok I Finally found the solution for firefox!!

When I had problems in the beginning I upgrade the jquery, jqueryui and jqeury.form.js files to the latest versions.
For some reason Firefox doesn't work with ver. 3.09 (the last one) so I just found other version online (v. 2.84) and I replace it and now it's working on all browsers!

I hope it will save nerves for some people..

you can found the 2.84 form.js plugin here:
http://code.google.com/p/bainternet-js-cdn/source/browse/trunk/js/jQuery...

iaminawe’s picture

I should update this that the only thing that worked for me was applying this ctools patch http://drupal.org/node/1494860 - everything works fine once doing that

susheel_c’s picture

Is this going into the release version of the Module?

JohnAlbin’s picture

Title: Fix jQuery 1.7 for Drupal 7 » Release jQuery 1.7 for Drupal 7
Status: Closed (fixed) » Needs review

I'm unclear about when this will happen too.

alexweber’s picture

It's funny/sad that this took so long that 1.8 has been released in the meantime..

Anyway, baby-steps right? Can any of the maintainers take a look at this?

dddbbb’s picture

@alexweber I think you probably want to create a new issue for that.

klonos’s picture

alexweber’s picture

@dixhuit yeah i know dude :) what I meant to say was its been so tough that at this point lets get 1.7 in and worry about 1.8 later...

1.7 -> 1.8 doesn't have major backwards-compatibility issues AFAIK. 1.5.2 -> 1.7 is a huge leap on the other hand

dwieeb’s picture

Following, would like to see this done asap.

mattcasey’s picture

Once caveat with jQuery 1.8 is that it does not play friendly with all jQuery UI 1.8 plugins. The RC for jQuery UI 1.9 is out, however, and uses jQuery 1.8. http://blog.jqueryui.com/

Anonymous’s picture

@mattcasey please keep things relating to jQuery 1.8 in #1546668: Keep jQuery 1.8.x updated to the latest version available (currently shipping 1.8.2 - update to 1.8.3)..

I totally agree with @alexweber - lets do this incrementally, otherwise nothing will ever get done!

ericduran’s picture

IDK, I'm confused why this issue keeps geting re-opened.

1.7 is already available with this module.

klonos’s picture

...I guess it's because the default is 1.5 and people are not aware that this can be changed from the module's config page (if they even know that one exists in the first place). Also, the project's page still says:

Updates...
...
Drupal 7 to jQuery 1.5.2 and jQuery UI 1.8.11

...when it should say:

Updates...
...
Drupal 7 to jQuery 1.5.2 or 1.7.1 and jQuery UI 1.8.11

Which brings me to this question: Why do we have an older version of jQuery as the default when new versions are released in order to fix/improve older ones and everyone is looking to upgrade to the latest?

klonos’s picture

...PS: having 1.5 as the default kinda of gives it an edge (people don't know how or don't bother to change the default), but I really wish #1439316: Provide means for module maintainers to collect heuristics on certain settings of their modules. was implemented and we did collect some stats in order to see if the default should change to 1.7 (based on actual usage count).

mattcasey’s picture

Sorry jackocnr, I was bouncing around threads.. I will send my commment to that post!

shaneforsythe’s picture

The recommend version for this project is still 7.x-2.2
which only ships with jQuery 1.5.2

Are all incompatibilities issues fixed? Can the the -dev be moved to new recommended release?

RobLoach’s picture

*cough* 1.8 out :-)

klonos’s picture

dddbbb’s picture

*cough* read at least some of the thread before commenting :-)

JonathanHindi’s picture

Exposed Filters in Views with Ajax Auto submit breaks jQuery 1.7,

Chrome Inspect Error:
Uncaught TypeError: Cannot read property 'form' of undefined ajax.js:137

if (this.element.form) {
    this.form = $(this.element.form);
  }

Should I report it in a new issue?

Letharion’s picture

@#77, yes open a new separate issue about that.

Letharion’s picture

Could we please update the project page to state that 1.7 is an option (in -dev), as suggested in #70? :)

RobLoach’s picture

Ah, thanks! Sounds like this issue should be closed then? JonathanHindi, mind linking the issue for that?

Thanks for linking up #1546668: Keep jQuery 1.8.x updated to the latest version available (currently shipping 1.8.2 - update to 1.8.3).. Followed.

JonathanHindi’s picture

creatile’s picture

Hi I have tested the 2.x-dev version and I can't use the rewrite field option with jquery 1.7 enabled.

Letharion’s picture

@#80, I would just like the project page to be updated, stating that this issue is closed, so to speak, before this issue is actually closed. :)
@#82, Separate issue please.

Letharion’s picture

Status: Needs review » Fixed

Actually, looks like that request has already been granted. Hurray!

Status: Fixed » Closed (fixed)

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