On a fresh Drupal 7.17 install with JQuery 7.x-2.x-dev & Views 7.x-3.5.

Views UI breaks when trying to modify a field, disabling JQuery Update solves the issue. so this is my workaround for the time being...

Comments

frob’s picture

Version: 7.x-2.3-alpha1 » 7.x-2.x-dev

I have also come across this.

This happens with I enable jQuery 1.8, when I bring this down to 1.7 the problem goes away. I am using the rubik admin theme.

Basically this is causing this error. http://drupal.org/node/806696

When I make a change to views the ajax popup is broken and all ajax responses are returned to the screen. Bringing jquery back down to 1.7 fixes this.

rickmanelius’s picture

This might be related to #1847900: Update jQuery UI to 1.8.24

rooby’s picture

I get this problem in jQuery 1.7 or 1.8.

When I make a change to views the ajax popup is broken and all ajax responses are returned to the screen. Bringing jquery back down to 1.7 fixes this.

muka’s picture

rooby’s picture

Thanks for the info.

I decided the reason I needed newer jQuery wasn't worth the hassle of using a newer jQuery anyway.

Also, hot tip if you didn't know, you can link direct to comments like so:

#1494860-30: Views Rewrite Results UI Broken using JQuery 1.7

muka’s picture

Oh.. good!
In case you come back here, I've provided a minimal workaround patch for this problem here #1766240-8: Option to limit Jquery Update scope to front end only.
Thank you, L

laz0rama’s picture

i just did a fresh install of drupal 7.20, views/views_ui 7.x-3.5 and jquery_update 7.x-2.3.

as soon as i enable jquery_update, views breaks, regardless of what jquery version i have selected in the jquery_update options.

seems like a showstopper for jquery_update.

Kazanir’s picture

It is a showstopper, and it is kind of frustrating that a new "stable" version was released with such a known and broken issue with a module in such widespread use i.e. Views. Check out #1524944: Allow different version for administrative pages for a solution and in particular #1524944-72: Allow different version for administrative pages for a patch that should work on 7.x-2.3 -- 7.x-2.3 looks like it is identical to 7.x-2.x from last September.

jswainst’s picture

Take a look at the jquery update admin screen at /admin/config/development/jquery_update. You can select which version of jQuery to be loaded. i believe version 1.5 works best with Drupal 7.

geetotes’s picture

I can confirm that switching to jQuery 1.5 in jQuery Update does not break views UI, while switching to 1.8 in jQuery Update does.

T_T

laz0rama’s picture

just to confirm, with a fresh install of drupal 7.20, views/views_ui 7.x-3.5 and jquery_update 7.x-2.3, it DOES NOT MATTER which jquery version i select in jquery_update, views appears broken. i disabled jquery_update, and no problem. oh well.

i was still seeing some very weird behavior in views once i did my complete install: when trying to modify any options on a view (such as fields, sorting, whatever), the dialog window that opens was missing all options, and only contained the action buttons. it turns out the problem was in my own module, where i was unsetting a number of form elements (including 'options') in hook_form_alter, indiscriminately. i needed to make sure i was looking at a node form before doing the unsetting - once i did that, the views dialogs were fine.

frob’s picture

Just to confirm, with a fresh install of drupal 7.20, views/views_ui 7.x-3.5 and jquery_update 7.x-2.3.
Everything works just fine for me if I pick jquery 1.5. Things break when I pick 1.8.

This was a fresh install of drupal 7
Using minified or production both work. I tried all CDN combinations. I cannot get this to error on jquery 1.5.

I will say to make sure js aggregation is cleared when switching versions. If you are switching back and forth then you might be caught up using the other version from an old js aggregation.

jaypark’s picture

FYI, am using AT Admin theme, views UI works with 1.7, breaks with 1.8. the view will still update, even if the UI is hosed.

lv46gl’s picture

subscibe

frob’s picture

You don't need to subscribe any more. There is a follow button at the top of the page now.

geetotes’s picture

Is there a way to have the jquery 1.5 version only run in the admin section, while jquery 1.8 goes on the frontend?
Oh wait, there is a patch: http://drupal.org/node/1766240#comment-6969950

rooby’s picture

@geetotes:

Notice that that issue is closed as a duplicate.

The issue to follow instead of that one is this one: #1524944: Allow different version for administrative pages

caw67’s picture

Version: 7.x-2.x-dev » 7.x-2.3
Assigned: Unassigned » caw67

same error here: jquery version 1.7 works, version 1.8 breaks the views!

pfrenssen’s picture

Assigned: caw67 » Unassigned
Status: Active » Closed (duplicate)
herluk’s picture

Same error i went from jquery update 1.5 to 1.7 because i wanted to use the fancybox, and needs jquery update, but the same problem i had

geocalleo’s picture

So I've been having issues with this as well. My solution is to use a seperate admin theme without jquery update installed. I then in the .info file, for the theme I'm using to display my site, add my own downloaded version (in my case 1.9) of jQuery. This however is just a temporary workaround and in my opinion, jQuery Update should, until this issue is fixed, not be used in a production environment.

