The javascript code breaks other AJAX fields like drag & drop for manage display or upload fields.

(function ($) {
  Drupal.behaviors.views_hst_filter = {
    attach: function(context, settings) {
      for (ajax_object in Drupal.ajax) {
        if (Drupal.ajax[ajax_object].options) {
          jQuery.extend(Drupal.ajax[ajax_object].options.data, Drupal.settings.exposed_form_info);
        }
      }
    }
  };
})(jQuery);
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ser_house’s picture

Where this occurs?

yannickoo’s picture

E.g. node creation/edit page or manage display, after disabling the module it works fine.

ser_house’s picture

Test it, please:

yannickoo’s picture

Cool, works fine but I think we should put that into an extra file so that it can be cached and please use single quotes instead of double quotes :)

yannickoo’s picture

Status: Active » Needs review
FileSize
1.52 KB
ser_house’s picture

Status: Needs review » Fixed

You're right. I made it.

Sk8erPeter’s picture

+1 for yannickoo, I just wanted to ask the same, to keep it separately in a JS-file, because in this way, this is hard to maintain, and can not be cached, and simply generates an inline code.

Thanks for ser_house for applying the changes, and for yannickoo for creating the patch.

yannickoo’s picture

And you forgot to attribute authorship to me again ;)

ser_house’s picture

And you forgot to attribute authorship to me again

Sorry, yannickoo, but I didn't use your patch because It is wrong.

again

When before?

yannickoo’s picture

The issue with the code clean-up, doesn't matter. When doing javascript in Drupal you should use camelCase that is the reason why I replaced ajax_object with ajaxObject. And the line break before the if was for better reading.

Sk8erPeter’s picture

+1 for the camelCase. :D

The problem why it didn't work was here, you didn't change all the ajax_object keys to ajaxObject.

+ if (Drupal.ajax[ajaxObject].options) {
+ jQuery.extend(Drupal.ajax[ajax_object].options.data, Drupal.settings.exposed_form_info);
+ }

yannickoo’s picture

Oh, my fault. I open a new issue and post a patch.

ser_house’s picture

Yep, camelCase... Mea pulpa :) Corrected.

yannickoo’s picture

Let us wait for this issue so that we can remove the javascript later. That is also the reason why I didn't touch exposed_form_info which should be also camelcased.

ser_house’s picture

@yannickoo

In issue "Clean up" commit message: "Issue #1841548 by yannickoo: Clean up code."

What else? I think it is important.

yannickoo’s picture

You're right and I cannot see it on my profile because this is still a sandbox, sorry.

barraponto’s picture

@ser_house this is how you attribute patches: http://drupal.org/node/1146430
anyway, let's close #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback first.

barraponto’s picture

@ser_house this is how you attribute patches: http://drupal.org/node/1146430
anyway, let's close #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback first.

yannickoo’s picture

Why you want to close #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback? We have to wait until the patch from #33 is in Views then we have to remove that part from the Views Hst module because the functionality is in Views then.

barraponto’s picture

@yannickoo that's what I meant. Let's [get the patch into RTBC and then finally commited with proper attribution and finally] close the issue :)

Status: Fixed » Closed (fixed)

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