[jorgefilipecosta]

Part of #83537.

Right now, since #84650, plugins can register actions in PHP and the /wp/v2/entity-actions route returns them, but the editors don't read them. The core actions are still decided on the client: registerPostTypeSchema() computes them from the supports of the post type, the theme and what the user can do, and registers them in the core/editor store. So plugins can only replace or remove them in JavaScript, with registerEntityAction() and unregisterEntityAction(), which only exist in the Gutenberg plugin.

This PR makes the editors read the actions from the server, and registers the core actions there, like a plugin registers its own:

• Adds the private getEntityActionsConfig( kind, name ) selector to @wordpress/core-data, which fetches the route, and a private useEntityActions() hook to the editor, which imports the script modules of the response and merges their parts into its actions, in the order of the response.
• Registers the core actions in PHP, from packages/core-actions/src/index.php, at priority 0, so a plugin hooking wp_entity_actions_api_init at the default priority can unregister or replace them. Each action gets an action.php next to its action.tsx with its serializable part, and the conditions registerPostTypeSchema() checked move to PHP: the supports of the post type, whether it is viewable, whether the theme is a block theme, and the create_posts capability of the post type for the duplicate actions. The build copies the PHP files with the gutenberg_ prefix, as Fields API #83368 does for @wordpress/core-fields, and the plugin unhooks the register_core_entity_actions() WordPress will ship, so only its copy registers them.
• Makes usePostActions() show only the actions registered on the server, and removes the actions from registerPostTypeSchema() and from the core/editor store. The editor no longer imports the modules itself, nor depends on @wordpress/core-actions.
• Makes @wordpress/core-actions private, like @wordpress/core-fields: no package depends on it anymore.
• Reverts the @wordpress/build change of Actions API: Extract the core actions into the @wordpress/core-actions script modules #84643 that registered the module_dependencies of each script. It was only needed for the literal import()s of the editor: _wp_add_entity_action_modules_to_editor_script() now adds the modules the server lists to the import map, which stays the same on the post editor, the site editor, and the extensible site editor.
• Shows a snackbar when the actions of a post type cannot be loaded, since a list or the inspector is then left with no action. It stays until it is dismissed, as the page has to be reloaded. Like useFields() of the fields loader, useEntityActions() returns the error along with the actions.
• Preloads the actions of the post type the post editor edits, which the actions menu of the document sidebar requests as the editor loads.
• Removes the serializable parts from the @wordpress/core-actions modules, which keep only the JavaScript parts.
• Deprecates registerEntityAction() and unregisterEntityAction(): they warn and have no effect.
• Documents in the README of @wordpress/core-actions how to replace a core action: merge the changes into the definition wp_unregister_entity_actions() returns, and register it again only when something was unregistered.
• Adds the "Gutenberg Test Entity Actions API" e2e test plugin, which adds an action with its own script module to pages, replaces "Trash…" and removes "Duplicate…". Its spec covers the lists and the inspector of the editor, and runs in the site editor and in the extensible site editor.

Some notes:

