I'm currently running into issues during development because I need 1.7 for stuff on the front-end of the site, but this is breaking administration pages for modules that are looking for an older version (like Views). This is really annoying, especially because it fails silently, and I don't really want to touch admin pages.

I'm not sure if this is something you guys are willing to consider, but I figured I'd give the patch a shot just in case, because I think it would be helpful.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jacine’s picture

Title: Allow different version for administrative versions » Allow different version for administrative pages
Zach Harkey’s picture

Brilliant. THANK YOU, Jacine!

bcn’s picture

Status: Needs review » Reviewed & tested by the community

Nice feature, thanks! Patch applied and is working.

Sharique’s picture

I tried applying patch but getting error.

git apply jquery_update_admin.patch
error: patch failed: jquery_update.module:78
error: jquery_update.module: patch does not apply

I'm using 2.2 version of module.

Zach Harkey’s picture

Run that patch on the 7.x-2.x-dev branch

realityloop’s picture

Wouldn't apply for us in a makefile, rerolled patch

moniuch’s picture

's wonderful!

pirog’s picture

works for me and i would love to see it included in dev and then later as part of a new release.

another thing to consider might be allowing users to "turn off" jquery update for admin pages (aka use 1.4.4). i know that there are still some mods (like admin, although fixed in dev) that break with 1.5.

if there is interest in this i could produce a patch.

moniuch’s picture

Guys, I applied that patch and now I noticed I'm unable to hide fields in Manage Display by dragging them into the "Disabled" group. Upon save the position reverts to original. The formatter menu also does not work. Hiding with row weights shown works OK. Can you confirm you can drag-disable fields on your sites? I'm not saying this has been caused by the patch, but chances are 50/50.

Jacine’s picture

#9, That's not being caused by this patch. I just double checked to make sure.

chapabu’s picture

@moniuch are you using the Google CDN to deliver jQuery? I found that the Google CDN version FUBAR'd a few things. If you are try it with another CDN or the supplied version.

If not - then I'm sorry for wasting your time ;-)

moniuch’s picture

@chapabu: I'm using jQuery CDN currently, but I'm going to change that to Google to check how "my mileage" will vary.

chymz’s picture

@Jacine : works perfectly, i love you !

rroose’s picture

EDIT: Never mind, I didn't use the 7.2.x-dev branch.

Trying to patch but getting the following errors:

[root@blackserver jquery_update]# patch < jquery_update_admin.patch
patching file jquery_update.module
Hunk #1 FAILED at 78.
Hunk #2 FAILED at 117.
Hunk #3 FAILED at 127.
3 out of 3 hunks FAILED -- saving rejects to file jquery_update.module.rej

dalberts69’s picture

Currently running into an issue in Panels administration, particularly where it calls and displays a modal window for settings. For instance, when adding a View block to a panel region, the following error occurs:

TypeError: $("form.user-info-from-cookie").once is not a function

I believe this is because Panels is calling ajax and returning the 1.7.1 version of jquery, as I can see it in the returned json, where this patch only reverts to 1.5 on admin pages based on path_is_admin().

EDIT: The only thing I can think of at the moment is to detect if it's an ajax request by the $_SERVER['HTTP_X_REQUESTED_WITH'] variable sent with the request by panels. I don't know or couldn't Google Fu the Drupal Way of checking for this server variable so I define my own.

