[jorgefilipecosta]

Part of #83537.

Right now the actions registerPostTypeSchema() registers for each post type ("Rename", "Duplicate", "Trash", …) are imported from @wordpress/fields and bundled into the editor script. To register actions in the server, as the fields API does, each core action needs to live in a script module the server can point to.

This PR moves the core actions into script modules, without changing which actions a post type gets:

• Adds the @wordpress/core-actions package with one script module per collection: post_type_supports (the 10 actions every post type can get), wp_block (duplicate-pattern and export-pattern) and wp_template_part (duplicate-template-part). The default export of each module maps the id of each action to the action.
• Moves the 13 actions there from @wordpress/fields. The moved files only change their import paths, and duplicate-post and order-pages use the Action type of @wordpress/dataviews instead of a local one.
• Makes registerPostTypeSchema() import the modules a post type needs with literal import()s, started while the post type, the permissions and the theme resolve, and register the same actions under the same conditions. A module that fails to load is reported with console.warn and skipped, so the post type still gets its fields and the actions of the other modules.
• Removes the actions from @wordpress/fields, with their deletePostWithNotices() helper and the @wordpress/api-fetch and client-zip dependencies. getItemTitle(), which the fields use, moves to the utilities of the fields.
• Moves the form to create a template part (CreateTemplatePartModal and CreateTemplatePartModalContents) from @wordpress/fields to the private APIs of @wordpress/patterns. The duplicate-template-part action takes it from there instead of keeping a copy, and so do the "Add Template Part" menu of the site editor, the "Create template part" block option and the template parts list of the extensible site editor. Its classes change from fields-create-template-part-modal* to patterns-create-template-part-modal*.
• Makes the script registration of @wordpress/build register the module_dependencies of each script's asset file, as WordPress does for its own scripts. Until now the plugin ignored them, so wp-editor kept the list WordPress registered for it, and the new modules never reached the import map.
• Resolves the @wordpress/core-actions subpaths to their sources in the unit tests, since packages are not built before the tests run and Vite resolves literal import()s while transforming the editor store.

Some notes:

