Views: honor all developer-defined view config overrides

[oandregal]

Fixes #80778.
Backport at WordPress/wordpress-develop#12766

What?

Fix useView hook so that the server-side view config filters are respected:

• search and page URL params: ignored for now (see conversation). They cannot be set via PHP.
• view_list overrides for type, perPage, fields are now applied, users can modify unlocked filters provided by a view

Why?

Closes #80778.

How?

• The view resolution in @wordpress/views only merged a fixed set of override keys, so type, perPage, and fields from view_list were silently ignored (e.g. the bundled "Trash" view rendered as a list despite being configured as a table).
• Override filters always replaced the user's same-field filter and were stripped before persisting, so unlocked filters could not be modified.

In mergeActiveViewOverrides/stripActiveViewOverrides, type, perPage, and fields now follow the same pattern as sort: the override applies while the view still matches the default view, so an explicit user change wins and is persisted. Locked filters keep replacing same-field filters and are never persisted, while unlocked filters act as defaults that a user-modified filter beats.

Testing Instructions

Add the two filter callbacks from the issue description (#80778) to any PHP file, then open Pages in the Site Editor: the "My view" tab should load with the grid layout, page size, and fields from the config, and its status filter should be user-editable; the bundled "Trash" view should render as a table.

Use of AI Tools

This PR (investigation, code, tests, and description) was authored with Claude Code using the Claude Fable 5 model, directed and reviewed by a human contributor.

Follow-ups

• DataViews: improve messaging for out-of-bounds page #80840
• Views: honor all developer-defined view config overrides #80832 (comment) Change how the persistence model works.

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Copilot]

Pull request overview

This PR fixes @wordpress/views view-resolution so server-provided view config overrides are fully honored (especially view_list overrides) while still allowing user preferences to win once a user explicitly changes an overridden setting.

Changes:

• Resolve URL-managed search/page as URL param → active override → default view (and exclude them from persistence comparisons).
• Apply type/perPage/fields overrides as “default-bound” (only while the current view still matches defaultView), and refine filter override behavior so unlocked filters are user-editable while locked filters remain enforced and never persisted.
• Add unit tests covering useView URL fallback behavior, overridden layout defaults, and the new override/stripping semantics.

Reviewed changes

Copilot reviewed 8 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
packages/views/src/use-view.ts	Fixes search/page fallback + persistence comparison; resolves layout defaults using effective type from active overrides.
packages/views/src/load-view.ts	Mirrors useView resolution for route loaders, including effective type for layout defaults.
packages/views/src/filter-utils.ts	Implements default-bound overrides (type/perPage/fields) and refined locked vs unlocked filter override/strip behavior.
packages/views/src/types.ts	Extends ActiveViewOverrides typing to include default-bound and URL-managed keys.
packages/views/src/test/use-view.tsx	Adds useView tests for URL/override/default resolution and overridden layout defaults.
packages/views/src/test/filter-utils.ts	Adds coverage for new default-bound override and filter lock/unlock semantics.
packages/views/package.json	Adds @testing-library/react as a dev dependency for the new hook tests.
packages/views/CHANGELOG.md	Documents the behavior fixes under Unreleased bug fixes.
package-lock.json	Updates lockfile for the new workspace dev dependency entry.

[github-actions]

Size Change: +11 B (0%)

Total Size: 7.78 MB

📦 View Changed

Filename	Size	Change
build/modules/content-types/index.min.js	166 kB	+12 B (+0.01%)
build/scripts/edit-site/index.min.js	306 kB	-43 B (-0.01%)
build/scripts/editor/index.min.js	501 kB	-2 B (0%)
build/scripts/media-utils/index.min.js	122 kB	+44 B (+0.04%)

_{compressed-size-action}

[oandregal]

For anyone reviewing: at this point, focus the reviews on "does this work?", "what are the side effects", "is it future proof?" rather than on variable naming, etc. I'm still testing scenarios and verifying the persistance mechanism.

[github-actions]

Flaky tests detected in 1444e8c.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/30547485693
📝 Reported issues:

• [Flaky Test] should paginate, navigate pages, and diff across page boundaries #80154 in /test/e2e/specs/editor/various/revisions.spec.js

[oandregal]

I've ran into this scenario #80840 but it also happens in trunk. Leaving it as a follow-up and not required for this to land.

[oandregal]

Update: #80832 (comment)

The changes to support search and page are solid, as far as I could test (with this patch). As before, the source of truth for these parameters remains the URL, and they are not persisted.

What changes here is

The fallback:

• before: they'd fallback to baseView (either the persisted view or the default)
• now: they fallback to active overrides or default view. This makes more sense as these parameters were never persisted (so no point in fallback to the persisted view) and both the default view or view_list can have them.

They still work after user changes:

• Before:

Screen.Recording.2026-07-29.at.13.12.30.mov

• After:

Screen.Recording.2026-07-29.at.12.16.58.mov

[oandregal]

Prepared backport with PHP changes at WordPress/wordpress-develop#12766

[oandregal]

One of the aspects that is challenging here is how the user preferences have been modeled to work with anything else:

• The preferences store user preferences (e.g., changes to a filter) and the default view. Overrides (view list, default layouts) are not stored.
• There are three different sources of data: core, plugins, users. Plugins can filter the default view or overrides.

So, there may be situations like this:

• User changes the sorting field (and so the view is stored with that change + the default view).
• User installs a plugin that modifies the type of the default view.
• The plugin changes WILL NOT take effect. The default view is ignored when there's user changes (which is the case here).

But:

• User changes the sorting field (and so the view is stored with that change + the default view)
• User installs a plugin that modifies the type of one of the view list items (overrides).
• The plugin changes WILL take effect. The overrides take precedence when we detect user hasn't changed anything from the default (which is the case here).

I think a simpler model to reason (and compute) would be: store only the user changes, not a whole view. And the hierarchy is core < plugin < user changes. This is, user changes take precedence over anything else, but only for the things they actually changed. That's how theme.json works, for example.

However, this is a change with how preferences work and would require users to reset their views. Additionally, the useView hook landed in WordPress 6.9, and we are in the RC cycle for 7.1. While I'd like to push for this change, I reckon the need for wider testing. This doesn't seem a good time for this. I'd leave it as it is, and will revisit later as necessary.

[ntsekouras]

It seems safe to implement that change, for people with the views preference stored with the old approach things will work as they were right? The same view will load (it is just our system thinks the user configured everything) but the end result is the same? These users will just face the default bug that already existed correct?

Yeah, if we don't clear those preferences, they stay as they are. Meaning that there's more preferences stored than the user selected, as so filters won't work because there's an user preference. This can be fixed by reseting the view and start over.

I think it's fine that preferences stored by the old model keep working as they do today. That keeps their current setup stable.

[ntsekouras]

I think that's ready to land. Thanks for all the iterations!

[github-actions]

I just cherry-picked this PR to the wp/7.1 branch to get it included in the next release: ad20d8f

[manzoorwanijk]

This is not correct. The preferences store is fully typed. Apart from that, we should use // @ts-expect-error to ensure this suppression is flagged when things change.

Also, I just now noticed that the package uses React without declaring react or react-dom as a dependency.