Line 85 of jquery_update.module (patched with above):

  $current_path = current_path();
  define('JQU_IS_AJAX', isset($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest');
  if ((path_is_admin($current_path) && variable_get('jquery_update_admin', FALSE)) || JQU_IS_AJAX) {
hswong3i’s picture

Title: Allow different version for administrative pages » Allow different version based on page specific visibility configurations
Status: Reviewed & tested by the community » Needs review
FileSize
9.65 KB

In order to address the issue of #15, moreover coming with more flexible options for different jQuery version per specific configuration, here is an update patch.

This patch clone the "page specific visibility configurations" setup from googleanalytics, and default disable replacement for all administrative pages as refer to http://drupal.org/node/34970. On the other hand, admin can further more update the visibility list accordingly, too.

Patch via 7.x-2.x-dev; also double check all coding style with coder and so coming with additional cleanup. Please feel free to comment with your idea ;-)

Jacine’s picture

IMO, page-specific complicates matters way too much and it will not solve the problem in #15. If you've got Panels Everywhere enabled, you're basically back to square one, right?

The idea behind the patch and issue is that jQuery Update module should recognize that there can be a different theme for the front-end and back-end, and that the dependencies are often different. Drupal itself clearly recognizes this separation and even provides a hook for modules to register administrative paths, so I think it's only right that jQuery Update recognizes it as well.

It's not a promise that everything will work perfectly. Yes, there will potentially be problems when dealing with modules that depend on older versions of jQuery and stack administrative functionality on the front-end. Personally, I'm willing to accept those and I don't think it's responsibility of jQuery Update to deal with. Issues should be filed against the offending modules to request that they get their dependencies updated on the basis that they are forcing dependencies on front-end themes for administrative tasks, which is not cool at all.

I suspect that fear of bug reports like this coming in are the reason why the maintainers haven't responded here. I'm still holding out hope that this will be accepted as a few feature because I run into this on every single site I build. But if not, there's always hook_js_alter() which can be implemented in the front-end theme.

Zach Harkey’s picture

Category: feature » bug

I agree with Jacine. This simple but critical feature is being blocked by over-reaching.

The original patch could have prevented many of the issues in this queue.

I also think we should be treating this as bug instead of a feature request.

Jacine’s picture

Title: Allow different version based on page specific visibility configurations » Allow different version for administrative pages

Changing the title back to what it was originally.

ericduran’s picture

Honestly this is just a hack. This isn't really required.

The underline issue is really a core bug over at #1480568: use $.attr with false instead of empty string which has already been fixed.

If it wasn't for that bug, no1 would ever want to run different version fo jQuery. that would be too confusing.

I'm marking this issue as wont fix. I think the jquery_update maintainers would agree.

If you still want to do this see my answer over at http://drupal.stackexchange.com/a/41394/809 which doesn't required any patches.

ericduran’s picture

Status: Needs review » Closed (won't fix)
Jacine’s picture

Couldn't disagree more. I want the most up to date version of jQuery on the front end, and I could care less about the backend on 9/10 sites I work on. This is the exact response I expected, so I'm not surprised. However, I'd just like to note that this is enough of an issue for me that it makes me wish jQuery was not in core to begin with, and I know I'm not alone in that. Oh, well... hook_js_alter() it is (hook_library_alter() doesn't work in themes). :)

Zach Harkey’s picture

@ericduran, are you saying that #1480568: use $.attr with false instead of empty string guarantees that we can run the latest version of jQuery on the front end of our sites without having to worry about breaking any legacy (core/contrib) administrative UI's?

fabioloool’s picture

COOL!

Hope to see this feature in the stable version too!!!

jhuon’s picture

I currently facing the same problem explained in #15. IMO it's pretty annoying that we can't disable jQuery Update on the fly. I tried ericduran's solution to downgrade to jQuery 1.5 but I still got problems with Panels... It would be great if there was a hook to get back to original jQuery. For now, I don't know what to do, I need jQuery 1.7 in my frontend theme and I definitely need Panels in the backend.

JonMcL’s picture

Category: bug » feature
Status: Closed (won't fix) » Active

Am I going to get in trouble for opening this again? :)

I changed the category to feature request, since that is what it technically is. This has nothing to do with #1480568: use $.attr with false instead of empty string. That refers to one specific breakdown when a newer jQuery is used. I think the OP of this thread, like me, needs to downgrade jQuery for all admin pages, but allow 1.7 or 1.8 to be used on the front-end. This won't be a solution for every case. My site is not using overlay, Panels Everywhere, etc. My front-end is very complex though and needs a more current version of jQuery. My admin area runs a different theme (Rubik) and can function with the older jQuery.

@ericduran: I see that you have a possible alternative available at http://drupal.stackexchange.com/a/41394/809, but is there anything wrong with requesting this as a new feature of the module itself rather than having to implement a custom second module to solve the same task?

So I think this would be a great function to add to jQuery Update. I can't see any drawbacks. It might not work for everyone, but it solves an issue for many of us.

I used patch from #6.

Any solid arguments against including this?

ipwa’s picture

Maybe this can be solved with this idea: http://drupal.org/node/888334#comment-6647014

Nevermind, just read #17.

According to the commits the current maintainer is Rob Loach, so let him decide. I think Jacine's patch is spot on, @ericduran please don't mark this as 'won't fix' again.

ywarnier’s picture

The only issue I see would be usability for the non-developer admin. Somehow the documentation has to be very clear about the jquery_update_jquery_admin_version variable, but I agree that this is a good idea.

adamelleston’s picture

Agree with #26 - having to write a 2nd module to solve this issue is not a great solution.

The patch looks good and think this is the best way to implement this.

I am going to have to use this patch on 2 projects that I am about to start so would be a bonus if jquery_update got a release with @Jacine's patch in.

sjak’s picture

FileSize
82.87 KB

I recently moved my site from localhost to an Ubuntu 12.04 server and suddenly I no longer have the effect of @Jacine's patch.

I double checked jquery_update.module and the patch code was still there, but I have no option to use jquery 1.5 on admin pages.

The only difference I can think of is the PHP version, 5.4 on localhost, 5.3 on hosted.

Anyone know why I've lost the option from Jacine's patch?

fuerst’s picture

Original patch works well. As long as the patch is not applied to the module I prefere using the approach from http://drupal.stackexchange.com/a/41394/809 though.

ericduran’s picture

@ipwa It's perfectly fine for other people to mark and issue 'won't fix' ;-) just like it's perfectly fine for someone to decided actually it should be an 'active' issue.

As explain in the previous post, this is not a real issue with the jQuery_update module it was a core issue and other contrib module issue.

Also I think any sane person would agree that having multiple jQuery version on a single site is bad practice and horrible maintenance nightmare. Instead of insisting that jquery_update should support this crazy/rare/bad behavior we should encourage all other modules/contributors/etc.. to write good working Js code :) (Which we already do, and this was really just a problem with a jQuery change that was well documented and blogged about). So in short this should have been expected.

That being said I won't speak for the jQuery update maintainers but this future request seems a bit crazy for me :)

Anyways I'll leave this thread now. :)

ericduran’s picture

Ok, after much debate with @jacine on twitter it does make sense to treat the front facing app completely different.

I've personally been spoil because I use Drupal for data which I guess is unfair to those that do use Drupal for both data and templating to not be able to separate the backend and front-end.

Anyways here's an update patch. This one purposely places the variable_get('jquery_update_admin', FALSE) in the left side of the if statement. This way it short circuit the rest of the code if it's not enabled.

Also this is simpler than #16 it goes back to the original patch. I think the rest of the changes in #16 are good but probably belong in a separate issue.

fuerst’s picture

One general issue which isn't considered yet: Drupal 7 uses jQuery 1.4.4. Switching admin pages to jQuery 1.5 may help to avoid problems but is not 100% plain Drupal 7 behaviour. For instance when using 1.5 the upload/remove buttons from image fields are not working.

I think jQuery 1.4.4 which comes with Drupal 7 should be an option in addition to the jQuery versions provided by the jquery_update module. jquery_update_library_alter() simply needs to stop replacing the jQuery library if the Drupal provided jQuery version was choosen.

What do you think?

ipwa’s picture

Status: Active » Needs review

@ericduran I know and it is fine, but at this point in the conversation it should be up to the maintainer. ;)

Zach Harkey’s picture

Maybe we just need to create a new module called "jquery_that_designers_can_actually_use_on_their_websites_without_breaking_drupal".

ericduran’s picture

Status: Needs review » Reviewed & tested by the community

Marking this as RTBC :)