• The registered actions are identical to trunk. On wp-env I compared, for the 12 post types of the site, the ids, labels, flags and modals of the 94 registered actions and their eligibility for 41 posts, before and after this change.
• Removing the actions and CreateTemplatePartModal from @wordpress/fields is a breaking change for its npm users, listed in its changelog. The package has no wp.fields global, so nothing changes for plugins using the WordPress scripts.
• The editor script is 10 kB smaller (gzipped), and the patterns script 1.91 kB bigger, since it now holds the form to create a template part. The modules are fetched when a post type is registered: the templates list and the post editor only fetch post_type_supports (6.42 kB), the patterns list fetches the three.
• The modules keep their own copies of the few pieces @wordpress/fields still uses: getItemTitle(), hasActionLink() and the post types. Importing them from @wordpress/fields would bundle that package into the modules.
• reset-post and delete-post stay in post_type_supports, because registerPostTypeSchema() registers them for every post type today and each one checks which posts it applies to.
• The moved files keep their @wordpress/components usages, and their ESLint suppressions with them. I considered migrating them to @wordpress/ui here, but that changes their UI, so I opted to move them as they are.
• Translations are not solved yet, which is why this is a draft. The strings of the actions now live in the modules, and nothing loads translations for them: WordPress prints translations only for enqueued script modules and their dependencies, not for the dynamic module dependencies of a classic script, and the plugin's load_script_translation_file filter only maps wp-* script handles to the gutenberg- language pack files. Strings other scripts share ("Cancel", "Save", "Delete", …) stay translated, but the ones only the actions use ("Rename…", "Trash…", "Order…", "Export as JSON", the notices, …) would show in English. The fields API modules will have the same problem, so I think it needs a core change (printing the translations of the module dependencies of classic scripts) with a compat layer here, plus mapping the plugin's script modules to its language packs.

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. Go to http://localhost:8888/wp-admin/site-editor.php?p=%2Fpage, 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.
4. 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.
5. Go to http://localhost:8888/wp-admin/site-editor.php?p=%2Fpattern&postType=wp_template_part&categoryId=all-parts. Duplicate a template part, verify the modal shows the name and the area options, and delete the copy.
6. On the same page, create a template part with "Add Pattern" > "Add Template Part", and another one with "Create template part" in the options of a block while editing a template. Verify the form looks as on trunk, and delete both template parts.
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.
9. Verify the import map of these pages lists the three @wordpress/core-actions/* modules, and that the network panel only shows the modules each page needs.
10. Enable the "Extensible Site Editor" experiment and repeat steps 3 to 7 in http://localhost:8888/wp-admin/admin.php?page=site-editor-v2, where the template parts list has an "Add Template Part" button.

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: +6.11 kB (+0.07%)

Total Size: 8.85 MB

📦 View Changed

Filename	Size	Change
build/modules/core-actions/post_type_supports.min.js	6.42 kB	+6.42 kB (new file)	🆕
build/modules/core-actions/wp_block.min.js	6.43 kB	+6.43 kB (new file)	🆕
build/modules/core-actions/wp_template_part.min.js	1.29 kB	+1.29 kB (new file)	🆕
build/scripts/edit-site/index.min.js	397 kB	+15 B (0%)
build/scripts/editor/index.min.js	610 kB	-9.37 kB (-1.51%)
build/scripts/patterns/index.min.js	14.3 kB	+1.93 kB (+15.65%)	⚠️
build/scripts/private-apis/index.min.js	1.16 kB	+4 B (+0.35%)
build/styles/edit-site/style-rtl.css	21.6 kB	-282 B (-1.29%)
build/styles/edit-site/style-rtl.min.css	17.6 kB	-263 B (-1.47%)
build/styles/edit-site/style.css	21.6 kB	-280 B (-1.28%)
build/styles/edit-site/style.min.css	17.6 kB	-261 B (-1.46%)
build/styles/editor/style-rtl.css	32.3 kB	-350 B (-1.07%)
build/styles/editor/style-rtl.min.css	27.5 kB	-240 B (-0.87%)
build/styles/editor/style.css	32.3 kB	-343 B (-1.05%)
build/styles/editor/style.min.css	27.4 kB	-237 B (-0.86%)
build/styles/patterns/style-rtl.css	2.08 kB	+419 B (+25.23%)	🚨
build/styles/patterns/style-rtl.min.css	1.11 kB	+405 B (+57.28%)	🆘
build/styles/patterns/style.css	2.08 kB	+418 B (+25.15%)	🚨
build/styles/patterns/style.min.css	1.11 kB	+408 B (+57.95%)	🆘

_{ce810f2 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	6b450ec	trunk	% Change
timeToFirstByte	52 ms +9.04% -1.44%	52.4 ms +18.23% -2.39%	-0.76%
largestContentfulPaint	88 ms +9.09% -4.55%	88 ms +9.09% -4.55%	0%
lcpMinusTtfb	34.5 ms +25.07% -5.07%	32.85 ms +8.37% -3.04%	5.02%
wpBeforeTemplate	27.49 ms +8.22% -0.62%	27.67 ms +13.44% -1.41%	-0.65%
wpTemplate	20.56 ms +4.72% -2.43%	21.1 ms +6.54% -5.12%	-2.56%
wpTotal	48.38 ms +9.36% -1.53%	48.6 ms +18.02% -2.22%	-0.45%
wpMemoryUsage	7.62 MB +0% -0%	7.58 MB +0% -0%	0.48%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	6b450ec	trunk	% Change
timeToFirstByte	45.45 ms +4.84% -2.42%	44.6 ms +4.04% -1.68%	1.91%
largestContentfulPaint	100 ms +2% -4%	96 ms +6.25% -0%	4.17%
lcpMinusTtfb	53.65 ms +3.26% -2.89%	52.4 ms +4.68% -1.53%	2.39%
wpBeforeTemplate	25.7 ms +8.91% -1.52%	25.85 ms +1.2% -1.04%	-0.58%
wpTemplate	15.99 ms +3.69% -2.06%	15.56 ms +3.79% -1.09%	2.76%
wpTotal	42.31 ms +5.32% -2.27%	41.55 ms +4.48% -1.4%	1.83%
wpMemoryUsage	6.28 MB +0% -0%	6.24 MB +0% -0%	0.6%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	6b450ec	trunk	% Change
mediaProcessingJpeg	400.93 ms +0.26% -0.37%	402.69 ms +0.59% -0.32%	-0.44%
mediaProcessingAvif	6081.26 ms +0.09% -0.13%	6040.08 ms +0.1% -0.07%	0.68%
mediaProcessingJpegToAvif	4174.27 ms +0.17% -0.02%	4171.28 ms +0.08% -0.25%	0.07%

media-upload

Metric	6b450ec	trunk	% Change
jpegUploadProcessing	1425.96 ms +37.85% -0.97%	1412.98 ms +0.91% -0.5%	0.92%
pngUploadProcessing	206.9 ms +2.63% -15.95%	206.33 ms +7.27% -16.8%	0.28%
largeJpegUploadProcessing	1412.66 ms +0.84% -0.3%	1406.65 ms +0.51% -0.51%	0.43%
multipleImageUploadProcessing	1549.57 ms +0.81% -1.23%	1550.46 ms +0.65% -0.51%	-0.06%

post-editor

Metric	6b450ec	trunk	% Change
serverResponse	399.68 ms +5.54% -6.5%	388.46 ms +8.05% -2.96%	2.89%
firstPaint	451.71 ms +7.61% -24.3%	351.82 ms +30.02% -24.24%	28.39%
domContentLoaded	1076.59 ms +2.55% -2.16%	1085.03 ms +1.43% -2.86%	-0.78%
loaded	1077.97 ms +2.54% -2.18%	1086.34 ms +1.41% -2.86%	-0.77%
firstContentfulPaint	479.25 ms +1.43% -1.99%	465.93 ms +1.13% -2.01%	2.86%
firstBlock	3199.38 ms +1.47% -0.27%	3162.31 ms +1.66% -0.45%	1.17%
type	17.07 ms +2.11% -0.64%	17.11 ms +2.22% -5.84%	-0.23%
typeWithoutInspector	17.04 ms +4.05% -4.4%	16.55 ms +2.78% -2.72%	2.96%
typeWithTopToolbar	22.94 ms +5.49% -3.71%	21.7 ms +6.31% -4.42%	5.71%
typeContainer	9 ms +3.11% -6.44%	8.04 ms +7.96% -2.86%	11.94%
focus	122.79 ms +3.06% -2.45%	113.55 ms +1.52% -7.84%	8.14%
firstFocus	237.83 ms +0% -0%	217.19 ms +0% -0%	9.5%
selectAll	533.75 ms +1.69% -4.39%	514.05 ms +0.96% -2%	3.83%
listViewOpen	78.72 ms +6.38% -3.86%	76.75 ms +7.3% -4.25%	2.57%
inserterOpen	41.04 ms +11.53% -6.68%	39.98 ms +7.03% -5.65%	2.65%
inserterHover	13.32 ms +8.33% -10.21%	12.93 ms +7.27% -12.37%	3.02%
inserterSearch	9.53 ms +10.6% -8.08%	8.59 ms +6.29% -2.79%	10.94%
loadPatterns	699.31 ms +3.7% -0.97%	653.28 ms +5.05% -6.77%	7.05%
wpTotal	390.23 ms +5.67% -6.66%	379.09 ms +8.22% -3.06%	2.94%
wpMemoryUsage	13.42 MB +0% -0%	13.38 MB +0% -0%	0.29%
wpDbQueries	54 +0% -1.85%	54 +0% -1.85%	0%

site-editor

Metric	6b450ec	trunk	% Change
serverResponse	317.92 ms +0.69% -2.84%	310.77 ms +2.14% -8.12%	2.3%
firstPaint	212.94 ms +16.81% -9.01%	212.27 ms +26.09% -15.33%	0.32%
domContentLoaded	967.23 ms +0.91% -2.83%	932.4 ms +0.71% -2.67%	3.74%
loaded	968.04 ms +0.91% -2.83%	933.14 ms +0.74% -2.66%	3.74%
firstContentfulPaint	414.84 ms +8.88% -3.49%	394.96 ms +3.32% -6.19%	5.03%
firstBlock	3531.73 ms +1.16% -1.23%	3453.23 ms +0.59% -0.91%	2.27%
type	15.35 ms +2.87% -2.8%	15.13 ms +3.77% -1.45%	1.45%
navigate	99.49 ms +5.95% -6.45%	90.64 ms +14.13% -2.86%	9.76%
loadPatterns	1207.69 ms +5.92% -11.86%	1234.42 ms +3.18% -11.53%	-2.17%
loadPages	1081.96 ms +0.99% -2.63%	1062.66 ms +1.41% -4.08%	1.82%
wpTotal	309.44 ms +0.72% -2.92%	302.48 ms +2.1% -8.42%	2.3%
wpMemoryUsage	12.48 MB +0% -0%	12.44 MB +0% -0%	0.31%
wpDbQueries	43 +2.33% -0%	43.5 +1.15% -1.15%	-1.15%

_{ce810f2 Run}

[jorgefilipecosta]

Some notes on why I think removing the actions from @wordpress/fields is safe:

• WordPress does not expose them to plugins. @wordpress/fields has no wpScript, so there is no wp.fields global. A plugin using the actions bundles its own copy from npm, and that copy keeps working.
• At runtime, plugins reach the actions through the entity actions registry, which still has the same actions with the same ids, so unregisterEntityAction() and the core.registerPostTypeSchema hook keep working.
• For npm consumers it is a breaking change, listed in the changelog. The package is 0.x, so it ships in a minor (0.50.0) that a ^0.49.0 range does not install; it only reaches someone upgrading on purpose.

I searched GitHub for imports of these actions from @wordpress/fields. Besides copies of Gutenberg and its handbook, I only found OmniForm, which uses 5 of them on ^0.41.1, so nothing changes for it until it upgrades.

After the removal, I tested all the actions again on wp-env (site editor, extensible site editor and editor inspector), and the registered actions are the ones the new modules export.

[oandregal]

I see what you did here. In some ways this is actually easier to review than my approach. As discussed, I still worry about the reverts, but your reasoning is sound and we need to take the plunge at some point.

[jorgefilipecosta]

Hi @oandregal, thank you for the review! Yes, I understand a revert would be bigger this way. I think it is still worth it, keeping the actions in two places could easily create divergences while both copies exist, and at least the whole move happens in this PR 👍