Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
An attachment display should be able to (optionally) inherit the exposed filter settings from the display on which the attachment is attached to. This should work similarly to how it's possible to specify that an attachment will inherit the arguments. It would also be best for this to behave similarly to how attachments work in that the filter settings of the parent display would always be copied to something like original_exposed_filter_data.
Comment | File | Size | Author |
---|---|---|---|
#4 | 273570_views_exposed_filters_4.patch | 4.5 KB | aclight |
Comments
Comment #1
aclight CreditAttribution: aclight commentedI took a look at this but got stuck. I modified the beginning of the attach_to() function of views_plugin_display_attachment to look like so:
When I created a simple view (below) and went to the page, and then set a filter and hit the apply button, both of these dsm() calls print out an empty array.
Comment #2
aclight CreditAttribution: aclight commentedI think the problem here is that attach_to() (line 2541 of plugins.inc) is called before views_exposed_form_submit() is called (line 875 of views.module), which puts the selected values into $view->exposed_data.
Comment #3
aclight CreditAttribution: aclight commentedFrom chatting in IRC, I'm told that I need to modify the attachment's "uses_exposed" setting in views_plugin_display_attachment::uses_exposed() to respect the new flag that I'll add.
Comment #4
aclight CreditAttribution: aclight commentedHere's a patch that implements what we discussed in IRC. I tested locally and it seems to work well and gives me the desired results.
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedGreat work! THanks!
Comment #6
aclight CreditAttribution: aclight commentedI've noticed now that if I have two views that are identical in every way except for one view the attachment display is set to inherit exposed filters and on the other view exposed filters are not inherited, when running the view that *does* inherit the exposed filters, I get some warnings and the view isn't built correctly.
The notices are:
I tried to figure out what's going on here but couldn't follow what was going on completely.
The problem seems to be in views_many_to_one_helper::ensure_my_table() on line 511:
The first time this line is executed, $this->handler->value = array(0 => 42). However, the second time the same line is executed, $this->handler->value = 42. So in other words, in the first case it's an array, in the second case it's a string. However, I couldn't figure out how this is getting set to be a string on the second run through.
I'll be around most of today, so if you need me to put this latest code on my dev site and add some dsm() for debugging ping me in IRC.
The view I'm getting this problem with is the very complicated one with the project_release relationship, etc. so just pasting the exported view here might not be much good, though I can do that as well if you wish.
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedHmm. The processing in accept_exposed_input is supposed to make that into an array. It's interesting that it doesn't happen on the attachment. I'm not sure why that might be, since they're both getting the input well before the form is actually processed. Will see if I can figure this out.
Comment #8
aclight CreditAttribution: aclight commentedOk, so in the case where I'm inheriting filters (and getting the warnings), views_handler_filter_term_node_tid::exposed_validate() gets executed only once, however views_handler_filter_term_node_tid::accept_exposed_input() is executed twice. The first time, $this->validated_exposed_input has a value (an array) and therefore is used to pupulate $this->value. The second time around, $this->validated_exposed_input is not set, and therefore $this->value isn't changed and remains the same value that views_handler_filter::accept_exposed_input() puts into it, which is a string and not an array.
Hopefully this info helps a bit.
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedHuh! Thanks, that is helpful.
Comment #10
merlinofchaos CreditAttribution: merlinofchaos commentedThis turned out to be an issue with FAPI that prevented multiple validate calls on the same form. I added an override and moved the function into views version of form.inc. Not ideal but there's LOTS of fodder in here for inclusion into Drupal core. =)
Comment #11
KarenS CreditAttribution: KarenS commentedTheres a core issue about this at http://drupal.org/node/260934. I posted a reference to this issue there.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commented#180063: No way to flush form errors during iterative programatic form submission is now RTBC. I marked Karen's as a dupe.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.