geocalleo’s picture

Okay as after I posted the above comment, I went and was about to update my views module with the latest and greatest. I noticed that in the notes it said "#1802198 by westwesterson, hswong3i, drumm | cjlgr: Fixed Views UI breaks with jQuery 1.8."

I haven't tried it yet but I'll install and see if it works. I'll make sure to post about my results once I've had a chance to play with it.

geocalleo’s picture

Okay so the update fixed the issue, at least with my setup, with jQuery 1.7 but not 1.8. Throwing my hands up in the air and just going with the workaround I previously posted for now.

criscom’s picture

jQuery 1.8 breaks Views 3.7. jQuery 1.7 and 1.5 both work. No patch applied. jQuery Update Version is 7.x-2.3

frob’s picture

This has been closed for a while now. I don't know why people keep posting. *Unfollowing*

fourmind’s picture

Okay, I haven't done any further testing to verify anything, but what I can say is that updating CTools from version 1.2 to 1.3 resolved the issue with Views UI and jQuery Update. I realize this issue is closed, but in case it helps someone else down the line.

I had tried updating Views to version 3.7 and that still didn't resolve with jQuery Update and jQuery versions 1.7 & 1.8 would not work with Views UI. I noticed CTools had an update available, updated it to version 1.3, and voila, Views starting working as expected again under jQuery 1.7. Again, limited testing but in case it helps save someone from pulling out their hair.

chrisjlee’s picture

Thanks @fourmind. That worked for me as well:
jQuery Update 1.7
ctools > 1.3

mrded’s picture

Version: 7.x-2.3 » 7.x-2.x-dev
Status: Closed (duplicate) » Active

Updating CTools from version 1.2 to 1.3 doesn't solve problem for me.
All versions of jQuery brakes my Views UI.

alphex’s picture

subscribing...

alphex’s picture

I set JQUERY to 1.7 in Jquery update configuration, and this fixed the problem for me... but yeah, obviously... this is an issue still.

adripop’s picture

Hello,
i think you could avoid having jquery_update in the admin section by replacing the function jquery_update_library_alter in jquery_update.module :

/**
 * Implementation of hook_library_alter().
 */
function jquery_update_library_alter(&$javascript, $module) {

  // We are updating just the system module. For all other cases we return.
  if ($module != 'system') {
    return;
  }
  if (path_is_admin(current_path())) {
    return;
  }
  $path = drupal_get_path('module', 'jquery_update');

  // Make sure we inject either the minified or uncompressed version as desired.
  $min = variable_get('jquery_update_compression_type', 'min') == 'none' ? '' : '.min';
  $cdn = variable_get('jquery_update_jquery_cdn', 'none');

  // Replace jQuery with the latest version.
  $version = variable_get('jquery_update_jquery_version', '1.5');
  jquery_update_jquery_replace($javascript, $cdn, $path, $min, $version);

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

  // Replace the jQuery Cookie plugin.
  $javascript['cookie']['js']['misc/jquery.cookie.js']['data'] = $path . '/replace/ui/external/jquery.cookie.js';
  // Noting the version based on git commit as no version number is available.
  $javascript['cookie']['version'] = '67fb34f6a866c40d0570';

  // Replace jQuery Form plugin.
  $javascript['jquery.form']['js']['misc/jquery.form.js']['data'] = $path . '/replace/misc/jquery.form' . $min . '.js';
  $javascript['jquery.form']['version'] = '2.69';

  // Replace files for jQuery 1.7 and up
  if (version_compare($version, '1.7', '>=')) {
    $javascript['drupal.states']['js']['misc/states.js']['data'] = $path . '/replace/misc/1.7/states.js';
  }
}
blasto333’s picture

This happens to me using jquery 1.8

drywall’s picture

Eight months after initially being reported and this is still broken. Sad.

tassaf’s picture

What is the solution for that? I cannot use jquery 1.5 in admin pages because I am using ajax in the front page and it's broken also

Any help please?

knalstaaf’s picture

knalstaaf’s picture

Status: Active » Closed (duplicate)
tassaf’s picture

Latest version of ctools was the solution
Thanks a lot

Aritas’s picture

Updating CTools doesn't solve problem for me.
Use Jquery 1.7 solve it. Strange Bug.

weri’s picture

The latest dev version from ctools and the version 3.7 from views solved the problem.

rlbusa’s picture

Updating CTools didn't solve the problem for me.
Updating jquery didn't solve the problem for me.
Installing the jQuery Update drupal module and updating the jquery version to 1.7 solved the issue.

GoddamnNoise’s picture

Issue summary: View changes

Updating jquery_update module to its last dev release solves the problem. It lets you select a default jquery version for the site and an alternative one to be used on administrative pages. Select the jquery 1.5 version for the administrative pages and the jquery version you need for your site and you're done.

gge’s picture

jquery 1.5 brakes some admin pages like create and edit content, list menu links, blocks page, etc...

GoddamnNoise’s picture

Hi gge!.

I've selected jquery 1.5 version for the administrative pages and I have no problems with those admin pages.

