Extract entity view config into a filterable API

[oandregal]

Part of #76544
Follows-up on #76573 (comment)

What?

Extracts the per-entity view configuration logic out of Gutenberg_REST_View_Config_Controller_7_1 into a standalone, filterable API.

No change to the REST response shape (default_view, default_layouts, view_list, form).

Why?

Previously, the view configuration for every entity was hardcoded inside the REST controller and was not filterable.

Moving the logic behind a dynamic filter:

• Makes the view config extensible per kind/name (e.g. custom post types, custom entity kinds).
• Decouples the data model from the REST transport, so the same config can be reused outside the endpoint.
• Keeps the controller focused on REST concerns (schema, permissions, serialization).

How?

• New file lib/compat/wordpress-7.1/view-config-api.php with a public gutenberg_get_entity_view_config( $kind, $name ) function.
• The function builds the default config shared by all entities, then exposes it through a dynamic get_entity_view_config_{$kind}_{$name} filter so core and third parties can provide entity-specific configuration.
• The existing per-entity configs (postType × page, post, wp_block, wp_template_part, wp_template) are moved out of private controller methods and re-registered as filter callbacks.
• The REST controller (/wp/v2/view-config) now keeps only the routing, permission, and schema plumbing and delegates data building to gutenberg_get_entity_view_config().

Testing Instructions

These screens are powered by the /wp/v2/view-config endpoint via getViewConfig / useViewConfig (@wordpress/views). Confirm the refactor produces identical behavior.

1. Build Gutenberg (npm run build or npm run dev) and activate the plugin.
2. Open the Site Editor and verify each DataViews screen renders with its expected columns, default layout, and saved-view list (these come from default_view, default_layouts, view_list):
   • Pages — list layout with hierarchy levels, featured-media field, and the view list (All, Published, Drafts, Scheduled, Trash, etc.).
   • Posts — list with the post DataForm fields in the sidebar.
   • Patterns (wp_block) — grid layout and its view list.
   • Template Parts — its layout and view list.
   • Templates — table layout and the author-based view list (verify author filters appear).
3. Open a Page and a Post in the editor and confirm the post summary / DataForm sidebar fields render correctly (form config: featured image, excerpt, status/scheduled date/password/sticky, slug, author, template, discussion, parent, format).
4. Hit the endpoint directly and confirm the response is unchanged from trunk for each entity:
   • wp.apiFetch( { path: '/wp/v2/view-config?kind=postType&name=page' } ).then( console.log ) — repeat for post, wp_block, wp_template, wp_template_part.
   • Compare the JSON against trunk — default_view, default_layouts, view_list, and form should be byte-for-byte equivalent.
5. Verify the new extensibility point works — temporarily add a filter and confirm it's applied:

   add_filter( 'get_entity_view_config_postType_page', function ( $config, $entity ) {
       $config['default_view']['perPage'] = 5;
       return $config;
   }, 20, 2 );

   Reload the Pages screen / re-fetch the endpoint and confirm perPage is now 5.
6. Confirm a kind/name with no registered filter (e.g. kind=postType&name=attachment) still returns the generic default config without errors.
7. Confirm the permission gate is intact: an unauthenticated request (or a user without edit_posts) returns rest_cannot_read / 401.

Use of AI Tools

This pull request was prepared with the assistance of AI tooling (Claude Code). All changes were reviewed by the author, who takes responsibility for them.

[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>

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

[oandregal]

This code has been moved (and restructured) verbatim into the view-config-api.php file.

[Copilot]

Pull request overview

This pull request extracts entity “view config” construction out of the WordPress 7.1 REST controller into a standalone API function, so entity-specific configs can be provided/overridden via dynamic filters while keeping the /wp/v2/view-config response shape unchanged.

Changes:

• Added gutenberg_get_entity_view_config( $kind, $name ) as the central builder for view config defaults and a dynamic per-entity filter hook.
• Moved the previously hardcoded per-entity configurations (page/post/patterns/template parts/templates) into filter callbacks registered in the new API file.
• Simplified Gutenberg_REST_View_Config_Controller_7_1::get_items() to delegate config building to the new API.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
lib/load.php	Loads the new view-config API alongside existing WP 7.1 REST compat code.
lib/compat/wordpress-7.1/view-config-api.php	Introduces the filterable view-config API and registers per-entity default configs via filters.
lib/compat/wordpress-7.1/class-gutenberg-rest-view-config-controller-7-1.php	Removes embedded config-building logic and uses gutenberg_get_entity_view_config() instead.

[oandregal]

This API is inspired by how the existing table list / admin screen works, that allows 3rd parties to filter it (e.g., WP_Posts_List_Table, screen's get_hidden_columns, or WP_List_Table.

A few alternate designs that were considered:

• Use of multiple filters (e.g., one per top-level config) vs. a single one (existing approach). While it sounds sensible to use multiple filters at first, consumers will run into issues quickly: some of these configs may depend on each other (e.g., see how default_layouts is used to build the view_list), and so having multiple filters will require us passing the whole config anyway.
• Filter callback arguments. One could argue that a dynamic filter would not need to pass $kind and $name as arguments because the filter is bound to that entity. Take a couple of filters such as get_entity_view_config_postType_wp_template and get_entity_view_config_postType_page as examples. If a consumer binds the same filter callback to multiple filters, how would it extract the $kind and $name from those filters? It becomes a bit tricky given both $kind and $name can have underscores.
• Filter callback arity. While it's useful to provide $kind, $name, and even $all_items_title to filter callbacks that want to use them, the majority of them won't need them. Instead of incrementing the filter callback arity with 3 arguments, I thought we'd bundle everyone of these into a single $entity array. This approach is also more future proof: if we want to add new items in the future, it won't be a breaking change.

[github-actions]

Flaky tests detected in b28a21e.
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/27196606793
📝 Reported issues:

• [Flaky Test] Should save the changes #78689 in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js

[ntsekouras]

Let's get this in!