View Config: Serve supported action IDs from the REST controller

[oandregal]

Part of #76544

Status

THIS IS AN EXPERIMENT NOT READY TO REVIEW/LAND.

What?

Move the "which DataViews actions are supported" decision from the client-side registerPostTypeSchema thunk to the PHP view config REST controller.

Why?

Currently, registerPostTypeSchema makes 3 separate async resolveSelect calls (getPostType, canUser('create'), getCurrentTheme) to derive the list of supported actions — information the server already has access to. This duplicates server-side knowledge in the client and adds unnecessary round-trips. By having the server return the action list, the client becomes a simple consumer that maps IDs to implementations.

This also opens up PHP extensibility: plugins can now filter the action list via apply_filters( 'gutenberg_view_config_actions', ... ) without requiring JS.

How?

PHP controller (class-gutenberg-rest-view-config-controller-7-1.php):

• New get_actions( $kind, $name ) method returns an array of action ID strings based on post type capabilities, supports, slug, and theme context.
• The get_items() response now includes an actions key, wrapped in apply_filters for extensibility.
• Schema updated with the actions property (array of strings, readonly).

Client-side (packages/editor/src/dataviews/store/private-actions.ts):

• New ACTION_MAP constant maps 13 action IDs (e.g. 'view-post', 'duplicate-post', 'move-to-trash') to their JS implementations.
• registerPostTypeSchema now fetches viewConfig.actions from the server and maps IDs to implementations, replacing the ~50-line conditional action-building block.
• The canUser('create') async call is removed (no longer needed for action resolution).
• IS_GUTENBERG_PLUGIN and __experimentalTemplateActivate client-side gates for duplicate-post are preserved.
• Fields logic is unchanged.

Supporting changes:

• core-data selector default updated to include actions: undefined.
• useViewConfig return type updated to include actions: string[] | undefined.

Testing Instructions

1. Start wp-env (npm run wp-env start).
2. Navigate to the Site Editor → Pages list.
3. Verify all context menu actions appear (View, Rename, Duplicate, Move to Trash, etc.).
4. Check other DataViews screens: Posts, Patterns (wp_block), Template Parts, Templates.
5. Verify that the REST response at /wp/v2/view-config?kind=postType&name=page includes an actions array with the expected IDs.
6. Test with a user without create_posts capability — duplication actions should not appear.

Testing Instructions for Keyboard

1. Navigate to Pages list using keyboard.
2. Tab to a page row and use the actions menu (three-dot button or keyboard shortcut).
3. Verify all expected actions are present and navigable via arrow keys.

Screenshots or screencast

N/A — no visual changes; this is a data-flow refactor.

Use of AI Tools

This PR was authored with the assistance of Claude Code (claude-opus-4-6). All changes were reviewed for correctness.

[github-actions]

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

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should show correct homepage actions based on current homepage or posts page #68892 in /test/e2e/specs/site-editor/homepage-settings.spec.js