gge’s picture

Yes, you're right. It worked after I cleaned the cache...

Thanks.

kamenrs’s picture

Updating jquery_update module to it's latest dev version, alone didn't fixed the problem with Views UI.
Then selecting jQuery 1.5 for the administrative interface and cleaning the cache also didn't worked for me.
Actually non of the above works for me to allow Views UI to function properly, even disabling jquery_update module.

Update: Disabling BEF (Better Exposed Filters) module, automatically solved all my issues related to AJAX in Views UI.
Some experiments showed that selecting BEF as "Exposed form style:" in Views prevents Views UI from working correctly. I tried to rearrange filters and failed. Then selected Basic as "Exposed form style:" and everything worked fine. I made all changes and selected BEF as last opperation.
Using jQuery 1.7 for UI and 1.5 for administrative pages, I succeeded to make BEF work properly on the front-end but Views UI still behaves weird with BEF selected as "Exposed form style:".

rajmataj’s picture

I don't use dev modules on production sites, nor am I running Better Exposed Filters but selecting 1.8 as the Default jQuery Version at admin/config/development/jquery_update worked for me, restoring Views, Module Filter, Admin Menu and likely others. Using:

  • Drupal 7.26
  • jQuery Update 7.x-2.4
  • Views 7.x-3.7
dawnbuie’s picture

#43 + #44 worked for me.

GeDu’s picture

Worked for me too.

sircosta’s picture

#45 Worked for me! Thanks! ;)

If your view use Better Exposed Filters then you have to disable the module and the problem with AJAX in Views UI gone away. After, you must change the exposed filter back to the Basic exposed.

cdonner’s picture

I need at least 1.7 for the Bootstrap theme. Luckily, downgrading to 1.7 seems to work.

Georgii’s picture

artfulrobot’s picture

I came here because when using jQuery > 1.7 the 'states' were not recognised for checkboxes. e.g. under the style settings for a field in views, un/checking "customize field html" is supposed to reveal other form controls.

However this is a problem with Ctools, and core not jQuery update. My fixes are:

This fixes the particular problem I had with Views:

--- a/sites/all/modules/ctools/js/dependent.js
+++ b/sites/all/modules/ctools/js/dependent.js
@@ -97,7 +97,8 @@
           else {
             switch ($(trigger).attr('type')) {
               case 'checkbox':
-                var val = $(trigger).attr('checked') ? true : false;
+                // original used .attr instead of .prop, which fails with jQuery>1.7
+                var val = $(trigger).prop('checked') ? true : false;
 
                 if (val) {
                   $(trigger).siblings('label').removeClass('hidden-options').addClass('expanded-options');

And this fixes other cases to do with #states:

diff --git a/misc/states.js b/misc/states.js
index 6d98da8..3544a98 100644
--- a/misc/states.js
+++ b/misc/states.js
@@ -509,7 +509,7 @@ $(document).bind('state:visible', function(e) {
 
 $(document).bind('state:checked', function(e) {
   if (e.trigger) {
-    $(e.target).attr('checked', e.value);
+    $(e.target).prop('checked', e.value);
   }
 });
 
diff --git a/modules/field_ui/field_ui.js b/modules/field_ui/field_ui.js
index c2e8978..5e26f06 100644
--- a/modules/field_ui/field_ui.js
+++ b/modules/field_ui/field_ui.js
@@ -97,7 +97,10 @@ jQuery.fn.fieldUIPopulateOptions = function (options, selected) {
       html += '<option value="' + value + '"' + (is_selected ? ' selected="selected"' : '') + '>' + text + '</option>';
     });
 
-    $(this).html(html).attr('disabled', disabled ? 'disabled' : false);
+    // old drupal core:
+    // $(this).html(html).attr('disabled', disabled ? 'disabled' : '');
+    // patch for jQuery>1.6ish:
+    $(this).html(html).prop('disabled', disabled);
   });
 };
 
@@ -250,7 +253,8 @@ Drupal.fieldUIOverview = {
 
       // Disabled elements do not appear in POST ajax data, so we mark the
       // elements disabled only after firing the request.
-      $(ajaxElements).attr('disabled', true);
+  // attr->prop for jQuery 1.6+
+      $(ajaxElements).prop('disabled', true);
     }
   }
 };
frob’s picture

@artfulrobot please do not post on closed issues. This issue was closed as a duplicate two years ago. Also, you shouldn't hack core like that. The fix is to use the latest version of jQuery updates which allows users to have different versions of jQuery for different themes. See this issue for details #1524944: Allow different version for administrative pages

Your "fix" will break core functionality or require the use of the jQuery update module.

hockey2112’s picture

I just experienced this issue today, but jquery update changes did not fix it for me. The issue in my case was that I was accessing the website with "www", but the base_url in my settings.php file had the domain name without "www". Once I added "www" to the base_url, the issue was immediately resolved. The error message in Chrome's Dev Tools Console was "Uncaught Error: The callback URL is not local and not trusted"

jomarocas’s picture

i used jquery version 1.8 and working

apaderno’s picture