Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I need to create a pair of dynamically interacting selects. The content in the actual exposed filter needs to be grouped, so i added a select with the group names that should, on change, load the coresponding items in the second select (the exposed filter).
I used hook_form_alter to add the select that triggers the ajax call.
My problem is that the ajax call does not trigger the callback function. I tested the same code in the form_alter of a node's add page, and they work correctly.
Any suggestions?
Comment | File | Size | Author |
---|---|---|---|
#154 | views-ajax_callback-1183418-154-D7.patch | 4.38 KB | Liam Morland |
#152 | views-n1183418-152.patch | 4.29 KB | pbirk |
| |||
#146 | views-n1183418-146.patch | 4.3 KB | DamienMcKenna |
#146 | views-n1183418-146.interdiff.txt | 893 bytes | DamienMcKenna |
Comments
Comment #1
andreicio CreditAttribution: andreicio commentedUpdate:
First problem: views preprocesses only the filters defined and exposed, ignoring all other widgets. The result is that the "form_id", "form_build_id" and "form_token" did not make it into the form, so the ajax call was incomplete. I added them to the #info array, so they would be rendered as filters.
Second problem. They arrive in the preprocess function with the #access set to false. I hacked it to set it to true, and it worked. Now the ajax works.
Current problem: Filtering no longer works. The list loads correctly, but when I click the filter button, even without setting any filter, there are no results. If I just comment the #ajax part for the widget I added then it all works, so it's not an issue with the newly added filters but rather with the js. I'm stuck again :(
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedViews are $_GET forms and they specifically remove the form_id and form_build_id and form_token because they are 'submitted' even when they aren't submitted. That means the standard #ajax tools don't work with them, since those rely on being able to cache the form in core's form cache. That system is to naive to work with core's filters. I've never really tried to do anything like this in D7 yet, so I don't know what the solutions might be, but I can say that it's going to provide very ugly URLs if you hack the form id back in.
Comment #3
joelstein CreditAttribution: joelstein commentedandreicio: Can you please post what you used to do this? I'm trying to do the exact same thing, and it just won't work for Views forms.
Comment #4
andreicio CreditAttribution: andreicio commentedOk, I made it work.
@merlinofchaos, I would love to read your comments on this idea. Maybe it can be implemented in a cleaner way inside views.
So. The only problem was that the ajax call needs form information in order to work (access form from cache) while views needs that information omitted (access form NOT from cache). My solution was to add an invisible and disabled select with all info in it, then add the info when ajax is called.
In php, inside the hook_form_alter() for the views exposed form:
In js, override the Drupal.ajax.prototype.beforeSubmit function with this one:
This way, if an ajax call gets made, the form info gets submited, while views' exposed filters stay clean.
One last note: in the ajax tutorial they tell you to expect the submited values in $form_state['values']. That is true for the ajax call, but if you just submit the exposed filters form, the values are in $form_state['input']. So you should do something like this:
Comment #5
joelstein CreditAttribution: joelstein commentedPerfect! Thank you very much for this. I was able to get my form_alter and Ajax callback working, thanks to your explanation.
(It was even more cumbersome for me, since I needed to alter two filters based on the value of one filter, and since Views wraps the filter widgets in it's own classes, the #prefix and #suffix settings don't allow you to wrap two fields together nicely. I had to return my whole form in my Ajax callback, and manually reset the $form['#method'] to "get" to make it work.)
Still, I wish there was a way to do this in a more elegant way. Perhaps we could assign some form value which Views could look for, and if it was present, the Javascript you have above would populate the form values on Ajax submit. We don't necessarily need to pass a select value, though. We could just as easily pass those values as Drupal Javascript settings (which makes sense, since it deals with Ajax).
Comment #6
merlinofchaos CreditAttribution: merlinofchaos commentedThat's a really awesome way to do it. Sadly a little bit manual, but it will do the trick. This should be documented somewhere, because people will need to know how to do this.
This would be good for the API section of the advanced help.
Comment #7
andreicio CreditAttribution: andreicio commentedOk. Updated version: This code is the ajax fix that needs to go in hook_form_views_exposed_form_alter():
Only one problem remains after this. As I mentioned before, submited values can be found in $form_state['input'] for a normal views submit and in $form_state['values'] for an ajax call. One solution is:
After that the default values for widgets will always be found in $form_state['input'] even for ajax calls.
And another note:
If you want to position your extra widget(s) in the exposed filters form you need to also add info to the $form['#info'] array in the correct position.
For example, to add a "brand_selector" widget right before a filter called "model_selector":
@joelstein:
I had to do similar stuff. One option is to copy views-exposed-form.tpl.php to views-exposed-form--YOUR_VIEW_NAME.tpl.php that will be applied for your particular view, and edit that.
Comment #8
joelstein CreditAttribution: joelstein commentedUsing Javascript settings is a nice solution, but my form now only behaves correctly on the first Ajax request. Since I am returning the entire form via Ajax, I'm guessing that the behavior needs to be re-attached or something after the first Ajax response. (I tried using the template file, but couldn't get it to work... not even after I flushed my caches... strange.)
Here's a solution which is working for me, using a Drupal "behavior". This can be done in a form_alter function... or, we can have Views sniff the form for any #ajax elements, and then add the Javascript if it finds some. Here's a proposed new version of views_form_views_exposed_form_alter().
Still to be considered is where we'd merge the $form_state['values'] and $form_state['input'] arrays.
Comment #9
andreicio CreditAttribution: andreicio commentedNice. I'm rather new to drupal, and still unsure how to use behaviors. Your solution is perfect.
The first 3 lines aren't needed though, since #access already is false, or at least it was for me. I had to change it to true in order to get them to render.
The foreach loop could even be integrated in views, I'd say. merlin's choice, I guess.
Comment #10
joelstein CreditAttribution: joelstein commentedLook a little closer... I was actually implementing this within Views in the example above. :)
Comment #11
andreicio CreditAttribution: andreicio commentedAh. Even nicer! :)
Comment #12
merlinofchaos CreditAttribution: merlinofchaos commentedChanging this to behaviors basically means changing this:
jQuery(function(){
to this:
And making sure the ) is rebalanced at the end.
Comment #13
joelstein CreditAttribution: joelstein commentedYep, that's what I did in #8 above.
Comment #14
andreicio CreditAttribution: andreicio commentedQuestion: views_form_views_exposed_form_alter is an implementation of hook_form_views_exposed_form_alter, right? If so, how do you know it's the last one to run? If i have mymodule_form_views_exposed_form_alter that creates a #ajax, then it has to come first, in order to actually have a #ajax that the foreach loop can find.
If indeed this is a issue, wouldn't this code work better in the template_preprocess_views_exposed_form function?
Comment #15
merlinofchaos CreditAttribution: merlinofchaos commentedViews is module weight 10 -- the vast majority of modules are lighter than this. We can't guarantee it's last but it'll be nearly last.
Comment #16
neoglez CreditAttribution: neoglez commentedJust for the record, very nice (and clean) things can be achived by taking advantage of the now (Views 3) available exposed form plugin implementation.
Comment #17
nicodv CreditAttribution: nicodv commentedHi there, I see the level of this conversation is higher than my knowledge, but i need to constructo a user (register and profile) form_alter including an ajax dependent dropdown and I have THE problem: ajax don´t work.
So, after reading this thread I more or less understood everything but I see you didn´t say anything final about the merging of $form_state['values'] and $form_state['input'] arrays... where do I have to place it?
Any help will be really welcome (It took me 3 days to finish the dropdowns :P)
Thanks a lot.
nico
Comment #18
merlinofchaos CreditAttribution: merlinofchaos commented#17: Sorry but this discussion is about views exposed filters, which are a very special form. This is not an appropriate place to ask about other forms.
Comment #19
mdrechsler CreditAttribution: mdrechsler commentedUsing the code in #8 allows my hook_alter AJAX code to "work" for an exposed view filter, and I'm trying to set my $form_state['values'] and $form_state['input'] to be the same, but submitting the form doesn't return any results, and I'm not sure how to check to be certain all my fields are being passed properly. I was thinking of setting them equal as part of the callback function, but those are only called for 2 of my 3 fields.
If I do a dpm($form) or dpm($form_state) as part of my callback I think I can see the inputs getting set, but I'm not sure where to set them for certain for the submit. I tried hooking into hook_submit to set them but didn't have any luck with that.
I hope I'm not rambling too much, I've very new to Drupal development, and feeling very frustrated.
I'm not even sure its the inputs holding me back at this point. Could anyone share some working code?
Comment #20
paolomainardi CreditAttribution: paolomainardi commentedThanks guys, you made my day! It works like a charm.
Comment #21
32i CreditAttribution: 32i commentedFollow-up to #8 and why solution mentioned in #7 working only first time - it's simple, after first request, select lose it's wrapper, so on second call, ajax don't have the wrapper where it should put the response.
So, it can be fixed by wrapping the element returned by callback in the same wrapper.
Comment #22
gillarf CreditAttribution: gillarf commentedThanks from me too - exactly what I needed.
Can this go into View hacks?
Comment #23
ACD CreditAttribution: ACD commentedGuys, so what is the last working variant for this?
I used the code mentioned in #7, but it work only for one element. But I have 3 select fields, each depends on the others, so when I changed the 2nd - the 3rd doesn't change. Any ideas why?
Thanks in advance
P.S.: I took the code from #8 and put it in the end of my hook_form_alter and it works properly. (at the first time it didn't). Thanks a lot!
Comment #24
gilzero CreditAttribution: gilzero commentedSub +1
Comment #25
barraponto CreditAttribution: barraponto commentedSo, basically, can we:
processafter_build to the exposed form elements, so that IF they have ajax properties, they get this hacks by default?I'll try and put up a patch once I get this hack working.
Comment #26
barraponto CreditAttribution: barraponto commentedSo, I moved all of the javascript logic to a separate file, and all of the PHP logic into an
#after_build
callback. What's left is the merger of$form_state['values']
and$form_state['input']
. After_build is too late to merge, but views' form_alter is too late as well. We're doomed to merge (if we want to) in our own form alter hooks.Of course, this needs documentation (but way less documentation than before).
Comment #28
barraponto CreditAttribution: barraponto commentedI had already seen that coming.
Comment #30
barraponto CreditAttribution: barraponto commentedkeep posting the wrong patch...
Comment #31
barraponto CreditAttribution: barraponto commentedActually, anonymous users don't (usually) get tokens. right?
Comment #32
RogerRogers CreditAttribution: RogerRogers commentedJust wanted to say that I applied the patch from #31 and it worked. Thank you barraponto!!!
Comment #33
yannickooI just renamed the file to
exposed-form-ajax.js
(replaced the underscores to dashes) and I replacedajax_object
withajaxObject
. In Javascript you should use camelCase. I think we have to check the callback because this was an issue in another module.Comment #34
scottrigbyAfter applying #33 I was finally able to use FAPI #ajax params on exposed filters.
Comment #35
barraponto CreditAttribution: barraponto commented@yannickoo can you elaborate on the callback issue? I want to see this commmited.
Comment #36
yannickooI will work on that later okay?
Comment #37
yannickooThe callback issue is not easy to solve because you can set the name of the callback. On "Manage display" there is a callback "field_ui_display_overview_multistep_js" which we don't want to extend with the exposed form info.
The patch uses "ViewsExposedFormInfo" instead of "exposed_form_info" as Drupal.settings name.
It is strange that I have no drag&drop issues like earlier.
Comment #38
Bart Vanhoutte CreditAttribution: Bart Vanhoutte commented#37 does the job.
Comment #39
InternetDevels CreditAttribution: InternetDevels commented# 37 breaks any other forms with #ajax on the same page. ajax_get_form() receives wrong form_biuld_id after the patch applied.
Comment #40
yannickooOkay that is the problem I expected... We have to check the callback name but I don't know how we can get it hm :/
And does the patch work for multiple altered exposed forms?
Comment #41
InternetDevels CreditAttribution: InternetDevels commentedAttached patch fixes both other forms with #ajax and multiple altered exposed forms, but I'm not sure about the way it is done.
Comment #42
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedHi,
Patch #41 works for me except when I use ajax along with the module Views Dependent Filter that hides exposed filters via Ajax too. Looks like there is a conflict somehow, I opened a separate issue not to mess with the readability of this one but if you guys could help me out on that one too that would be awesome.
http://drupal.org/node/1959370
Thanks!
Comment #43
lathanThis patch is not working for me i keep getting 'Invalid form POST data.' http://drupal.org/node/1922342 when trying to add a dependant drop down to an views filter option form.
Something like this.
Comment #44
bsuttis CreditAttribution: bsuttis commentedWanted to chime in and say the patch at #41 works against 7.x-3.7, thanks.
Comment #45
InternetDevels CreditAttribution: InternetDevels commentedProblem was in element_children(), which looked only on the first level of the form. Attached patch should fix this behavior.
Comment #46
InternetDevels CreditAttribution: InternetDevels commentedForgot to remove console.log from js.
Comment #47
lathanThat is still failing for me. I have attached screen shots and the views_handler_filter_in_operator i have extended that I am using.
Comment #48
frankdesign CreditAttribution: frankdesign commentedJust to let you know, patch at #46 worked for me on Views 7.x-3.7.
Comment #49
barraponto CreditAttribution: barraponto commented@jucallme what version of views were you using?
Comment #50
lathanIm on the 7.x-3.x branch specifically commit f7cb51aad6943973e22197d54d202453292d6a27
Comment #51
doliveros CreditAttribution: doliveros commentedI can also confirm that #47 worked. It should be committed IMO.
EDIT: Sorry guys, I meant #46, not #47
Comment #52
barraponto CreditAttribution: barraponto commentedWe have some feedback calling for RTBC, but @jucallme says it doesn't work with that particular commit. @jucallme can you try upgrading your views module? that commit is pre 3.6.
Comment #53
yannickooGuys, why do you say that #47 should be committed? There is only a zip file with a file which extends
views_handler_filter_in_operator
class. That isn't a patch and I don't know how it is related to this issue here.Comment #54
lathan@barraponto i have updated views to the latest dev code and i am still getting this error.
To make it easier for other to test this issue i have created a sandbox with this handler.
git clone --branch views_form_alter_test jucallme@git.drupal.org:sandbox/jucallme/1978134.git addressfield
enable addressfield and create a view with an administrative area field filter. Selecting the country throws the error i have been speaking about. The code associated with that can be found in addressfield_views_handler_filter_administrative_area.inc
Comment #55
yannickoo#54 are you sure that you are in the right issue? This looks more like an Address Field issue what you try to do.
Comment #56
barraponto CreditAttribution: barraponto commented@yannickoo I guess we're saying #46 is rtbc-candidate, but #47 points to a possible issue.
Comment #57
lathan@yannickoo Read #43 there i point out what i am doing in the patch to addressfield.... in which i need to implement a dependant drop down to an views filter option form. I have attached what i am working on simply for your connivence to test this case where by this patch here is failing. Else follow the steps i pointed out in #43 and implement your own dependant drop down in a views options form and you will have the same experience.
Comment #58
InternetDevels CreditAttribution: InternetDevels commented@jucallme, sorry for taking so long to reply. I've looked more closely at your code attached at #47. Your problem isn't related to the exposed forms, but to the views handler's settings form. Please consider views_handler::options_form() and it's usage in the views_ui/includes/admin.inc. Views uses some own mechanism for ajax processing.
Anyway, I'm not sure that solution used for the exposed forms can help for handler options form. I may try to find any other way, but I think it should be a separate issue.
Comment #59
barraponto CreditAttribution: barraponto commented@InternetDevels can we mark this as RTBC again?
Comment #60
fortis CreditAttribution: fortis commentedi think we can just use hook_views_ajax_data_alter(&$commands, $view) and $view->exposed_raw_input
and it's better way
ps:// SFME
Comment #61
MixologicIm having some troubles with the patch in #46. For some reason the normal exposed filter, when used in a block, becomes a POST instead of a GET. If I comment out line 17 of the javascript file,jQuery.extend(Drupal.ajax[ajaxObject].options.data, Drupal.settings.ViewsExposedFormInfo[name]);
, then it stays as a GET.Hmm. Actually this is because Im replacing the whole form as I've got seven dropdowns that are interdependent upon each other. If I dont explicitly set the form method to GET it comes back to the ajax call as POST.
Comment #62
MixologicSetting status back.
Comment #63
DartDruart CreditAttribution: DartDruart commentedHi guys, I'm tried to make two interdependent dropdowns. I'm using #7 and has encounter error in ajax.js in line 133 (Has anyone encountered this error). I tried to catch it and discovered, that element_settings.url become as array.
I'm using this code in my module
Has anyone encountered this error?
Comment #64
danharper CreditAttribution: danharper commentedHas this been committed yet?
I could do with this patch but don't fancy using patched version of views on a live site.
Cheers
Comment #65
thesame- CreditAttribution: thesame- commentedI'm also interested in this. Is this going to be committed?
Comment #66
mr_scumbagI just needed this, and patch at #46 is not committed to views, so I needed to apply it myself.
I applied the patch at #46, and my ajax powered views exposed form now works just like regular FAPI ajax powered forms do. Using hook_form_views_exposed_form_alter() to add the ajax
Is this patch expected to be committed to Views?
(It adds really useful functionality, which makes views hook_form_alter() with ajax work just like it should.)
Comment #67
barraponto CreditAttribution: barraponto commentedI guess everyone is on the D8 bandwagon... but you can try mailing the mantainers through the contact form.
Comment #68
heddn#46 RTBC on yet another site.
Comment #69
mareks CreditAttribution: mareks commentedI can confirm that #46 works for my form_views_exposed_form_alter with Views 7.x-3.7. It nicely reacts to my select list changes.
However, it does not seem to do anything when I enable Better Exposed Filters module (BEF) and change the "Default select list" to "Checkboxes/Radio buttons".
Maybe I'm holding it wrong :) Can anyone else test the Radio buttons vs Default select list use case?
In case of a radio buttons, should the callback be coded differently?
Thanks,
Comment #70
bneel CreditAttribution: bneel commented#46 works great, but if you have a dynamic form with new subform appearing after ajax call (like herarchical select form). The drupal.settings contain form_info for the initial form, not the updated form. Hence, the newly subform does note trigger the callback.
To resolve this issu, don't attach setting to the form in the #after_build callback, but use drupal_add_js().
change
To
drupal_add_js() update the drupal.settings, not the settings attached to the form.
Comment #71
barraponto CreditAttribution: barraponto commented@bneel can you provide a patch?
Comment #72
bneel CreditAttribution: bneel commentedET voilà
Comment #73
jonhattan#72 is missing file js/exposed-form-ajax.js. Rerolled.
Comment #74
geekygnr CreditAttribution: geekygnr commentedI applied #73 to 7.x-3.7 while trying to do this and it works great.
Comment #75
henk CreditAttribution: henk commented#73 confirm, works for me also, thanks!
Comment #76
mas0h CreditAttribution: mas0h commentedAfter applying #73, when trying to add new filter to the view I can't search for fields now in the view when selecting filters or fields, no matter what I write in search field values don't change.
Comment #77
geekygnr CreditAttribution: geekygnr commented@mas0h I can't replicate the problem you described. What version of views did you apply #73 to?
Comment #78
mas0h CreditAttribution: mas0h commentedGreetings Geekygnr,
I applied the patch against 3.7, but I suspect this issue is related to this module https://drupal.org/node/2168371
It is supposed to limit views exposed filter to the used terms in the results.
Comment #79
frankdesign CreditAttribution: frankdesign commentedHi, Has anyone got this working on Views 7.x-3.8? I'm anxious to upgrade as it is a security update but the patches at #46 and #73 only seem to work on Views 7.x-3.7.
Thanks
F
Comment #80
i.bajrai CreditAttribution: i.bajrai commented#73 does not work in views 7.x-3.8.
line 2077 views.module
remove weight from the attachment and all works again.
Comment #81
dariogcode CreditAttribution: dariogcode commentedI can confirm it is working with latest 7.x.-dev version.
Comment #82
aleksijohansson CreditAttribution: aleksijohansson commentedAlso confirming that #73 works with Views 7.x-3.7. Tested on a view that is somewhat complex.
Comment #83
Vj CreditAttribution: Vj commentedTested the patch #73 with views 7.x-3.8 and it works great :)
Comment #84
pcrats33 CreditAttribution: pcrats33 commentedTested patch #73 on views 3.8 finally got it working. I'm not sure if this patch is just for the Reference Option Limit module or for other things as well, but I want to stress the importance of good documentation. It took me a week to figure out how to use this module, and mostly by reading and re-reading error issues. Without proper documentation a lot of time and energy is wasted, please document well! For this particular patch, it took me a while to realize how views AJAX exposed forms would work. Hitting apply worked, but I didn't realize you have to set EXPOSED FORM, Exposed form style: | Settings: check Autosubmit and Hide Submit button. That may be basic knowledge to some, but not everyone knows this. My problem was also with another bad jQuery add on with the site I was working on that transforms select boxes to div wrapped a href dropdowns, but that's another story, and i'd pull that code if I had the choice. So yes, the patch works, and please please document well. And be well.
Comment #85
dieuwePatch #73 works perfectly with 3.8, no changes required.
Comment #86
pmkanse CreditAttribution: pmkanse commentedPatch #73 tested with views 7.x-3.8 and it works great \m/\m/.
Comment #87
c.dan CreditAttribution: c.dan commentedPatch #73 tested and works on views 7.x-3.10.
Comment #88
TuWebO CreditAttribution: TuWebO commentedHi,
Patch #73 is working fine for me too on views 7.x-3.8, just as is, I didn't need to change the weight (as #80 mentioned).
My use case:
I have a view with 3 exposed filters as text fields, and also have the view with the settings "Exposed form in block" to "Yes" and "Use Ajax" set to "No".
I'm able to hook into "MYMODULE_form_views_exposed_form_alter", change those fields to select list and make them dependant one on each other with no problem, before this patch the ajax didn't work. That's the test that I made.
I can also confirm that (in my case) the plugin geofieldProximityExposedFilter from the geofield module, throws an error when aplying this patch, I will try to find the problem and post an issue for this.
Thanks for this great patch to everyone involved on it.
Comment #89
baikhoPatch #73 also works for Views 7.x-3.10 Thanks!
Comment #90
Drupaltarzen CreditAttribution: Drupaltarzen commentedI dont know any coding , I need this functionality, what should i do ..
1) Where should this patch be placed.
2) I need the exposed filter to search/filter on 4 fields
3) Any modules other then view's ? needs to be installed here ?,
Please guide.
Thanks
Comment #91
Vj CreditAttribution: Vj commented@Drupaltarzen
Save patch in your views module folder. Then run
git apply -v views-exposed_forms_ajax_support-1183418-73.patch
If patch applied successfully then you should get it working.
Comment #92
Drupaltarzen CreditAttribution: Drupaltarzen commentedthanks
Comment #94
sgurlt CreditAttribution: sgurlt commentedI had a little problem applying the patch, the file "exposed-form-ajax.js" did not get created in "/www/sites/all/modules/contrib/views/js", instead of this is got created next to my root folder "www",
After moving the file to the correct destination the ajax problem is solved.
Comment #95
colanAs this is a fairly big patch, I'd like to wait for #2450447: Drupal QA is broken for Views 7.x-3.x before committing.
Comment #96
donquixote CreditAttribution: donquixote as a volunteer commentedIt does not work for me so far with #73 based on 7.x-3.8 or more recent versions of views.
Trying to have conditional elements in a custom views field handler.
I still get "Invalid form POST data for form-...", and the AJAX response is empty.
The AJAX request has the correct form_build_id that is also found in the form html (of the field handler configuration form, not the overall views config form). But then ajax_get_form() / form_get_cache() don't find the form in the cache.
Looking into the cache_form table, the respective form_build_id is indeed not in there.
I might add more information if I have done further debugging and created a reduced example, but for now this is all I can say.
Comment #97
bessone CreditAttribution: bessone commentedI have the same problem of @donquixote with Views 7.x-3.11 and Drupal 7.39
Comment #98
donquixote CreditAttribution: donquixote as a volunteer commentedThere are some revealing comments in views_ui.module.
Comment #99
donquixote CreditAttribution: donquixote as a volunteer commentedJust to mention it, in my case, I would like to implement the AJAX logic for a reusable form element, not for a specific form..
Comment #100
donquixote CreditAttribution: donquixote as a volunteer commentedIt seems that setting
['#ajax']['path'] = $_GET['q']
is sufficient, at least for field handler config forms.Comment #101
bessone CreditAttribution: bessone commentedMy problem is related to changes to the Ajax System introduced in Drupal 7.39 (https://www.drupal.org/drupal-7.39-release-notes), reverting back to 7.38 everything works again.
Calling ajax_set_verification_header() in the Ajax callback function didn't solve the problem.
Comment #102
kjl CreditAttribution: kjl commentedThe patch in #73 appears to have a bug in it which was revealed by the stricter form token validation in Drupal 7.39.
Should probably be:
Comment #103
joelpittet@kjl could you explain why it should be that? (Not totally familiar with the token system)
Comment #104
kjl CreditAttribution: kjl commenteddrupal_valid_token() compares form_state['values']['form_token'] (the actual token) with a hash of $form['#token'] (which is usually the form_id, not an actual token).
$form_info['form_token'] = $form['#token'];
in the patch was causing the hash of $form['#token'] to be compared to $form['#token'] itself, rather than to the token, when those values were passed to drupal_valid_token.
Comment #105
joelpittetThanks for the clarification. Setting to Needs Work with that in mind.
Comment #106
barraponto CreditAttribution: barraponto commentedok, re-rolled.
Comment #107
joelpittetOk since #104 was included in the re-roll in #106 I think this is fair to go back to RTBC.
Comment #108
jdesrig CreditAttribution: jdesrig commentedI can confirm that patch #106 worked for me, while #73 did not. However, I am still having an issue:
I am using a country field select list to update the state field field select list. The first AJAX call works correctly and the form is rebuit, however subsequent calls do not. I have been doing some debugging and I do see that the form function is being hit again, but the State select list remains unchanged. Is this issue related to the above fix?
Comment #109
colanTrying to fire up the testbot now that #2450447: Drupal QA is broken for Views 7.x-3.x is in.
Comment #110
colanComment #111
colanComment #112
colanSorry about the interruption. Can't test this yet as the branch is failing. Carry on.
Comment #113
zuernBernhard CreditAttribution: zuernBernhard at UEBERBIT GmbH commentedpatch #106 does not work here with Views 7.3 dev I have a View in a Panel Pane and the views exposed form outside the view-div in the panel pane template. ajax works fine (views result is replaced in the markup according to the exposed filter) but the form is not rebuild after the ajax callback (select for the exposed filter stays disabled).
Comment #114
colanWe've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.
If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.
We apologize for the trouble, and appreciate your patience.
Comment #115
colanComment #116
joelpittetRe-uploading previously RTBC'd patch from #106 for testing.
Comment #117
colanCan someone speak to the issues raised in #108 & #113? If valid, we need to account for them.
Comment #118
joelpittet@jdesrig @zuernBernhard could you provide more details so we can try to reproduce your issues? I've not run into this issue myself so far.
Comment #119
jncrucesI've created a module with the code of the patch #116, for use it in any case. I not publish the module because i think the patch will be applied to the original views module but this module can be used with previous version if for some reason can't be updated views.
With the patch the form become outdated i correct it with a $form['#token']=NULL;
Thanks for the patch.
Comment #120
mukesh4only CreditAttribution: mukesh4only commentedThank you @jncruces
Comment #121
Liam MorlandUniversity of Waterloo has successfully been using the patch in #106 since January.
Comment #122
kumkum29 CreditAttribution: kumkum29 commentedHello,
the views module is an important module of an site in production. For me this is a bad thing to patch directly this module.
So, I use the mini-module of #119.
Do you think include this feature / patch in the next version of views (stable or dev)?
Thanks for your replies.
Comment #123
riddhi.addweb CreditAttribution: riddhi.addweb at AddWeb Solution Pvt. Ltd. commentedComment #124
pcambraJust mentioning that patch in #116 solves the issue for me, exposed filter in search api with no panels.
Comment #125
joelpittetAsked for feedback from #118 10 months ago and no feedback so setting the status again.
Comment #126
dwwI ran into the same problems in D8 Views trying to get #ajax working in an exposed views filter form for Address module. See #2787255: Provide a views filter for administrative areas for more. So I started porting patch #106 to D8. However, for reasons I can't explain,
$form_state->getTriggeringElement()
is returning the submit button, not the form element with #ajax attached. But I wanted to attach this as a start towards fixing this in D8 core. Not sure the right issue workflow for getting a Views bug like this fixed in both core (D8) and contrib (D7).Comment #127
dwwI heard from dawehner in IRC that he thought a separate issue for fixing this in core for D8 views was a good idea. So I just opened #2842525: Ajax attached to Views exposed filter form does not trigger callbacks for solving this in D8 core and I'm marking that the parent issue to this one for D7 contrib.
Comment #128
DamienMcKennaRerunning the tests..
Comment #129
DamienMcKennaMinor comment adjustments. The JS is also tweaked to 'use strict' and use === instead of ==, can someone please test this again? Thanks.
Comment #130
joelpittetOther than a couple whitespace changes I spotted, this looks still RTBC and fixed the issue I was having.
Comment #131
GuillaumeDuveauHello,
I didn't review the code, but I find, too, that the patch from #129 solves the issue.
Comment #132
dillix CreditAttribution: dillix commented+1 for RTBC, #129 solved my issue.
Comment #133
Chris CharltonThat's a few RTBC yeses. :)
Comment #134
wdseelig CreditAttribution: wdseelig commentedApplied the patches in 129 to Views 7.x-3.16, but Ajax still not working from exposed filters.
Not sure if these two patches alone were supposed to fix things, or whether I was supposed to apply some (all?) of the patches in the other files attached to comment 129 [Some of which failed testing?]
Took a look at views 7.x-3.17, and saw that it does not include the js file exposed-form-ajax.js, so I think I can assume that 7.x-3.17 does not include these fixes?
To be clearer about the nature of the failure: I AM getting to my ajax callback routine when I click on an element in the exposed filter. However, I am, at that point, unable to execute any ajax commands. The test code in my callback routine is as follows:
drupal_add_js('misc/ajax.js');
$commands[] = ajax_command_alert('Made it into the setindividualtags routine');
$page = array('#type' => 'ajax', '#commands' => $commands);
ajax_deliver($page);
This code works just fine in other places, but not here. Instead, I get an AJAX HTTP error with a result code of 200.
Observation: I notice in the debugging information that I get back that the Path is /system/ajax, and am wondering if I'm somehow not finding the exposed-form-ajax.js file? I have put it in both my views folder and in the views/js folder, but to no avail.
Wyckham
Comment #135
wdseelig CreditAttribution: wdseelig commentedHere is the debugging information I get when I try to execute the code above:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /system/ajax
StatusText: OK
ResponseText: [{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"marinelli","theme_token":"bqgihR823xfRojqu6ZaiKNwnGWa2Mxzukr5YtPWe2YE"},"ViewsExposedFormInfo":{"field_contacttags_tid":{"form_id":"views_exposed_form","form_build_id":"form-NxLHIUooCC78UgSuIDQEAGpkLlafqKOtcOGtJ4hI3Jo"}}},"merge":true},{"command":"alert","text":"Made it into the setindividualtags routine"}][{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"marinelli","theme_token":"bqgihR823xfRojqu6ZaiKNwnGWa2Mxzukr5YtPWe2YE"},"ViewsExposedFormInfo":{"field_contacttags_tid":{"form_id":"views_exposed_form","form_build_id":"form-NxLHIUooCC78UgSuIDQEAGpkLlafqKOtcOGtJ4hI3Jo"}}},"merge":true},{"command":"updateBuildId","old":"form-anRx-WxdIasT3TToKWVZYYwLQTBqPMybjh5aRIUmstM","new":"form-NxLHIUooCC78UgSuIDQEAGpkLlafqKOtcOGtJ4hI3Jo"}]
Comment #136
wdseelig CreditAttribution: wdseelig commentedI am using Firefox developer edition to investigate this error further, and can now report the following.
When I click on an element of an exposed form, my site is, for some reason issuing the following
XMLHttpRequest (XHR):
http://(my_domain)/system/ajax
I have no idea why this is happening. When I compare this non-working code with code that successfully utilizes ajax, I see that the successfully working code issues an XHR that looks like this:
https://(mydomain)/mycallbackroutine.
In the code that works, I create a link to a menu item that goes to an ajax callback routine. In this code, I am not as free to format the item in the exposed filter, so I think I'm relying on the patched views module to do it for me.
Comment #137
wdseelig CreditAttribution: wdseelig commentedI am embarrassed to have posted #134 to #136, and if I could delete them I would. I had somehow missed the need [described in Ajax forms in Drupal] to "change #ajax['path'] from the default 'system/ajax' and set up a menu entry in hook_menu to point to your replacement path." Once I did this I found that I could execute the code described in #134 just fine.
Comment #138
dflitner CreditAttribution: dflitner commentedI also am trying to implement http://bouteillenicolas.com/expertise-drupal/views-ajax-dynamic-dependen... and was getting "Invalid form POST data" and "Notice: Undefined index: form_build_id in ajax_get_form()" errors in the log. The patch in #129 fixed it for me and ajax now works as desired in my exposed filter.
Views 7.x-3.18.
Comment #139
tuchoThe patch at #129 works for me too.
I have written an drupal_form_alter to attach the AJAX hook and I have tested it with Drupal 7.56 and Views 3.18.
Comment #140
omnia.ibrahim CreditAttribution: omnia.ibrahim commentedPatch for views version views-7.x-3.20
Comment #141
Rajeev H CreditAttribution: Rajeev H as a volunteer commentedThe patch views-n1183418-128.patch works fine.
Comment #142
pbirk CreditAttribution: pbirk commentedConfirming patch views-n1183418-128.patch works against Views 7.x-3.20.
I verified after a fresh download of Views 7.x-3.20 my callback did not fire after modifying the select field it was attached to. Applied patch and the callback fired as expected.
Thanks @DamienMcKenna!
Comment #143
sano CreditAttribution: sano commentedPatch #140 works for me as well. Views 7.x-3.20. Thank you all.
Comment #144
pbirk CreditAttribution: pbirk commentedTested #129 no longer works for my site against the latest development branch. I haven't attempted to troubleshoot that yet and likely won't manage to this week.
Comment #145
DamienMcKennaReroll and I've tidied up some of the comments & formatting.
Comment #146
DamienMcKennaUse struct on the JS, which necessitated changing the comparison statement to an equality operator. Can someone please test it? Thanks.
Comment #148
DamienMcKennaComment #149
sano CreditAttribution: sano as a volunteer commentedI installed a fresh copy of views 7.x-3.20 and run my app. Saw JS error whenever trying to set a checkbox value in my ajax-interconnected exposed filters. Corresponding log entry:
After applying the patch my exposed filter works and I have no entries in the log. Thank you.
Comment #150
pbirk CreditAttribution: pbirk commentedFinally dug into this more and found my site broke due an unrelated Views patch that I missed installing after updating. Turns out my site works after updating to Views 7.x-3.20+29-dev both with and without the patch from #146. While I can't confirm the patch fixed anything, I can confirm nothing new appears broken on my site.
Comment #151
sano CreditAttribution: sano as a volunteer commentedjust updated views to v. 7.x-3.21 and the patch is still necessary & applies cleanly.
Comment #152
pbirk CreditAttribution: pbirk commentedI just upgraded my site to 7.x-3.22 and found I was able to reproduce errors related to this again. The patch from #146 installed cleanly and resolved the errors.
I also decided to test this against 7.x-3.22+51-dev and found the patch applied, but not perfectly cleanly. It created a views.module.orig file. I'm attaching an updated patch against that branch. I don't think anything changed but the line number references.
Comment #153
DamienMcKenna@pbirk: thanks for the reroll.
This needs a tiny improvement with the comments, e.g. this comment is unfinished:
Comment #154
Liam MorlandRe-roll with comments updated and array type declarations added.
Comment #155
pbirk CreditAttribution: pbirk commentedMarking RTBC. Tested patch in #154 against views-3.x-dev. Comments appear complete now.
Comment #157
DamienMcKennaCommitted. Thanks everyone!