FYI, testing and review the patch is always helpful :)

gausarts’s picture

Tested, and looks great.
Option for not overriding anything (drupal default) should be in another issue.
Looking forward for a commit :)
Thanks to allow this unavoidable "crazy/rare/bad behavior"

fuerst’s picture

@38: You are right: Choosing Drupal's default (jQuery 1.4) is already another issue: #1548028: Make the default jQuery version (1.4.4) for D7 an option

paskainos’s picture

Until now I've avoided certain modules with jQuery Update dependency simply for this reason. The havoc wreaked on Views admin etc. is a nightmare. I agree with JonMcL in #26, and I have several use cases similar to what he outlined (i.e. Rubik backend, different complex front-end, etc.). I also really like the latest direction this has taken (#34, #39). I think everyone understands and agrees this isn't ideal, but without assembling a blacklist of offending modules (inconceivable), what viable alternative is there?
I like the 'leave it alone' option in #2 on #1548028: Make the default jQuery version (1.4.4) for D7 an option. But since that's not the direction taken here, in the end I opted to simply roll 1.4.4 in to #33 since I was experiencing issues based on what fuerst pointed out in #34. Works great! Thanks Jacine for the work on this, and everyone else too.

paskainos’s picture

Added 1.4 for admin too (Admin / Context Editor wasn't behaving otherwise).

gagarine’s picture

A temporary workaround using hook_module_implements_alter in a custom module http://antistatique.net/blog/2013/01/04/drupal-use-a-different-jquerys-v...

johnnyfofo’s picture

star-szr’s picture

For the record, RTBC +1 for #33. It accomplishes the feature in the issue title just fine. I really want to be able to use 1.4.4 for admin pages, but let's tackle allowing 1.4 in #1548028: Make the default jQuery version (1.4.4) for D7 an option.

gausarts’s picture

Hello all, I appreciate all workarounds, but we want a commit. Pretty please kindly do not comment for any workarounds anymore in an issue that provide patches. That will distract maintainer from a commit, and we are afraid to get this marked "won't fix" again. Please provide more test and reviews instead, that will help us all in the long run. Thanks for understanding.

star-szr’s picture

+++ b/jquery_update.moduleundefined
@@ -78,6 +78,15 @@ function jquery_update_library_alter(&$javascript, $module) {
+  // If a different version is specified for administration pages, use it instead.

Hate to say it but this comment should be wrapped at 80 chars :)

eusonic’s picture

Patch #33 works great for me.

In my opinion, this is an absolutely necessary feature. This solves jQuery compatibility issues I have been having with several other modules. For example: #1882466: File Browser function compatibility w/jQuery update to version 1.7 or 1.8

Let's hope we can get this committed soon.

-Cameron

DamienMcKenna’s picture

We (Mediacurrent) just ran into this problem on a project, so a huge +1 from us to get this committed.

DamienMcKenna’s picture

waitasecond.. how about simplifying the patch in #41 by only having the jquery_update_jquery_admin_version selector rather than checkbox + selector?

Albert Volkman’s picture

muka’s picture

#1766240-8: Option to limit Jquery Update scope to front end only allow for path selection as in the block.module

Isn't this an optional alternative worth to be considered instead of multipling jquery versions on the same page? (in my use case, using bootstrap frontend theme with latest jquery/ui and I'm happy with it)

