Evaluate views reference filters module to configure views paragraphs with exposed filters instead of contextual arguments.

[trackleft]

Description

Related issues

Closes #3443

How to test

Types of changes

Arizona Quickstart (install profile, custom modules, custom theme)

• Patch release changes
  • Bug fix
  • Accessibility, performance, or security improvement
  • Critical institutional link or brand change
  • Adding experimental module
  • Update experimental module
• Minor release changes
  • New feature
  • Breaking or visual change to existing behavior
  • Upgrade experimental module to stable
  • Enable existing module by default or database update
  • Non-critical brand change
  • New internal API or API improvement with backwards compatibility
  • Risky or disruptive cleanup to comply with coding standards
  • High-risk or disruptive change (requires upgrade path, risks regression, etc.)
• Other or unknown
  • Other or unknown

Drupal core

• Patch release changes
  • Security update
  • Patch level release (non-security bug-fix release)
  • Patch removal that's no longer necessary
• Minor release changes
  • Major or minor level update
• Other or unknown
  • Other or unknown

Drupal contrib projects

• Patch release changes
  • Security update
  • Patch or minor level update
  • Add new module
  • Patch removal that's no longer necessary
• Minor release changes
  • Major level update
• Other or unknown
  • Other or unknown

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[ejsamboy]

After enabling and configuring the View Reference Filters module on a multidev site, I successfully ran several tests (see screenshots below).

Note: The module appears to function correctly; however, it is not yet covered by the security advisory policy. There is an open ticket to include it in the security advisory policy.

Also, I reached out to the module maintainer, @roborew, via Slack and the ticket, but haven't received a response yet.

Content type: Expose filter option

Views Paragraphs: Checkbox for enabling and disabling the exposed filter.

After enabling the exposed filter

View with the exposed filter disabled

[trackleft]

Troy mentioned we should keep the argument filters
Dana asked how to set the operator

[joeparsons]

TODO: add back optional views to config.

[natebyerley]

Questions:

• should we have both "Select a Category" and "Argument" options?
• if Category and Argument do not reference same Taxonomy, no items shown
• What views would we add this to?
• If we add to existing views, argument would remain after upgrade so View is not changed, but we then run into the issue of clients needing to be educated on the fact that there are two different settings that change the same thing in Views?
• Perhaps we put help text to guide clients?

[trackleft]

TODO remove the option to expose the filter.

[trackleft]

• should we have both "Select a Category" and "Argument" options?

My opinion is that the goal should be to replace the existing "Argument" option with the "select a category" option.

• if Category and Argument do not reference same Taxonomy, no items shown

This will cause a lot of trouble for us.

• What views would we add this to?

Hopefully all of the views that are currently configurable with the argument.

• If we add to existing views, argument would remain after upgrade so View is not changed, but we then run into the issue of clients needing to be educated on the fact that there are two different settings that change the same thing in Views?

Hopefully we can write a migration/database update to move existing values for the argument into new values for select a category option.