I have a view with a page which has an exposed filed on taxonomy terms with the "Remember the last selection" enabled. The view has the "Exposed form in block" option enabled. It works if the block is displayed on the same page, but not if the block is displayed on another page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Lukas von Blarer created an issue. See original summary.

Lukas von Blarer’s picture

In case this helps, here is the exported view:

uuid: 3b642e28-52e1-44f3-8906-6d14d0e42022
langcode: de
status: true
dependencies:
  config:
    - core.entity_view_mode.node.teaser
    - node.type.project
    - taxonomy.vocabulary.category
  module:
    - node
    - taxonomy
    - user
id: projects
label: Projects
module: views
description: ''
tag: ''
base_table: node_field_data
base_field: nid
core: 8.x
display:
  default:
    display_plugin: default
    id: default
    display_title: Master
    position: 0
    display_options:
      access:
        type: perm
        options:
          perm: 'access content'
      cache:
        type: tag
        options: {  }
      query:
        type: views_query
        options:
          disable_sql_rewrite: false
          distinct: false
          replica: false
          query_comment: ''
          query_tags: {  }
      exposed_form:
        type: basic
        options:
          submit_button: OK
          reset_button: true
          reset_button_label: Reset
          exposed_sorts_label: 'Sort by'
          expose_sort_order: false
          sort_asc_label: Asc
          sort_desc_label: Desc
      pager:
        type: none
        options:
          items_per_page: null
          offset: 0
      style:
        type: default
      row:
        type: 'entity:node'
        options:
          view_mode: teaser
      fields:
        title:
          id: title
          table: node_field_data
          field: title
          entity_type: node
          entity_field: title
          label: ''
          alter:
            alter_text: false
            make_link: false
            absolute: false
            trim: false
            word_boundary: false
            ellipsis: false
            strip_tags: false
            html: false
          hide_empty: false
          empty_zero: false
          settings:
            link_to_entity: true
          plugin_id: field
          relationship: none
          group_type: group
          admin_label: ''
          exclude: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: true
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_alter_empty: true
          click_sort_column: value
          type: string
          group_column: value
          group_columns: {  }
          group_rows: true
          delta_limit: 0
          delta_offset: 0
          delta_reversed: false
          delta_first_last: false
          multi_type: separator
          separator: ', '
          field_api_classes: false
      filters:
        status:
          value: true
          table: node_field_data
          field: status
          plugin_id: boolean
          entity_type: node
          entity_field: status
          id: status
          expose:
            operator: ''
          group: 1
        type:
          id: type
          table: node_field_data
          field: type
          value:
            project: project
          entity_type: node
          entity_field: type
          plugin_id: bundle
        field_category_target_id:
          id: field_category_target_id
          table: node__field_category
          field: field_category_target_id
          relationship: none
          group_type: group
          admin_label: ''
          operator: or
          value: {  }
          group: 1
          exposed: true
          expose:
            operator_id: field_category_target_id_op
            label: Category
            description: ''
            use_operator: false
            operator: field_category_target_id_op
            identifier: field_category_target_id
            required: false
            remember: true
            multiple: true
            remember_roles:
              anonymous: anonymous
              authenticated: authenticated
            reduce: false
          is_grouped: false
          group_info:
            label: ''
            description: ''
            identifier: ''
            optional: true
            widget: select
            multiple: false
            remember: false
            default_group: All
            default_group_multiple: {  }
            group_items: {  }
          reduce_duplicates: false
          type: select
          limit: true
          vid: category
          hierarchy: false
          error_message: true
          plugin_id: taxonomy_index_tid
      sorts: {  }
      title: Projects
      header: {  }
      footer: {  }
      empty: {  }
      relationships: {  }
      arguments: {  }
      display_extenders: {  }
      use_ajax: true
    cache_metadata:
      contexts:
        - 'languages:language_content'
        - 'languages:language_interface'
        - url
        - user
        - 'user.node_grants:view'
        - user.permissions
      cacheable: false
  page_1:
    display_plugin: page
    id: page_1
    display_title: Page
    position: 1
    display_options:
      display_extenders: {  }
      path: projects
      exposed_block: true
    cache_metadata:
      contexts:
        - 'languages:language_content'
        - 'languages:language_interface'
        - url
        - user
        - 'user.node_grants:view'
        - user.permissions
      cacheable: false
