Problem/Motivation

The remember feature of exposed filters is not working on some cases because it is not storing values under some circumstances (for example when selecting a non-restrictive option option such as "All").

This behaviour is hidden by the fact the usually the default value for a filter that exposes the "All" option is going to be "All".

To replicate:

1. Setup a view for nodes, and create an exposed filter for the Published field (status) with the following settings: not required, remembered by the authenticated role, default value "NO".

2. Save the view and go to the view's page, the default selected option is "No".

3. Change this to "All" and apply the filter to the view.

3. Refresh the page, the value is not rememberd and back to "NO" which is the default.

The culprit of the issue seems to be in views.inc (_build):

            $rc = $handlers[$id]->accept_exposed_input($this->exposed_data);
            $handlers[$id]->store_exposed_input($this->exposed_data, $rc);
            if (!$rc) {
              continue;
            }

store_exposed_input will internally only store (and otherwise clear) remembered input if $rc == TRUE.

But $rc is FALSE when the input is supposed not to affect the query (such as selecting the "All" option).

So looks like the logic is overally messed up, and the internals of accept_exposed_input are a bit messy to understand.

Proposed resolution

Pending.

Remaining tasks

Pending.

User interface changes

Pending.

API changes

None.

Original report by cYu

My problem happens when I set up a view with a "Content: Author" relationship, add an exposed filter for "User: Current", set it to non-required with a default value of yes or no, and enable "Remember the last selection".

When using the view and selecting yes or no, the selection will be saved after leaving and returning to the view. When selecting "- Any -" and then leaving and returning to the view, the default value will be selected instead of "- Any -".

This behavior appears to be the same with a simpler example of an exposed filter for "Content: Published" as well.

My temporary solution will be to make "- Any -" the default value, since that gives the appearance of remembering the last selection for each option, but the ideal default would be only showing nodes authored by the current user.

Comments

Ilikejava’s picture

I am having a similar issue. I have a binary field with a checkbox set up as a filter using Better Exposed Filters. I have Remember the Last Selection checked, which works for the default page, but not other pages.

I have other filters set up and it all works like I want it to across all pages in the view. I move from page to page by clicking on a link to the URL. I can't figure out why the filters that are all set up the same way act differently when not on the default page. This one filter happens to be a binary field. The Exposed Form is in a block.

pixelpreview@gmail.com’s picture

I have the same problem with the option "remember the last action"... I must switch to the core select

david_garcia’s picture

Issue summary: View changes
david_garcia’s picture

Issue summary: View changes
david_garcia’s picture

Project: Views (for Drupal 7) » Drupal core
Version: 7.x-3.7 » 8.0.x-dev
Component: exposed filters » views.module
Related issues: +#2459289: Boolean default values are not saved

Probably this bug is still present in D8, but cannot reproduce because of #2459289: Boolean default values are not saved.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jhedstrom’s picture

Issue tags: +VDC, +VDC-cleanup

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
quietone’s picture

Status: Active » Closed (cannot reproduce)
Issue tags: -VDC-cleanup +Bug Smash Initiative

I tested this on 9.4.x, standard install, and was not able to reproduce this error. I followed the steps given in the Issue Summary.

Therefore, closing as cannot reproduce. If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!