I'm not sure if this is a Panels or Views issue, but seeing as how the block works as desired *outside* of a panel... I've got a view defined with a page display, and have exposed the filters as a block. I've tested the block in a generic sidebar region of a page, and when submitted it redirects to the view's display path as expected (in this case properties/leasing/search).

The problem is occurring when I embed the filter block as content within a panel (panel path defined as leasing). When I submit the exposed filter form, instead of redirecting to properties/leasing/search the panel page at leasing is loaded with the filter query string attached (i.e. leasing?prop_type[]=office&state=All).

I have tried implementing hook_form_alter in a custom module to explicitly set the $form['#action'] setting to properties/leasing/search for the form in question per a suggestion in #669444: Exposed View in MiniPanel, won't redirect., which is having no effect in this case.

Am I missing something, or is this something that Panels just simply doesn't support?

Thanks!

Comments

merlinofchaos’s picture

merlinofchaos commented

Are you using the node add or node edit contexts in this panel?

arpieb’s picture

arpieb commented

Nope, I'm not using anything contextual or related to node editing. I was basically using Panels to define a convoluted multi-panel page for a client. I had embedded the exposed views filter block in one of the panes hoping that when the filter criteria were selected and the "Apply" button was clicked, it would jump to the view page display with filtering applied. Instead, it consistently reloads the panel page that the block is placed in.

I wound up just building a page template instead of using Panels and embedding the filter block that way. Unfortunately I'm too much under the gun to try and troubleshoot it at this point and had to go with what I know works right now... It probably still needs to be addressed as the panel probably shouldn't be overriding the exposed view filter block's destination.

merlinofchaos’s picture

merlinofchaos commented

Well, teh thing is, Panels isn't overriding this, so I don't have a good explanation for why it's happening.

arpieb’s picture

arpieb commented
Assigned: Unassigned » arpieb

Well, once I have some breathing room after this week, I'll dig back into it and trace through the Panels and Views code to see if I can figure out what is going on. I can't imagine that nobody else has run into this before, so was hoping that there were some pointers out there of what to look for...

If you don't mind keeping this open and assigned to me, I'll dig into it on my end and document it here so there is a trail for some future Drupalier that might run into the same thing...

Who knows - I might even come up with a patch... ;)

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Postponed (maintainer needs more info)

Marking NMI based on #4. Maybe an export might help me see what's going on, though I think it's unlikely to show me much. :/

mysterlune’s picture

mysterlune commented

subscribing

mysterlune’s picture

mysterlune commented
Issue tags: +Panel Pages, +views exposed filters, +views blocks

Hi there,

I stumbled upon a similar problem recently, and have at last (I believe) gotten to the bottom of it. #906916: use_ajax setting gets lost when exposed filter form is added as a block inside of a panel involves the loss of AJAX form submission when a Views Exposed Filters form is added as a block-within-a-panel via Page Manager. The ultimate problem, as I believe I've found, doesn't have so much to do with Panels or Contexts.

The matter seems to do with a condition in views/includes/view.inc where a (possibly) deprecated view::ajax property is getting evaluated, and a boolean gets handed off to the $form_state variable. It's always FALSE because there is no view::ajax property. At the end of the day, views_exposed_form() will not include the jquery.form.js file unless view::use_ajax is TRUE. So unless some other module happens to be including it by happenstance, the AJAX form submission cannot take place.

It seems that looking to the view::display_handler->get_option('use_ajax') value is the proper check at that point. I've submitted a patch for testing to the issue indicated above.

@arpieb I'm not sure if this patch would address your issue, but could be worth checking whether that jquery.form.js file is getting included for your exposed filter block.

@merlinofchaos I noticed there is an "ajax" index on the $form_state array that gets used variously throughout views/includes/admin.inc, sometimes a string or boolean, so I'm not entirely sure whether the fix I suggested in #906916: use_ajax setting gets lost when exposed filter form is added as a block inside of a panel would interfere with the admin stuff... I'd like to hear whether you have thoughts on this, so would you mind posting them to that issue if you do?

Cheers,
--mysterlune

coderintherye’s picture

coderintherye commented

@mysterlune Thank you very much, this is the first result I found when searching on this issue and is exactly the issue I was experiencing.

totocol’s picture

totocol commented

Subscribing

Letharion’s picture

Letharion commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Because the issue queue has a great number of open issues, and there are few volunteers to tend them, I must prune old issues that are left untouched for a long time.
This issue has been marked "Postponed, needs info" for a long period, and is therefore closed. If this issue is still relevant to you, please feel free to re-open it.

josepvalls’s picture

josepvalls commented

Just for the record; we encountered the exact same problem and we solved it using hook__form_alter and setting the $form['#action'] to the URL where the desired view's page resides.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Subscribing. Same problem here with the latest versions.