Exposed filters submit erroneously appends filter value to paths

Views automatially appends arguments (contextual filters) to the path. I believe there is a checkbox in the contextual filter to disable that behavior. You'll want ot use that.

Hit this bug. A bit of investigations - if View inserted into context then $view->override_path is empty

Suppose "override_path" should be set for context'ed view before views_content_context_get_output() is executed, but I still not found a right place to patch

This is a hack but it works

To test this
1) add a view with exposed form into panel's context
2) add exposed form to panel
3) try to submit form

without patch you will be redirected to site's frontpage

@mh You mean exposed form from Paged view, but I'm talking about context-view - neither context nor exposed form has 'Use panel path' checkbox

Steps to reproduce:
1) create a view with ONLY context display & exposed filters
2) drop this context into panel
3) drop rows and exposed form into panes
4) try to use exposed filter

I found 'Use panel path' in the Context settings and everything works fine

That is not a CTools problem, that is a problem in Views.

#11 clearly states this is a bug in Views. #10 describes the issue. I've attached an export of my view and an export of my page. The exposed filter block is added via block.module. My exact steps to reproduce.

1. Import the view and page attached.
2. Show the exposed filter block on the path volunteering/vacancies
3. Visit the path volunteering/vacancies
4. Submit the exposed filters
5. You are now at volunteering/vacancies/volunteering?keys= ....

My page manager page is already supplying the argument to views, why is views adding it again?

I could of course rearrange my URLs so they read vacancies/volunteering and vacancies/employment but semantically this makes less sense for my particular site, because the site has an entire section about employment (with path "employment") and an entire section about volunteering (with path "volunteering") but does not have a section about vacancies, that is a subsection of the above two.

The bug still exists....

Another workaround is to activate AJAX. Then it works too..

I don't think this is limited to page manager displays. Anything that embeds a view into an existing path may have the same behavior.

I'm using the view_reference module to embed a view that has an exposed filter into a node - views will append the current filter argument to the node path when submitting a new filter value, ie:

node/345/current-filter-value?filter=new_value

This still displays the node and view, but if you have blocks etc that depend on the path you'll need to allow for the extra argument to the path in the block setup, which may become hard to handle.

I haven't tested with EVA but I suspect this may be an issue there as well.

I'm reopening this because contextual filters are not involved (my view uses none). Changing title to reflect the more general case.

Workaround I'm going with is something like this:

function mymodule_form_views_exposed_form_alter(&$form, &$form_state) {
  switch ($form['#id']) {
    case 'views-exposed-form-viewname-displayname':
      // Workaround for #1269794.
      // Whatever you need to make it behave, but remove the added filter argument.
      $form['#action'] = 'my-path';
      break;
  }
}

It is this line as #16 that causes 'problems'.

<?php
$form['#action'] = url($view->display_handler->get_url());
?>

The problem

Views try to find it's own path. Since the views it not the one that make the page with URL rather it is made by page manager. get_url() return an empty string. url() function resolve this to '/' causing the submit button action to be '/' something that normally is your front page.

The fix

To get around this do you have to change/add a 'content page' and let page manager pull this in. The trick is a small setting in 'content pane' pane settings 'Use panel path'.

That's not much use if you aren't using panels.

Eh.. no but that was not the point either. Do you care to share your setup?

Just views, and hook_form_alter as per #16. How you manipulate the #action variable there will depend on what the path looks like, but I use substr() or preg_replace(). It's a hack, not a generic solution.

OK, but I was thinking more along, how and where do you use this view? since views have trouble getting the url. Is it a Views page, a block used by core blocks, view attached to a node and so on?

Mine is a block used by core blocks, grabbing its contextual filter values (nid) with a line of php. I have not yet experimented with EVA to see if attaching the view to the node that way produces the same problem.

Thanks, John Pitcairn. #16 worked well for me (with contextual filters). Just wrapped the path in url() and all good to go.

.. snip ..
      $form['#action'] = url('my-path');

same problem here:

* view as context (use panel path: yes) and the view has an argument (provided through the panel)
* panel with the exposed filters and the view rows

on every submit over the exposed filters the argument is added again to the url, resulting in a panel_path/argument/argument/argument/argument/... path.

(d7 with the latest versions of views, ctools and panels)

A slight variation on #16 is:

      $form['#action'] = url(current_path());

Avoids hard coding the view URL into your alter.

Is D8 affected by this? so maybe better to move the issue to core?

I just ran into this problem using eva. I have a view with an exposed filter that gets attached to an entity of type organization. The path of the entity is redhen/org/12345. Each time I submit the form on the exposed filter, I get 12345 appended to the end of the url. Worked around it with the hook_form_alter suggestions from #16 and #25.

I think this effects more then just the exposed filter forms.

Some other examples of where this happens:

• more link
• in the form action for other views handlers that implement views_form() (example: draggableviews)
• glossary filter links

I think these issues could all be summarized as: Views Contextual Arguments are appended to various paths of Panel Pane displays when "Use Panel Path" is set to "Yes".

See also:
#1284738: Wrong form action URL for exposed filters of content pane view displays using contextual filters
#1449248: When using "Override path" and an argument with "input on pane config", the argument is appended to the overridden path
#2213005: Argument repeatedly appended to URL on glossary views content panes

I'm attaching a patch that I think fixes this without requiring custom form_alters().

Patch is for ctools, moving to that issue queue.

Wrong project...

@steinmb, thanks for #17