Actions Reference

Fires after the available widgets and sidebars have loaded, before the admin footer.

This action is documented in wp-admin/admin.php

Fires on a non-authenticated admin post request where no action is supplied.

Fires on a non-authenticated admin post request for the given action. The dynamic portion of the hook name, `$action`, refers to the given request action.

Fires on an authenticated admin post request where no action is supplied.

Fires on an authenticated admin post request for the given action. The dynamic portion of the hook name, `$action`, refers to the given request action.

This action is documented in wp-admin/admin.php

Fires authenticated Ajax actions for logged-in users. The dynamic portion of the hook name, `$action`, refers to the name of the Ajax action callback being fired.

Fires non-authenticated Ajax actions for logged-out users. The dynamic portion of the hook name, `$action`, refers to the name of the Ajax action callback being fired.

Fires on the next page load after a successful DB upgrade.

This action is documented in wp-admin/network/upgrade.php

Fires as an admin screen or script is being initialized. Note, this does not just run on user-facing admin screens. It runs on admin-ajax.php and admin-post.php as well. This is roughly analogous to the more general {@see 'init'} hook, which fires earlier.

Fires before a particular screen is loaded. The load- hook fires in a number of contexts. This hook is for plugin screens where a callback is provided when the screen is registered. The dynamic portion of the hook name, `$page_hook`, refers to a mixture of plugin page information including: 1. The page type. If the plugin page is registered as a submenu page, such as for Settings, the page type would be 'settings'. Otherwise the type is 'toplevel'. 2. A separator of '_page_'. 3. The plugin basename minus the file extension. Together, the three parts form the `$page_hook`. Citing the example above, the hook name used would be 'load-settings_page_pluginbasename'.

Used to call the registered callback for a plugin screen. This hook uses a dynamic hook name, `$page_hook`, which refers to a mixture of plugin page information including: 1. The page type. If the plugin page is registered as a submenu page, such as for Settings, the page type would be 'settings'. Otherwise the type is 'toplevel'. 2. A separator of '_page_'. 3. The plugin basename minus the file extension. Together, the three parts form the `$page_hook`. Citing the example above, the hook name used would be 'settings_page_pluginbasename'.

Fires before a particular screen is loaded. The load- hook fires in a number of contexts. This hook is for plugin screens where the file to load is directly included, rather than the use of a function. The dynamic portion of the hook name, `$plugin_page`, refers to the plugin basename.

Fires before an importer screen is loaded. The dynamic portion of the hook name, `$importer`, refers to the importer slug. Possible hook names include: - `load-importer-blogger` - `load-importer-wpcat2tag` - `load-importer-livejournal` - `load-importer-mt` - `load-importer-rss` - `load-importer-tumblr` - `load-importer-wordpress`

Fires before a particular screen is loaded. The load- hook fires in a number of contexts. This hook is for core screens. The dynamic portion of the hook name, `$pagenow`, is a global variable referring to the filename of the current screen, such as 'admin.php', 'post-new.php' etc. A complete hook for the latter would be 'load-post-new.php'.

Fires when an 'action' request variable is sent. The dynamic portion of the hook name, `$action`, refers to the action derived from the `GET` or `POST` request.

Fires when outputting the content of a custom Site Health tab. This action fires right after the Site Health header, and users are still subject to the capability checks for the Site Health page to view any custom tabs and their contents.

Fires after block assets have been enqueued for the editing interface. Call `add_action` on any hook before 'admin_enqueue_scripts'. In the function call you supply, simply use `wp_enqueue_script` and `wp_enqueue_style` to add your functionality to the block editor.

Fires before the page loads on the 'Profile' editing screen. The action only fires if the current user is editing their own profile.

Fires before the page loads on the 'Edit User' screen.

Fires inside the your-profile form tag on the user editing screen.

Fires in the 'Admin Color Scheme' section of the user editing screen. The section is only enabled if a callback is hooked to the action, and if there is more than one defined color scheme for the admin.

Fires at the end of the 'Personal Options' settings table on the user editing screen.

Fires after the 'Personal Options' settings table on the 'Profile' editing screen. The action only fires if the current user is editing their own profile.

Fires in the create Application Passwords form.

Fires after the 'About Yourself' settings table on the 'Profile' editing screen. The action only fires if the current user is editing their own profile.

Fires after the 'About the User' settings table on the 'Edit User' screen.

Fires before the sites list on the My Sites screen.

This action is documented in wp-admin/edit-form-blocks.php

This action is documented in wp-admin/widgets-form.php

This action is documented in wp-admin/widgets-form.php

This action is documented in wp-admin/widgets-form.php

Fires before MagpieRSS is loaded, to optionally replace it.

This action is documented in wp-includes/feed-rss2.php

Fires at end of the Atom feed root to add namespaces.

Fires just before the first Atom feed entry.

Fires at the end of each Atom feed author entry.

Fires at the end of each Atom feed item.

This action is documented in wp-includes/feed-rss2.php

Fires at the end of the feed root to add namespaces.

Fires at the end of the RDF feed header.

Fires at the end of each RDF feed item.

This action is documented in wp-includes/feed-rss2.php