dawehner’s picture

Thank you for your great bug report!

I have some feeling that this is yet another cacheability issue. Did you tried to disable caching for the exposed form block?

I think we need to expand somehow the way how we render exposed forms to include the session cache context in case the view is configured to remember the value.

Lukas von Blarer’s picture

No, caching is disabled on this block.

Lukas von Blarer’s picture

Ah and I also disabled caching on the view itself. Could it be that the exposed filters are only safed for the corresponding path of the views page?

dawehner’s picture

Status: Active » Needs review
FileSize
8.11 KB

Alright, so we need the session value being part of the actual views cache context.

Wim Leers’s picture

  1. +++ b/core/core.services.yml
    @@ -47,6 +47,11 @@ services:
    +  cache_context.session_value:
    
    +++ b/core/lib/Drupal/Core/Cache/Context/SessionValueCacheContext.php
    @@ -0,0 +1,40 @@
    +class SessionValueCacheContext extends RequestStackCacheContextBase implements CacheContextInterface {
    

    I don't think we want an additional cache context; I think the existing session (\Drupal\Core\Cache\Context\SessionCacheContext) cache context can be updated to implement CalculatedCacheContextInterface, just like \Drupal\Core\Cache\Context\QueryArgsCacheContext already does for example.

    That'll then allow you to write session:some_key.

  2. +++ b/core/modules/views/src/Plugin/views/filter/FilterPluginBase.php
    @@ -1305,22 +1305,24 @@ public function storeGroupInput($input, $status) {
    -    if ($status === FALSE && isset($_SESSION['views'][$this->view->storage->id()][$display_id])) {
    -      $session = &$_SESSION['views'][$this->view->storage->id()][$display_id];
    +    if ($status === FALSE && $this->view->getRequest()->getSession()->has("views:{$this->view->storage->id()}:{$display_id}")) {
    +      $session = $this->view->getRequest()->getSession()->get("views:{$this->view->storage->id()}:{$display_id}");
    

    Just to make sure I understand: this change — and many like it — are not necessary strictly speaking, but they're just clean-up, right?

dawehner’s picture

Just to make sure I understand: this change — and many like it — are not necessary strictly speaking, but they're just clean-up, right?

Well, if we want to be able to use $request->getSession()->get() this would be needed.

Lukas von Blarer’s picture

Status: Needs review » Needs work

The patch did not fix the issue for me. The filters are applied, but when visiting the form again the default values are not being set. Is there anything I could do to help debug this?

The last submitted patch, 6: 2551431-5.patch, failed testing.

alexej_d’s picture

I can confirm that this bug still exists. It is obviously connected with the caching system. My views page does remember the settings of exposed filters but once caching is on the exposed filter persists till the next cache clearing which renders this function unusable with cache…

alexej_d’s picture

I also noticed a different problem: ViewExecutable.php has this line

    // unset items that are definitely not our input:
    foreach (array('page', 'q') as $key)

which is pretty fragile. When "remember the last selection" was active and I tried to fetch a view with a _format parameter in the url, the exposed filter would unset itself…

dawehner’s picture

which is pretty fragile. When "remember the last selection" was active and I tried to fetch a view with a _format parameter in the url, the exposed filter would unset itself…

OH yeah, can't agree more. Do you have a general idea how to deal with that?

alexej_d’s picture

Maybe each view with exposed forms has to store a list of applicable parameters. When you define a new exposed filter the list is updated. On request only parameters from this list are being considered. But I have no idea what the performance implications would be and I think at this stage it is too late to implement such a change…

legolasbo’s picture

This is probably a duplicate of #2596649: Exposed form does not save state when it is placed in a block, because at the exposed filter block does not provide any cacheability metadata, which it should do.

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.

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

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

So I tested by

Created a taxonomy page view
Added a filter by name checking if value contains and checking Remember last selection
Exposed the form block to yes
Placed the block on a random page and my view page
The search feature works on both (though on the random page it redirects me to the view page when I search)
Neither seem to "Remember my selection"

Interesting when I turn off exposed form block and go to the view page it doesn't remember my selection then either.

Not sure if I'm testing that right but any feedback would be appreciated.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.