Open
Conversation
Introduce view-level isRequired filters that can be edited but not removed or reset. Updates include: - types: add isRequired to Filter and NormalizedFilter. - filter component: treat required filters as non-removable/non-resettable in the UI. - reset-filters: exclude required filters from reset and persist them with locked filters when resetting. - use-filters: surface isRequired on normalized filters, make them always visible, and include required filters in sort order (after locked, before primary). - stories: add a RequiredFilter story demonstrating differences between isPrimary, isRequired, and isLocked and wire it into the stories index. This change clarifies filter semantics: isLocked = read-only, isRequired = editable but cannot be cleared/removed, isPrimary = field-level default visibility/behavior.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @ilonagl. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +73 B (0%) Total Size: 2.98 MB
ℹ️ View Unchanged
|
Member
|
Should the Another option could be changing how |
Contributor
|
Thanks for the review request, thanks for contributing. As I'm catching myself up, let me be sure I read this right: this is a mandated filter to reduce what DataViews shows to a particular CPT or otherwise? If yes, does this need a UI at all? It seems like a required filter should be an under-the-hood lock-in mechanism that is used situationally and therefore supported by its context. A "Posts" page is actually a good example: I click Posts, I expect to see only posts, never a page or a "podcast" CPT in there, and I would not go looking at filters to do so. |
Contributor
Conceptually this seems a bit more like navigation than filtering (acknowledging there's a lot of overlap :)). It's essentially the same as the bundled by-status views for Pages in the site editor but using the filter UI rather than a menu. That's not to say we shouldn't support this, but I'm curious to understand the use case a bit more. |
|
Thank you for working on this, @enejb! Appreciate it.
Very valid points. I just want to add a bit more context for this specific proposal. While it can feel close to navigation, most wp-admin plugins don’t have enough real estate to properly support navigation patterns (like page examples, CIAB designs, or richer IA). Given those constraints, using primary filters becomes a practical way to surface and switch between different types. Here are a couple of examples: 
|
Contributor
|
Thanks for sharing. This is just my take and I'm happy to defer to others, but from a UX perspective my instinct is that this would be better handled with tabs/navigation, like in the extensible site editor experiment. It seems identical to me. 
|
Contributor
Author
|
Thanks for the feedback and questions, @jasmussen and @jameskoster! We need a filter that stays visible and active at all times, the user must choose from its options but can never dismiss it. None of the existing filter attributes
This isn't specific to CPTs — it's a general-purpose filter attribute that lets developers create a persistent, non-dismissable filter. The current
See the screenshot provided by @ilonagl for the current use case. More broadly, this is useful any time you want the user to narrow down data using multiple mandatory filters — for example, tabs as a first level and a mandatory filter as a second level. Without mandatory filters, users can end up with an unfiltered view that is overwhelming, especially on mobile where horizontal space is limited and we have to display the value inline in each row when no filter is applied. (An example of this is showing post status in a row vs having it always be a filter)
Tab navigation doesn't work here because we're already one level deep in the information architecture — we already use tabs for the first dimension of filtering and need a second, independent dimension. Adding another layer of tabs would create a confusing nested tab pattern. To answer one more likely question: yes, combining multiple mandatory filters could result in zero results, but that scenario is already handled by the empty state. How do we move this work forward? |
Member
|
We have various filter types, select-based filters (like the one you use) are just one of them. See all field types (and filters). For example:
How this proposal would work with those other filter types, given the user can introduce empty values? |
Contributor
Author
|
@oandregal I haven't thought about this. Thanks for pointing it out. We could prevent the user from submitting an empty field by making the modal/dropdown not removable/dismisable. Or we could go back to the previous value or the default value. I would assume that the developer would provide a default value so they never end with an empty state. @oandregal Should I implement this in this PR? Which direction should I try? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a new
isRequiredproperty to DataViews filters that prevents users from removing or resetting the filter while still allowing them to interact with and change its value.Key difference from existing filter properties:
isRequiredisPrimaryisLockedUse case: Enforcing a filter that must always be active with a value (e.g., "only show my posts"), while still allowing the user to change which value is selected.
Changes
isRequiredproperty toFilterandNormalizedFilterinterfaces intypes/dataviews.tsuse-filters.tsto read and normalizeisRequired, include required filters in visibility, and sort them after locked filtersfilter.tsxto prevent reset/remove button for required filtersreset-filters.tsxto preserve required filters on resetisPrimary,isRequired, andisLockedUsage Example
Screenshots
Test plan
isLockedto confirm difference (isRequired allows interaction)