Register and filter view config for DataViews/DataForm in the server

[oandregal]

We want to introduce the ability to configure the view/form config received by DataViews/DataForm for any given entity. For example, 3rd parties should be able to change what fields are visible in DataViews, or the default layouts.

The whole initiative is tracked in Gutenberg at ​https://github.com/WordPress/gutenberg/issues/76544

Trac ticket: https://core.trac.wordpress.org/ticket/65516

## What?

Introduces a server-side, filterable API for the DataViews/DataForm configuration of an entity, plus a REST endpoint that exposes it.

• wp_get_entity_view_config( $kind, $name ) (new src/wp-includes/view-config.php) builds the shared defaults (default view, layouts, view list, form) and runs them through a dynamic get_entity_view_config_{$kind}_{$name} filter so core and plugins can provide per-entity configuration.
• Core registers default providers for the page, post, wp_block, wp_template_part, and wp_template post types as filter callbacks on init (_wp_get_entity_view_config_post_type_*).
• WP_REST_View_Config_Controller exposes the config at GET /wp/v2/view-config?kind=…&name=…, delegating to the API and handling REST concerns (schema, edit_posts permission, empty-object serialization).
• Adds PHPUnit coverage for both the API and the controller.

## Why?

Part of ​https://github.com/WordPress/gutenberg/issues/76544

## How?

Backports the View Config REST API endpoint from Gutenberg to WordPress Core.

• [x] ​https://github.com/WordPress/gutenberg/pull/76573
• [x] ​https://github.com/WordPress/gutenberg/pull/76734
• [x] ​https://github.com/WordPress/gutenberg/pull/76622
• [x] ​https://github.com/WordPress/gutenberg/pull/76823
• [x] ​https://github.com/WordPress/gutenberg/pull/76953
• [x] ​https://github.com/WordPress/gutenberg/pull/76903
• [x] ​https://github.com/WordPress/gutenberg/pull/77290
• [x] ​https://github.com/WordPress/gutenberg/pull/78977
• [x] ​https://github.com/WordPress/gutenberg/pull/79195
• [x] ​https://github.com/WordPress/gutenberg/pull/76934
• [x] ​https://github.com/WordPress/gutenberg/pull/79347

## Testing Instructions

1. Start a WordPress development environment.
2. Log in as an admin user.
3. Send a GET request to /wp-json/wp/v2/view-config?kind=postType&name=post — verify it returns generic defaults (table view, author/status fields).
4. Send a GET request to /wp-json/wp/v2/view-config?kind=postType&name=page — verify it returns page-specific config (list view, status sub-views like Published, Drafts, Trash).
5. Send the same request as an unauthenticated user — verify it returns a rest_cannot_read error.

## Use of AI Tools

This backport was prepared with the assistance of Claude Code (Claude Opus 4.8).

[oandregal]

In 62547:

Add view config API and REST endpoint.

Introduce wp_get_entity_view_config( $kind, $name ) to build the shared DataViews/DataForm configuration for an entity (default view, layouts, view list, and form), exposed through a dynamic get_entity_view_config_{$kind}_{$name} filter so core and plugins can provide per-entity configuration. Core registers default providers for the page, post, wp_block, wp_template_part, and wp_template post types.

Add WP_REST_View_Config_Controller, which exposes the configuration at GET /wp/v2/view-config?kind=…&name=…, delegating to the API and handling schema, the edit_posts permission check, and empty-object serialization. Include PHPUnit coverage for both the API and the controller.

This ports the View Config REST API from the Gutenberg plugin. See ​https://github.com/WordPress/gutenberg/issues/76544.

Props ntsekouras, oandregal.
Fixes #65516.

## What?
Adds the wp_block form configuration for the View Config API so pattern summaries can expose the DataForm fields used by the editor sidebar.

This is a follow-up to WordPress/wordpress-develop#11272 and backports the PHP portion of WordPress/gutenberg#79452.

## Testing

• git diff --check
• php -l src/wp-includes/view-config.php && php -l tests/phpunit/tests/rest-api/rest-view-config-controller.php
• vendor/bin/phpcs src/wp-includes/view-config.php tests/phpunit/tests/rest-api/rest-view-config-controller.php
• php ./vendor/bin/phpunit --filter test_wp_block_config_includes_pattern_summary_form

Do we need a new trac ticket or we can re-open the previous one with the initial backport 🤔

Do we need a new trac ticket or we can re-open the previous one with the initial backport 🤔

I think it could go either way, but I suggest opening a new ticket linking back to the original one.

I suggest opening a new ticket linking back to the original one.

I opened a new trac ticket for this PR which will include two PRs from GB (see description)

Trac ticket: https://core.trac.wordpress.org/ticket/65516

## What

Ports the latest iteration of the view configuration API from the Gutenberg update/view-config-api-versioning branch:

## Why

## How

• Rework the WP_View_Config_Data write API around merge(), replace(), set(), and remove(), all operating on patches of top-level keys and taking the schema version the change was authored against.
• Make get_data() private and move filter application into a new apply_filters() method so callbacks cannot read the materialized configuration and become coupled to its shape.
• Update the default post type configuration callbacks to use the new single-patch set() signature.
• Adapt and expand the unit tests accordingly.

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code, Zed agent
Model(s): Opus, Fabble
Used for: Initial code skeleton and test suggestions; final implementation and tests were reviewed and edited by me.