muka’s picture

Hi, I don't want to make this an infinite issue but I've merged this patch with my proposal.
Attached an updated patch. The final result is something like this

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Needs work

(sorry, misread the last post).

DamienMcKenna’s picture

This needs some improvements:

  • The fields should be updated to indicate that 'jquery_update_jquery_version' is the default jQuery used throughout the site and that 'jquery_update_jquery_admin_version' is for overriding the selection on specific pages.
  • IMHO the jquery_update_admin option is redundant, it'd be a much better UX to have the first option of the 'jquery_update_jquery_admin_version' selector use the version selected in 'jquery_update_jquery_version'.
  • The code needs to be cleaned up to match the Drupal coding standards.
  • There needs to be a hook_uninstall to remove the new variables.
DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
7.14 KB

Try this out for size. It's an improved version of #52 with some simplified logic as described in #54. I also improved the '#states' logic to hide the fields to improve the UX.

aidanlis’s picture

@DamienMcKenna, your patch is great, however you've got a small bug in your comparison -- all form values are stored as strings, but you're doing a strict comparison to an integer constant, so this will never be true:

if ($visibility === JQUERY_UPDATE_VISIBILITY_ADMIN) {

Obviously you can't use a == comparison instead as comparing any string to JQUERY_UPDATE_VISIBILITY_ADMIN will be TRUE, but that may not be relevant if you've used numeric values for the other keys.

Cheers,

muka’s picture

Updated #55 (my fault)
if ($visibility == JQUERY_UPDATE_VISIBILITY_ADMIN) {
should behave correctly

Would be nice to have this committed so jquery/ui can be updated to latest versions too :)

Albert Volkman’s picture

Status: Needs review » Reviewed & tested by the community

I've tested patch #57 and it works as intended.

star-szr’s picture

Rerolled #57 to remove trailing whitespace, no other changes.

rolando.alevelbeyond’s picture

I'm getting this error message (i picked 1.4 for the admin backend):

Warning: file_get_contents(sites/all/modules/jquery_update/replace/jquery/1.4/jquery.min.js) [function.file-get-contents]: failed to open stream: No such file or directory en _locale_parse_js_file() (línea 1488 de /home/*****/public_html/dev/fad/includes/locale.inc).

I'm guessing I should just copy on over the default drupal jquery to that location and it should go away.. but maybe it should be included somewhere or it should reference the drupal default jquery instead of looking for it in the jquery_update module..

but great patch btw!!

eromba’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.39 KB
8.2 KB

I received a similar error immediately after selecting jQuery version 1.4 for the administration pages:

Warning: file_get_contents(sites/SITE/modules/jquery_update/replace/jquery/1.4/jquery.min.js): failed to open stream: No such file or directory in drupal_build_js_cache() (line 4915 of /.../drupal/includes/common.inc).

It turns out that the patch in #59 was handling the "1.4" case in the same way as the other jQuery versions, causing the browser to try to load jQuery 1.4.4 from the jQuery Update module directory. Of course, jQuery Update includes only versions 1.5 - 1.8.

I've updated the patch to handle the "1.4" case correctly by loading jQuery 1.4.4 from Drupal core. Please test!

Thanks to everyone who has worked on this so far!

lklimek’s picture

Patch from #61 works for me.

I like the "listed pages" option, which allows me to say that I want JQuery 2.8 only on node/* (that's where I really need it).

Great work!

pyxio’s picture

This works perfectly for me. Thank you soooooooooooooooooooooooooooooooooo much! This is a godsend for bootstrap users! Cheers, Kevin

muka’s picture

+1 #61 works

muka’s picture

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

One more: +1 #61 works.

Should be committed in -dev.

thank you.

CarbonPig’s picture

#61 works

andreab-1’s picture

how did you guys apply patch #61?

I tried "git apply jquery_update-1524944-61.patch"

from inside the jquery_update module directory, but nothing happens...

Albert Volkman’s picture

@andreab unless you have the project checked out, you'll need to apply the patch using 'patch -p1 < jquery_update-1524944-61.patch' in the jquery_update folder.

tsvensen’s picture

#61 worked great, just saved me right before a client review.

eusonic’s picture

Patch #61 works great.

star-szr’s picture

Revised patch to correct the capitalization of "jQuery".

Kazanir’s picture

I can imagine that a lot of people are about to be frustrated by the new "stable version" from 08 Feb breaking Views UI and not including this patch.

drupov’s picture

Patch from #72 worked. Thanks!

rerooting’s picture

Agreed with #73. In my opinion, views UI should work with all jquery versions that jquery update provides, implicitly, though this patch offers a workaround! The only problem is that some of us may want to use jquery 1.8 within /admin/* so... le sigh...

Jason Dean’s picture

#72 working well for me.

Even with Panels UI (so far, so good) once I set to switch on the following pages:

admin
admin/*
panels/ajax
panels/ajax/*

(Though Panels IPE still falls over...)

rerooting’s picture

Yeah it works for me as well, however this still feels like a workaround to me rather than an actual bugfix. I work with Twitter Bootstrap and really really need to use 1.8.2 or later in admin and on the frontend. Should we round up the outstanding bugs with ctools/panels/views and jquery version compatibility? Is this already being done somewhere?

muka’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
8.61 KB

The path selection fails on path like system/ajax (and probably on panels/ajax too)
An AHAH enabled form reload the core jquery (or the one selected if setted in the selection) causing a version mismatching.
Attached a patch proposal to handle it using the referrer path of the request.

mikeytown2’s picture

muka’s picture

Status: Needs work » Needs review

#78 Works for me.
Can someone else try with panels ui / AHAH form and give a feedback?
Thank you

btopro’s picture

worked for me but I get the angry broken folder in Chrome when running a different version in the admin window and in the front-facing site. If I refresh the page it's fine, seems like it might be a conflict between the two accidentally loading on the same page but not sure?

muka’s picture

Safer way to "sniff" ahah requests. Tested with mini-panels UI.

Stolzenhain’s picture

The patch didn't work with Views AJAX overlays (only by disabling scripts in Views UI or by turning off the alternative library), this is a welcome solution though to many problems arising on juggling jQuery versions.

Just one question – I patched and installed the .dev-version, which is older than the actual release branch – would this patch work there as well or can anybody give instructions on how to apply this feature on the current release?

Thanks! And again props for this solution.

star-szr’s picture

@Paracetamol - It's a bit confusing. The date displayed on the project page is when the release node for 7.x-2.3 was created. The last commit was September 27th, this is why a newer dev snapshot has not been generated. Commit log: Commits for jQuery Update

emcniece’s picture

+1 confirming #82

ericduran’s picture

Status: Needs review » Needs work

Well this patch got a bit out of hand.

We shouldn't do anything but switch the version. The ajax sniffing shouldn't be needed.

edit: Or the path sniffing.

amberau79’s picture

The patch in #61 broke Rules UI for me:

Applied patch
Selected default version 1.83
Selected alternate version 1.4 - administration pages only
Turned off CDN
Spent 6 hours 1.5 weeks later when I realised rules wasn't working trying to find out why because it threw NO javascript errors at all (or errors of any kind), but disabling jQuery update fixed it.

Problem:
Rules add/edit condition form wasn't reloading with the parameter form after condition selection. It failed silently.

I do need to use jQuery 1.8 on the front end so will have to continue trying to find a solution.

Edit: works with 2.3 & patch in #82

muka’s picture

Rules works for me with #82.
@ericduran imho, this is the minimal set of things needed to make the pieces work togheter

Danny Englander’s picture

I am so thankful I found this issue, I was wracking my brain trying to figure out what was wrong with Views Ui as there were no in your face error messages but of course after adding up 1 + 1, I came here. The patch in #82 works as expected and this is a really nice feature. Thank you!

star-szr’s picture

This did get really complex (@ericduran in #86). I was going to say, can we just work on something based on #41, which IMO has a much higher chance of being committed, but…

Attached patch combines #41 with #61, minus all the path sniffing and ajax sniffing stuff. Doesn't work with Rules UI, just posting it here so that others can test and to make sure I didn't miss anything obvious. #82 does work with Rules UI.

So maybe we do need the ajax sniffing, but I'm not sure I'm convinced we need the path sniffing.

DamienMcKenna’s picture

@Cottser: The #states logic doesn't need to be put on a custom container, see my patch in #55 for a cleaner way of handling it.

star-szr’s picture

@DamienMcKenna - Thanks, I did miss that when bringing in the changes from #61, I just put it together quickly. The patch is just meant to show that we probably do need the ajax sniffing to make this work 100%. IMO we should remove all the path sniffing code from the latest patch (#82) but that might just be me (and @ericduran).

muka’s picture

mmh, so /imce won't work..

timdiacon’s picture

original patch works perfectly for me - really useful - Thanks!

Stolzenhain’s picture

I don't use Rules and the patch in #90 worked for me, while #82 didn't.
Thanks for your many efforts!

star-szr’s picture

@Paracetamol - What exactly didn't work for you with the patch from #82? That information would be very helpful in moving this issue forward.

Stolzenhain’s picture

@Cottser – here's what I did:

  1. I applied the patch from #82 to the latest jquery_update dev version, got the menu selection and chose 1.5/1.4 as alternative library for admin pages.
  2. I opened Views and clicking on a field simply showed the loading icon, but no overlay appeared, so I guess somehow the AJAX call didn't get through.
  3. Turning of AJAX in Views settings resulted in normal behaviour (also the sub-forms for display settings toggled as expected – contrary to Views with regular jquery_update on 1.8)

I didn't test on other pages with AJAX calls (as mentioned below for the stripped down patch)

More information on the patch from #90 as I already found 2 Drupal components not working (patched against the current module release – I don't know if there is a difference):

  1. Field display management hangs on AJAX call, when changing display status
  2. button for adding rows on multiple fields doesn't work on node forms

… still way more convenient than changing the jquery version every time I need to edit a view with field options.

ericduran’s picture

Status: Needs work » Needs review
FileSize
3.92 KB

OK so I read every comment and sadly it's always going to be impossible to make everyone happy.I do want to get this fix and into a release asap since this is a big issue. I've taken into consideration everyones issue and try to come up with the most generic implementation but not to crazy.

So this patch fixes any ajax issues correctly. No path sniffing involved. This uses the drupal ajax_page_state setting which will be included in any proper drupal.ajax request which means it'll work for Panels, Views, etc.. Also this does not piggy back on other ajax_page_state it just adds its own by adding an extra settings on the Drupal.Ajax library which again will be included in any proper ajax request from Drupal.

Also this patch removes the option to keep 1.4 This is not really necessary. 1.5 Works just as good as 1.4 and remember this is the jquery_update project. It updates jQuery so the extra code require for handling 1.4 isn't justifiable in this project.

So this really does fix everyones problem. I've done a crazy amount of testing, that being said I'm sure it's possible this might have some issue. So please test and give me feedback. If no feedback is received in the next couple of days I'll just commit this to the repo.

Thanks everyone for all the comments :)

Also note: As soon as this fix is in, I will go through all the jquery 1.7, 1.8 issues and get those fixed. So the sooner this is in, the sooner you will no longer need a different admin version ;-)

Stolzenhain’s picture

Hello! Thanks for your hard work - the patch in #98 works in all situations I encountered; can't speak for Rules or Panels though.

There is only one optical glitch in using Views/CTools overlays: On opening the overlay for the field editor, it gets positioned on the top left corner of the window instead of being centered. Reszizing the window re-centers it, so this probably has to do with the order of script inits – nothing that breaks any functionality though. (for reference I tried the core overlay function on some pages – didn't encounter any optical glitches there)

ericduran’s picture

@Paracetamol Yep, that is specifically at jquery 1.8 issue and overlay. I've taken note of that and is on my list of things to tackle once this is in. This only happens when you have 1.8 in non-admin pages right? and 1.5 or so in admin.

Good catch, This is something we'll tackle right after.

Stolzenhain’s picture

Hello!
Sorry to chime in again on the patch on #98: The aforementioned problem of not being able to add rows to multiple value fields persists, but not consistently.

For testing: I created a node type with several multiple value fields: Adding values worked on one of the fields, but not on the other. (not even showing a loading notifier)

Upon saving, this behaviour was reversed, now the second field was able to add rows, while the first wasn't. Guess this has something to do with multiple AJAX requests from the same node form.

The loading notifier sometimes appears the first time (not resulting in anything), on some instances, nothing at all happens while clickinh on "add another item".

So right now, I'm adding values one row per node edit (an additional row is added on the next edit).

star-szr’s picture

Please, forget about the patch in #90! :) I should have never posted it.

Unfortunately I haven't had a chance to test #98 yet. Anyone else?

DamienMcKenna’s picture

@ericduran: Yes, the project is jQuery_Update, but how many maintainers will be likely to fix JS compatibility problems that arise in their modules because sites are forced to use 1.5 on admin pages because they need a newer version for public pages? There wasn't that much code to add 1.4 support.

Stolzenhain’s picture

@Cottser – sorry, I was actually talking about #98 …

ericduran’s picture

@DamienMcKenna 1.5 doesn't break anything. All the views UI, Fields UI, Sates, etc.. That all works with 1.5

Also once this patch gets in, I'm going to give all the contrib modules to work with all the latest jquery_version and compatible with the older version.

Sadly I can't get to that until this is fixed :)

michaelgc’s picture

This is what I get from #98: Link to Image (imgur direct link)

Edit: Seems to work so far

ericduran’s picture

Status: Needs review » Fixed

Ok this is now committed.

This issue is fixed now. In regards to allowing 1.4 we can take that into a separate issue.

Give it some time before it shows up in the dev release. I'm going to make a hit-list for 7.x-2.4 which will hopefully fix all the jQuery woes currently going on with everything.

Thanks everyone :-D

--
http://drupalcode.org/project/jquery_update.git/commit/469fac0

Dave Reid’s picture

Crazy thought, what if the jQuery version was actually per-theme, and was exposed in the theme settings instead? Maybe a followup if anyone is interested, but just wanted to put the thought out there.

DamienMcKenna’s picture

@Dave: Only if it was an optional way of doing it, to allow for sites that use the same theme for the public and admin sides.

MauMau’s picture

Use http://drupal.org/project/jqmulti instead of Jquery Update.
Then core will be able to run on and old jquery alongside your new code running on a newer version of jquery.

Status: Fixed » Closed (fixed)

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

Stolzenhain’s picture

Hello! Sadly the problem mentioned in #101 still exists:

Having more than one field with multiple rows on the node form breaks AJAX requests on adding new rows (and the node form altogether afterwards).

Does this problem belong here or in a new issue?

emcniece’s picture

I believe #105 has your answer - use jQuery 1.5 on the administration side. This is unfortunate, there are some plugins (like fancybox) that require 1.7 or higher even in the admin interface... but I think the issue of AJAX breaks might belong in core or in Panels issue queues instead.

Stolzenhain’s picture

Hello!
I use the module to deploy version 1.5 on admin pages. This fixes Views administration. The aforementioned problem with field rows has nothing to do with the jQuery version though – it works fine with 1.8 and it starts to work again, when I turn off the feature of having a separate library in the admin theme.

The error mentioned before seems to be introduced by AJAX sniffing of this feature to detect, if an administration page is served which seems to confuse certain requests.

EDIT: I also encounter problems on the node field visibility page – changing the status of an element results in freezing the page

Zach Harkey’s picture

This is the Jason Voorhees of Drupal issues.

tomas.souto’s picture

It works very well, thanks!

Ice-D’s picture

Using any version except 1.4.4 breaks the Rules interface. What's so bad about allowing the user NOT to load ANY special version of jquery on admin pages? The core version is just FINE on admin pages!

rooby’s picture

Depends if you have customised admin pages that require newer jQuery plugins.

There are most definitely use cases for having higer versions in some admin areas of the site.

Ice-D’s picture

Well, how about an option to bypass the module entirely for admin pages?

berliner’s picture

There are additional considerations on this topic here: #1969244: Specify jQuery version per theme