Attachments on Views Content Panes don't always inherit exposed filters

Created on 11 January 2014, almost 11 years ago
Updated 6 February 2023, almost 2 years ago

Use case: I want a "quicktabs" style view where each "tab" is a view result row. I'm rendering 3 nodes in the main display, and then the 3 node titles in the attachment. Then I have a bit of custom javascript that toggles the visibility of the appropriate node based on the link clicked. This requires the order of the titles in the attachment and the full node displays in the main display to match.

Setup: I have a Views Content Pane display configured in my view, which has an attachment. The attachment is configured to inherit arguments and exposed filters from the parent display. The content pane is configured so that the arguments and exposed filters / sorts can be configured via the panel pane configuration.

Situation: with the above setup, there is no exposed filters form displayed or rendered - the settings come from the panel pane. As a result, there are no $_GET parameters in the url showing what the exposed input values are.

Problem: the parent content pane display receives the exposed input values from the pane configuration, and that display appears correctly. However, the attachment doesn't receive its exposed input values from the parent display - it is still looking at the url for the $_GET parameters, even though it has the correct values in $view->exposed_input (when printed in the "attach_to()" function in plugins/views_plugin_display_attachment.inc). It doesn't have $view->exposed_raw_input or $view->exposed_data set initially, however once get_exposed_input() function is executed all of these 3 variables are set to the default values, not the actual values configured in the panel pane.

This means that the content pane and its attachment are using different exposed filters/sorts, which is causing problems with my "quicktabs" use case as there is a different sort applied to the 2 displays, and so there is a mismatch between the title clicked and node content displayed.

Solution: 2 line patch (see attached) which uses the "exposed_input" as the parent display and calls $view->set_exposed_input(). This prevents the exposed form being submitted again which would result in the default exposed filter/sort settings being used rather than those configured in the panel pane.

🐛 Bug report
Status

Postponed: needs info

Version

9.5

Component
Views 

Last updated about 4 hours ago

Created by

🇮🇪Ireland stella

Live updates comments and jobs are added and updated live.
  • VDC

    Related to the Views in Drupal Core initiative.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States smustgrave

    This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

    Wonder if this is an issue for D10? I have not seen this issue yet

    If so could the IS be updated for D10 steps please
    Still needs tests also.

  • 🇺🇸United States emerham

    Yes this still an issue with Drupal 10.3

    My steps are simple view

    Have a node bundle with two fields:

    • Body
    • Select List Text

    Create a Paged view and expose the filter of the Select list

    Create an attachments view display and attach it to the paged view. Exposed the same filter from the paged view with the same identifier

    Ensure the Inherit exposed filters is checked

    Attempt to filter the paged view and see that the attachments view is not filtered.

    If these are the steps that would let this be reproducible then I can update the issue and start working on some tests.

Production build 0.71.5 2024