The form element is output with the wrong URL when blocks have exposed filters.

This is because the block display handler relies on the base handler returning a relevant URL. Given blocks don't have a path, this bug must have been around for a long time.

The proposed solution (see patch in comment #3) is to set the url/path to the current page's alias for blocks.

This bug has a lot of symptoms, including the one originally reported:
---------------
Hi,

There seems to be a bug with block displays of views that contain exposed filters. I typically do some testing for browsers without Javascript to check how search engines would crawl the site and noticed this behavior.

The expected behavior would be that the view appends the variables to the URL if javascript is not enabled. For page displays everything works fine, however block displays break and visitors always end up on the homepage (see 3) as the path to the page on which the block is placed (1) does not get added to the URL.

Example:
1) Random URl with view and exposed filters: www.example.com/path/to/view
2) URL if display is "page" and javascript disabled: www.example.com/path/to/view?var1=val1&var=val2
3) URL if display is "block" and javascript is disabled: www.example.com/?var1=val1&var=val2

In other words, a visitor with a browser without javascript support visits page (1), selects items in the exposed filters, hits submit and either ends up on (2) if the display is page (works fine as expected) or (3) if the display is block (not as expected = bug).

Any idea how to fix this? I assume views would need to check on which page the block is placed and form the URL pattern accordingly.

Cheers, J.
---------------

CommentFileSizeAuthor
#15 views-blocks_exposed_filters_have_wrong_url_in-1069966-15.patch603 bytesandrew answer
#3 views-wrong_url-1069966-3.patch601 bytesjonathan.dh

Comments

jkingsnorth’s picture

jkingsnorth commented
Version: 6.x-2.12 » 7.x-3.0-rc1

Updating to most recent version because this is still an issue.

It is occurring because the
tag has the action attribute set to '/'. This is because the block doesn't know what path it is going to be placed on, or could be placed on several different pages.

So as jelo suggests, perhaps ajax enabled blocks should have their form action set to the current page's path. That way they won't redirect people off to the front page if javascript is enabled.

jkingsnorth’s picture

jkingsnorth commented

I was able to fix this using this approach, which sets the form 'action' to be the current page.

Why isn't this the default behaviour for all exposed forms on the 'block' display? Surely the action in this case should always be the current page?

Whereas I can see that if a page's exposed filters were placed in a block there is the use-case for having them post to a different page. (ie: filter in a block on the homepage that redirects the visitor to a listing page with the filter applied).

jonathan.dh’s picture

jonathan.dh commented
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new views-wrong_url-1069966-3.patch601 bytes

Submitting patch that fixes the url generated by views' block display handler.

Status: Needs review » Needs work

The last submitted patch, 3: views-wrong_url-1069966-3.patch, failed testing.

jonathan.dh’s picture

jonathan.dh commented
Title: Block display with ajax and exposed filters does not work with Javascript disabled (wrong URL) » Blocks exposed filters have wrong url in form action
Issue summary: View changes
jonathan.dh’s picture

jonathan.dh commented
Version: 7.x-3.0-rc1 » 7.x-3.x-dev

Status: Needs work » Needs review

jonathan.dh queued 3: views-wrong_url-1069966-3.patch for re-testing.

jonathan.dh’s picture

jonathan.dh commented
Version: 7.x-3.x-dev » 7.x-3.8
damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Version: 7.x-3.8 » 7.x-3.x-dev
RAWDESK’s picture

RAWDESK commented

Hi,
Thanks to your patch i partially solved this issue i had with Exposed filter, build via views_autocomplete_filters module :
http://megadrupal.com/comment/7318#comment-7318

I said partially, because if the URL already has existing query parameters (in my case ?currency=USD) the exposed autocomplete filter is not applied.
Symptom can be witnessed here : http://couture1.artstanding.be/product-grid-sidebar
After switching currency to USD, the malfunctioning occurs.
Also note that all other exposed filters (sorting,...) do append their querystring to the existing ?currency=USD.

Please advise how to solve this remaining issue.
Can it be done by executing drupal_get_query_parameters() inside this patched function get_path() and append the parameters somehow ?
Thanks

UPDATE: Also issued here at Views Autocomplete Filters : https://www.drupal.org/node/2622964

betz’s picture

betz commented

I can confirm this patch is working.

@rawdesk, I can't confirm your issue with urls having query parameters before applying a exposed filter. It works perfect here.

betz’s picture

betz commented
Status: Needs review » Needs work
betz’s picture

betz commented
Status: Needs work » Needs review

queueing testbot

chris matthews’s picture

chris matthews commented
Status: Needs review » Needs work
Issue tags: +Needs reroll

The 4 year old patch in #3 to views_plugin_display_block.inc does not
apply to the latest views 7.x-3.x-dev and if still relevant needs to be rerolled.

Checking patch plugins/views_plugin_display_block.inc...
error: while searching for:
        ->execute();
    }
  }
}

error: patch failed: plugins/views_plugin_display_block.inc:240
error: plugins/views_plugin_display_block.inc: patch does not apply
andrew answer’s picture

andrew answer commented
Status: Needs work » Needs review
Issue tags: -Needs reroll
StatusFileSize
new views-blocks_exposed_filters_have_wrong_url_in-1069966-15.patch603 bytes

Patch rerolled.

redbrickone’s picture

redbrickone commented
Version: 7.x-3.x-dev » 8.x-3.x-dev
Component: exposed filters » Code
Status: Needs review » Needs work

Is there any update on this? I am encountering this in Drupal 9 Views still.
I have a block view display and a page view display in the same view. Exposed form is on the block view. It sends the user to my page view every time.
If I remove the page view display from this view it works as expected.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Version: 8.x-3.x-dev » 7.x-3.x-dev
Component: Code » exposed filters
Status: Needs work » Needs review

In the Drupal 8+ world Views is in core, so please search the Drupal core issue queue for this problem.