| [ Index ] |
PHP Cross Reference of WordPress Trunk (Updated Daily) |
[Source view] [Print] [Project Stats]
Entity actions API. An action definition is the serializable subset of the DataViews Action API: every property that is plain data (`id`, `label`, `isPrimary`, `supportsBulk`, `context`, `modalHeader`, …). Properties that are JavaScript callbacks, components, or elements (`callback`, `RenderModal`, `isEligible`, `icon`, a `label` that depends on the items, …) cannot be declared here. They are provided by a script module registered for the entity along with its actions: its default export maps action ids to the properties of each action that are JavaScript. An entity can have several modules. Each module applies to the actions it was registered with, see {@see wp_get_registered_entity_action_modules()}.
| File Size: | 218 lines (9 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| wp_register_entity_actions( $origin, $kind, $name, $actions, $script_module = null ) X-Ref |
| Registers actions for an entity, see {@see WP_Entity_Actions_Registry::register()}. It only runs on the `wp_entity_actions_api_init` action. param: string $origin Who registers the actions: `core`, or param: string $kind The entity kind (e.g. `postType`). param: string $name The entity name (e.g. `page`). param: array[] $actions The list of action definitions, each with an `id`. param: string|null $script_module The id of the script module providing return: string[] The ids of the actions registered, in the order of the |
| wp_unregister_entity_actions( $kind, $name, $ids = null ) X-Ref |
| Unregisters actions of an entity, see {@see WP_Entity_Actions_Registry::unregister()}. It only runs on the `wp_entity_actions_api_init` action. param: string $kind The entity kind (e.g. `postType`). param: string $name The entity name (e.g. `page`). param: string[]|null $ids The ids of the actions to unregister. Default return: array[] The list of the definitions unregistered, in |
| wp_get_registered_entity_actions( $kind, $name ) X-Ref |
| Returns the actions registered for the given entity. param: string $kind The entity kind (e.g. `postType`). param: string $name The entity name (e.g. `page`). return: array[] The list of registered action definitions, in |
| wp_get_registered_entity_action_modules( $kind, $name ) X-Ref |
| Returns the ids of the script modules registered for the given entity. param: string $kind The entity kind (e.g. `postType`). param: string $name The entity name (e.g. `page`). return: array<string, string[]> The ids of the actions each module |
| wp_get_all_registered_entity_action_modules() X-Ref |
| Returns the ids of all script modules registered for any entity. return: array<string, array<string, string[]>> The lists of module ids, |
| _wp_add_entity_action_modules_to_editor_script( $scripts = null ) X-Ref |
| Declares the script modules of the entity actions as dependencies of the editor script. The editor imports the script modules of an entity on demand, with a dynamic `import()` the browser resolves through the import map of the page. Listing the modules as dynamic `module_dependencies` of the `wp-editor` script adds them to the import map of every page that loads the editor script: the post editor, the site editor, and the pages booted by `@wordpress/boot`, whose prerequisites depend on it. A dynamic dependency is only listed in the import map; the module is fetched when it is imported. Reading the registry fires `wp_entity_actions_api_init`, so the actions and their script modules are registered on demand. It only reads the registry on the pages that load the editor script, not on every admin request (heartbeat, Ajax, other screens). It runs on `admin_footer`, the last action before the import map is printed that fires both in the admin template and in the pages rendered outside it, which print the import map themselves. By then `init` has completed, so the post types and supports the actions derive from are final. The registry only accepts registrations while the action fires, so the modules declared here are the modules of every action the page can show. The `admin_footer` action passes it no argument, so the global registry is used. In other scenarios (tests), the scripts are given directly. param: WP_Scripts|null $scripts The scripts registry. Defaults to the global one. |
| _wp_preload_entity_actions( $paths, $context ) X-Ref |
| Preloads the actions of the post type the post editor edits. The actions menu of the post editor reads them from the `wp/v2/entity-actions` route as it loads, see `useEntityActions()` in packages/editor/src/dataviews/entity-actions-loader.ts. The path must match the request of the `getEntityActionsConfig` core data resolver, see packages/core-data/src/resolvers.js. param: array $paths REST API paths to preload. param: WP_Block_Editor_Context $context Block editor context. return: array Filtered preload paths. |
| Generated : Tue Oct 20 08:20:34 2026 | Cross-referenced by PHPXref |