WordPress 7.1 Site Editor Screen Filters: A First Look

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Every enterprise WordPress build I have shipped in the last decade has the same conversation at some point. The client’s content team looks at the Pages screen, or Templates, or Patterns, and asks the same question: “Can we hide these columns, sort by the date field we actually care about, and stop showing drafts nobody owns?” And the answer, for years, has been a small pile of JavaScript that leans on private APIs, dies quietly at the next release, and has to be rewritten by whoever inherits the retainer.

WordPress 7.1 finally gives that conversation a real answer. Four new PHP filters let you configure the Site Editor’s DataViews screens — Pages, Templates, Template Parts, Patterns — from the server, in a shape that survives updates the way pre_get_posts and manage_edit_columns have survived for fifteen years. No React tree to wrap. No private hook to guess at. One filter per screen, one shared config object, four narrow methods to mutate it.

This is a small dev note with a large downstream effect. If you run agencies that build editorial workflows on top of WordPress, this is one of the two or three most useful things landing in 7.1 for the people who actually touch the admin every day.

What is actually new

The Filtering Site Editor Screens in WordPress 7.1 dev note by André Maneiro, published July 31, 2026 on Make/Core and reviewed by @ntsekouras and @priethor, introduces four new PHP filters that mirror the four DataViews-powered screens in the Site Editor:

• get_entity_view_config_postType_page — Pages screen
• get_entity_view_config_postType_wp_template — Templates screen
• get_entity_view_config_postType_wp_template_part — Template Parts screen
• get_entity_view_config_postType_wp_block — Patterns screen

Each filter receives a Gutenberg_View_Config_Data object and lets you configure four aspects of the corresponding screen. default_view controls the DataViews layout — which fields are visible, the sort order, the default view type (table, grid, list). default_layouts sets which layout options users can switch between. view_list is the preconfigured sidebar (the “All”, “Published”, “Drafts” entries you see on the left). form configures the Quick Edit form: which fields show, in which order, whether they open by default. All four are declarative arrays. No React needed.

The config object exposes four mutation methods that determine how you compose with defaults. merge() adds new entries and leaves existing ones intact. remove() deletes specific entries by key. replace() substitutes an indexed array wholesale. set() is the sledgehammer — top-level replacement that, per the handbook update, “drops whatever the key held before”. The naming discipline matters: merge is the default reach for most curation work, set is where you tell the client to sign off in writing first.

The full arc lives in Gutenberg tracking issue #76544 “Register view/form config in the server” opened by André Maneiro (oandregal) on March 16, 2026. That issue links the four merged PRs that shipped this surface: #76573 for Pages, #76622 for Templates, #76734 for Patterns, #76953 for the Quick Edit form config, plus #78977 which added the filterable PHP API on top. Everything ships in WordPress 7.1 GA on August 19, 2026, per the release party schedule.

What is not shipping: no inspector-side UI to record these filters through clicks. The point of this release is the server-side seam. If a settings-screen wrapper eventually lands, it will land on top of this API. Do not wait for it; the filter is the contract.

Why it matters for WordPress and WooCommerce people

Every serious editorial workflow I have built on WordPress in the last five years has bumped against the same wall: the Site Editor screens ship one opinionated view, and the client wants a different one. The store’s content manager wants Pages sorted by “last modified” not “date created”. The WooCommerce merchandiser wants Patterns filtered to only show product-card variants. The legal team wants Templates with a “Owner” column added by a custom field. Until 7.1, every one of these lived in a JavaScript file that hooked a private slot, prayed the store shape did not change, and broke on every other Gutenberg release.

Moving this to server-side PHP filters is the same governance move WordPress has made every time it wanted a customisation surface to survive a decade. register_post_type, pre_get_posts, manage_edit_{$post_type}_columns, rest_prepare_{$post_type} — all boring, all durable, all still working the way they did when they shipped. The Site Editor screen filters slot into that same shape. Ten lines of PHP in a client’s mu-plugin folder now buys you a curated Pages screen that will still be a curated Pages screen in WordPress 8.5.

For WooCommerce agencies specifically, the interesting screen is Patterns. Stores that lean on block themes accumulate dozens of patterns — hero variants, product cards, testimonial layouts, promotion banners. The default Patterns screen dumps them all into one grid. With get_entity_view_config_postType_wp_block you can register a sidebar view per business context (“Product cards”, “Homepage sections”, “Legal footers”), sort them by “last used” instead of alphabetical, and hide the fields the merchandiser does not need. That is the shape of curation that turns a Gutenberg screen from a developer tool into an editorial tool.

The wider signal is that WordPress 7.1 keeps quietly hardening the seams around the Site Editor. This dev note landed the same day as Design System Theming, and two days after the Abilities API execution lifecycle filters. Three separate surfaces, three separate teams, one common pattern: give the admin a proper extension seam and let plugins retire the private-API hacks. This is the year that pays off.

What I would do (or not do) about it

Four steps for the next three weeks, in order, on a WordPress 7.1 Beta 4 staging clone or a Playground blueprint. Do not run any of this on production before GA.

First, audit every mu-plugin, child theme, and admin script you maintain for private-API access to DataViews. Anything reaching into @wordpress/dataviews internals, anything filtering fields with a useSelect against the entity store, anything trying to force a sort order via JavaScript at editor load — list it. That is the migration inventory. Most of what you find will collapse to a five-line PHP filter after 7.1 GA, and the plugin build step goes with it.

Second, prototype one screen against one filter on staging. Pick the flattest case in your client roster — probably the Pages screen for an editorial site — and rewrite the existing customisation as a get_entity_view_config_postType_page handler that uses merge() to add fields and replace() to swap the sidebar view list. Prove the diff is empty against the current production behaviour before you touch any other screen.

Third, if you maintain a distributed plugin whose admin surface wraps Site Editor screens (WooCommerce extensions with Pattern browsers, membership plugins with restricted-page views, DAM integrations with custom Templates filters), start planning a version release aligned with 7.1 GA that ships a PHP filter path alongside the existing JS. Do not remove the JS. Layer the PHP as the preferred path, feature-flag on function_exists( 'gutenberg_get_view_config' ) or the 7.1 version check, and let the JS fall through as fallback for 7.0 users through the end of the year.

Fourth — the negative list. Do not install any plugin whose entire pitch is “adds a UI to configure the Site Editor screen filters”. The filter is one function per screen. Wrapping it in a settings page that stores the config in wp_options creates exactly the technical debt this API was designed to retire. If the client needs a UI, build it inside your own mu-plugin against the client’s brand, versioned with the site, and gone the day the client leaves.

Do not stack this test cycle on the WooCommerce 11.0 upgrade window either. WC 11.0 lands August 4 after last week’s RC1 delay, WP 7.1 lands August 19. Sequential change windows save weekends, and putting two moving DataViews-adjacent surfaces in the same triage queue is how you spend a Saturday narrowing which one broke.

Five years from now, when someone inherits a WordPress site you built in 2026 and finds a tidy little mu-plugin with four filters that shape the entire content team’s daily view of the CMS, that is what the boring, quiet governance layer looks like when it is working. This is one of those pieces.