exposed blocks path incorrect when using bef_links + contextual filters or Content Pane displays

Fabulous!!! Thanks for the patch Jim. Saved me from having to figure it out. This should certainly be implemented in the module.

BEF also throws an error about a missing path when exposed in a Views Content Pane used in a Panel. This patch fixes that, since $form['#action'] is available there also.

Can confirm that it is working on my side.

This patch should be modified. Think of multilanguage site with language prefix.
E.g. $form[$field_id]['#bef_path'] for 'bef_links' should use current_path();

Setting status to NW, based on #6.

Have modified this patch, so it also contains the fix from patch https://www.drupal.org/files/issues/bef-pager_index_not_reset-1924822-3....

It is a patch that corrects errors on the page index, which does not reset the index when you click on a link generated through better exposed filter.

My current project is dependent on both patches, but I think that https://www.drupal.org/files/issues/bef-pager_index_not_reset-1924822-3.... should be included in the project right away, because I can not clearly see any use case where it is not desired for the page index to be reset, when a link is clicked.

The patch in #8 helped resolve my issue with contextual filters in use, but
1. I couldn't get it to apply to the latest checkout of dev
2. The 'bef_links' case has a condition that is now erroneous I think:

if (!empty($this->display->display_options['exposed_block']) && isset($this->display->display_options['path'])) {
  $form[$field_id]['#bef_path'] = $form['#action'];
}

I re-rolled the patch against the latest dev and removed the condition checking for $this->display->display_options['path'].

A little note: when I'm using this in combination with the contrib module "Views Block Exposed Filter Block" (allows block displays to put exposed form in blocks which is not normally allowed), $form['#action'] always seems to be '/' regardless of the page I'm on. So for me, setting #bef_path to current_path() covers all bases.

I'm not sure if this would work out for all other use cases though, even though I can only think of cases where I want the filter to affect the page I'm on and not go somewhere else. Using current_path() would probably get funky in ajax requests that load the view...but I haven't pondered this too deeply. Unfortunately I don't have enough time to help find a perfect solution, but this will do for me for now.

I re-rolled the patch against the latest 7.x-3.x-dev.

Seems like a lot of unrelated changes in #11 (whitespace changes, etc.) which makes it harder to review. Can you post a patch with only only the changes related to this issue?

(Coding standards patches are always welcome, btw!)

i have added patch to version module 7.x-3.0

#13 works fine for me, thanks to you all. This is the exact same patch rolled against 7.x.3.x-dev

Here is the patch... sorry

Strange -- when I apply #15, I get a corrupt patch error:

$ curl https://www.drupal.org/files/issues/better_exposed_filters-fix_exposed_block_link_path-2179169-14_1.patch | git apply -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2897  100  2897    0     0   7428      0 --:--:-- --:--:-- --:--:--  7428
fatal: corrupt patch at line 53

Haven't had time to look into this more closely.

@mikeker @pamatt forgot to use --relative when making the patch. Quick fix, open the patch and replace : sites/all/modules/contrib/better_exposed_filters/ with nothing.

Same patch as #15, rolled against the latest 7.x.3.x-dev version and (hopefully) with corruption problems solved.

@joelpittet, @pamatt: Thanks for the updated patch. However, this patch will give the wrong URL if the exposed filter block is placed on a page that is not the view result.

For example:

• Expose filters on a page using the Link render option
• Set Expose form as block to Yes
• Place the block in the sidebar (or wherever) for all pages
• Navigate to a random node

The paths for the links in the exposed filter block will be similar to node/368?field_tags_tid=7 instead of path_to_page_display?field_tags_tid=7.

Here is a new proposed patch, with a slightly different approach. The view's URL and arguments are read directly from the view object and attached to the links. I am using it now for a project I'm working on and it seems to work fine, so far.

Nice fix, thanks all for the hard work on this issue! The latest patch works in my testing as well: exposed filters on landing page, results page separate. All aliased appropriately :)

Thank you to everyone that worked on this issue! And my apologies for the delay in reviewing it...

A modified version of #21 has been committed to the 7.x-3.x branch (couple more cases of #bef_path and trailing whitespace removed). Tagging so it is not left behind in the D8 port.