• The client code was in Actions API: Register the entity actions on the server #84650 before, which landed with only the server code, like Fields API: Add the server-side registry and REST route #84078 for fields. It follows the entity naming of Rename "fields" to "entity fields" #84691: the route is /wp/v2/entity-actions, the selector getEntityActionsConfig and the hook useEntityActions.
• useEntityActions() is private and temporary. It lives in the editor because every screen showing actions loads it (the post editor, the site editor and the extensible site editor), and it mirrors useFields() of the fields loader (Fields API: Add @wordpress/fields-loader and the getFieldsConfig selector #84323). Once the place of the fields loader settles, it moves next to it, and so does the way the modules reach the import map, through wp-editor for now (as discussed in Fields API #83368 (comment)). There is no loadEntityActions() for route loaders, since no route needs the actions before rendering.
• An action without a callback or a RenderModal from its module cannot run, so it is skipped with a warning. A module that fails to load is reported, and only its actions are skipped. An entry of a module for an action it was not registered with is ignored.
• The site editor requests the actions of a list or of the page it opens, along with other requests it does not preload yet, so the preload test of the site editor now lists it. Preloading the actions of its screens can follow the way Fields API #83368 preloads the fields of the same screens.
• The actions are the same as on trunk. On wp-env I compared, for the 11 post types of the site, the ids, order, labels, flags and modal options of the actions an administrator, an editor and an author get, and their eligibility; the menus of every item of the lists of both site editors and of the inspectors; and the result of running each action, single and bulk. The only difference: global styles and font faces now get "Duplicate…". The server checks the create_posts capability of the post type, while canUser( 'create' ) checked whether its REST route accepts POST, which these two routes do not. No screen shows the actions of these post types.
• There is no wp_register_entity_action_collection() like the field collections. Which actions a post type gets depends on conditions, not only on the post type, so register_core_entity_actions() registers them in one loop, in the order the menus show them.
• The registry is built for each request, so the duplicate actions are only registered when the current user can create posts of the type, as I suggested for the sticky field in Fields API #83368 (comment).
• The labels of the action.php files are translated on the server. The strings of the modules (modal texts, notices…) need Script Modules: Fix missing translations of script modules #84651, like the ones of Actions API: Extract the core actions into the @wordpress/core-actions script modules #84643, which is why this is a draft.
• "Set as homepage" and "Set as posts page" are still added by usePostActions(). Actions API: Register the homepage and posts page actions as entity actions #84646 makes them entity actions; whichever of the two PRs lands second moves them to the server, behind manage_options.

Testing Instructions

1. Build the plugin and start wp-env with a block theme active (Twenty Twenty-Five).
2. Create a draft page and a pattern, and customize the "Page: 404" template.
3. In the console of http://localhost:8888/wp-admin/site-editor.php?p=%2Fpage, run await wp.apiFetch( { path: '/wp/v2/entity-actions?kind=postType&name=page' } ) and verify it returns the actions of pages, and the @wordpress/core-actions/post_type_supports module with the ids of the actions it applies to.
4. On the same screen, open the actions of the draft page and verify the menu shows View, Trash…, View revisions, Duplicate…, Rename… and Order…, as on trunk. Rename, order, duplicate and trash the page; then, in http://localhost:8888/wp-admin/site-editor.php?p=%2Fpage&activeView=trash, restore it, trash it again and permanently delete it.
5. Go to http://localhost:8888/wp-admin/site-editor.php?p=%2Fpattern&postType=wp_block&categoryId=my-patterns. Export the pattern as JSON, rename it, duplicate it, and delete the copy and the pattern.
6. Go to http://localhost:8888/wp-admin/site-editor.php?p=%2Fpattern&postType=wp_template_part&categoryId=all-parts. Duplicate a template part and delete the copy.
7. Go to http://localhost:8888/wp-admin/site-editor.php?p=%2Ftemplate and reset "Page: 404".
8. Open a page in the post editor and verify the actions menu of the inspector. In the Network panel of the developer tools, verify the editor made no request to /wp/v2/entity-actions, which is preloaded.
9. In http://localhost:8888/wp-admin/site-editor.php?p=%2Fpage, block the requests to /wp/v2/entity-actions in the developer tools (Network request blocking) and reload. Verify a snackbar says "Could not get a valid response from the server.", and that it stays until you dismiss it.
10. Start the tests environment (npm run wp-env-test start), activate "Gutenberg Test Entity Actions API" in http://localhost:8889/wp-admin/plugins.php, and create two pages, one with comments open and one with comments closed. In http://localhost:8889/wp-admin/site-editor.php?p=%2Fpage, verify the page with comments open has "Close comments", and that it closes its comments, while the other page doesn't have it. Verify the menus show "Move to bin…" instead of "Trash…", which still asks for confirmation and moves the page to the trash, and no "Duplicate…". No "Archive" action shows: the module of the plugin exports it, but nothing registers it. Verify the same in the actions menu of the inspector when editing a page.
11. Enable the "Extensible Site Editor" experiment, then repeat steps 4 to 7 in http://localhost:8888/wp-admin/admin.php?page=site-editor-v2, and step 10 in http://localhost:8889/wp-admin/admin.php?page=site-editor-v2.

AI usage disclosure: fix and description drafted with AI assistance and reviewed by me.

[github-actions]

🤖 PR meta 🤖

🎉 Props

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: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

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

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: -144 B (0%)

Total Size: 8.85 MB

📦 View Changed

Filename	Size	Change
build/modules/core-actions/post_type_supports.min.js	6.21 kB	-219 B (-3.41%)
build/modules/core-actions/wp_block.min.js	6.35 kB	-78 B (-1.21%)
build/modules/core-actions/wp_template_part.min.js	1.23 kB	-58 B (-4.51%)	✅
build/scripts/core-data/index.min.js	79.2 kB	+87 B (+0.11%)
build/scripts/edit-post/index.min.js	52.8 kB	+8 B (+0.02%)
build/scripts/editor/index.min.js	609 kB	+116 B (+0.02%)

_{b8873c4 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	9356b73	trunk	% Change
timeToFirstByte	58.05 ms +4.82% -5.08%	55.75 ms +10.49% -2.06%	4.13%
largestContentfulPaint	98 ms +8.16% -6.12%	94 ms +8.51% -6.38%	4.26%
lcpMinusTtfb	38.8 ms +15.85% -3.87%	36.25 ms +8.83% -5.93%	7.03%
wpBeforeTemplate	29.94 ms +9.95% -1.87%	29.26 ms +9.36% -1.03%	2.32%
wpTemplate	23.15 ms +3.97% -6.18%	22.43 ms +3.83% -2.94%	3.21%
wpTotal	54.04 ms +5.44% -5.01%	51.83 ms +11.23% -1.5%	4.26%
wpMemoryUsage	7.62 MB +0% -0%	7.58 MB +0% -0%	0.49%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	9356b73	trunk	% Change
timeToFirstByte	48.45 ms +3.51% -2.17%	47.4 ms +8.86% -1.79%	2.22%
largestContentfulPaint	104 ms +3.85% -0%	104 ms +3.85% -0%	0%
lcpMinusTtfb	56.8 ms +2.73% -1.06%	57.35 ms +1.31% -2.18%	-0.96%
wpBeforeTemplate	27.37 ms +3.4% -0.73%	27.27 ms +6.71% -1.98%	0.37%
wpTemplate	17.13 ms +4.44% -2.8%	17.17 ms +4.95% -3.9%	-0.23%
wpTotal	45.13 ms +4.01% -2.39%	44.17 ms +8.99% -1.81%	2.17%
wpMemoryUsage	6.28 MB +0% -0%	6.24 MB +0% -0%	0.61%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	9356b73	trunk	% Change
mediaProcessingJpeg	410.76 ms +1.04% -1.13%	406.44 ms +0.85% -1.13%	1.06%
mediaProcessingAvif	6068.87 ms +0.31% -0.19%	6077.44 ms +0.05% -0.18%	-0.14%
mediaProcessingJpegToAvif	4185.23 ms +0.22% -0.22%	4189.07 ms +0.06% -0.19%	-0.09%

media-upload

Metric	9356b73	trunk	% Change
jpegUploadProcessing	1445.83 ms +36.74% -1.11%	1414.2 ms +3.32% -0.5%	2.24%
pngUploadProcessing	201.8 ms +10.41% -6.05%	200.46 ms +6.33% -13.87%	0.67%
largeJpegUploadProcessing	1418.8 ms +0.72% -0.34%	1407.14 ms +0.69% -0.53%	0.83%
multipleImageUploadProcessing	1593.74 ms +1.16% -0.4%	1577.21 ms +0.42% -1.08%	1.05%

post-editor

Metric	9356b73	trunk	% Change
serverResponse	381.45 ms +4.14% -2.56%	396.21 ms +5.82% -2.41%	-3.73%
firstPaint	372.49 ms +20.86% -24.33%	457.71 ms +2.73% -31.08%	-18.62%
domContentLoaded	1049.07 ms +3.82% -1.18%	1065.85 ms +1.81% -0.42%	-1.57%
loaded	1050.3 ms +3.82% -1.22%	1067.07 ms +1.79% -0.42%	-1.57%
firstContentfulPaint	447.36 ms +4.76% -5.27%	468.86 ms +0.49% -1.87%	-4.59%
firstBlock	3172.96 ms +1.42% -1.46%	3188.41 ms +0.74% -1.22%	-0.48%
type	16.91 ms +1.71% -2.72%	16.58 ms +2.9% -2.11%	1.99%
typeWithoutInspector	16.94 ms +7.08% -2.95%	17.63 ms +1.93% -7.43%	-3.91%
typeWithTopToolbar	22.59 ms +3.41% -6.77%	21.66 ms +4.76% -4.34%	4.29%
typeContainer	8.39 ms +7.03% -5.01%	8.42 ms +8.91% -9.03%	-0.36%
focus	121.96 ms +4.76% -3.16%	116.89 ms +3.32% -1.69%	4.34%
firstFocus	218.29 ms +0% -0%	217.31 ms +0% -0%	0.45%
selectAll	498.22 ms +6.51% -2.09%	504.05 ms +4.14% -2.38%	-1.16%
listViewOpen	73.2 ms +2.81% -5.9%	73.53 ms +3.43% -4.66%	-0.45%
inserterOpen	38.37 ms +6.44% -1.43%	37.33 ms +9.13% -3.24%	2.79%
inserterHover	12.42 ms +7.89% -7.09%	12.24 ms +8.82% -9.07%	1.47%
inserterSearch	8.78 ms +5.92% -6.04%	8.39 ms +5.01% -4.41%	4.65%
loadPatterns	654.64 ms +2.43% -1.61%	622.49 ms +4.03% -2.7%	5.16%
wpTotal	372.11 ms +4.19% -2.64%	386.7 ms +5.62% -2.47%	-3.77%
wpMemoryUsage	13.51 MB +0% -0%	13.38 MB +0% -0%	0.94%
wpDbQueries	54 +0% -1.85%	54 +0% -1.85%	0%

site-editor

Metric	9356b73	trunk	% Change
serverResponse	232.39 ms +6.69% -4.4%	239.45 ms +1.25% -0.66%	-2.95%
firstPaint	161.68 ms +3.13% -9.22%	152.54 ms +13.47% -8.29%	5.99%
domContentLoaded	730.24 ms +4.23% -2.03%	725.67 ms +1.18% -0.64%	0.63%
loaded	731.06 ms +4.23% -2.01%	726.51 ms +1.16% -0.63%	0.63%
firstContentfulPaint	320.52 ms +3.89% -1.31%	321.58 ms +2.44% -2.16%	-0.33%
firstBlock	2666.06 ms +0.61% -0.74%	2622.88 ms +1.31% -0.43%	1.65%
type	13.16 ms +1.37% -2.13%	12.98 ms +2.16% -2.85%	1.39%
navigate	63.62 ms +19.32% -3.95%	91.32 ms +4.08% -2.86%	-30.33%
loadPatterns	1027.35 ms +4.74% -10.98%	914.27 ms +11.01% -9.71%	12.37%
loadPages	1011.34 ms +1.54% -4.1%	1036.04 ms +2.8% -9.07%	-2.38%
wpTotal	225.85 ms +7.02% -4.37%	233.14 ms +1.31% -0.68%	-3.13%
wpMemoryUsage	12.56 MB +0% -0%	12.44 MB +0% -0%	0.99%
wpDbQueries	44 +0% -2.27%	44 +0% -2.27%	0%

_{b8873c4 Run}

[oandregal]

We are removing this entry we added in the previous PR, and the changelog ci job for wp-build is complaining. But this is the right move, we don't need an extra entry here. The CI job is optional, so I'd skip that.

[oandregal]

This is working great and aligns with how fields work as well.