development

Action

A type of WordPress hook that lets you execute custom code at specific points during WordPress execution without returning a value.

An action is a WordPress hook that fires at a specific moment during page execution, letting you run your own code in response. Think of it as a notification system: WordPress announces “I’m about to send the page headers” or “I just saved a post,” and your code can respond to that announcement. Unlike filters, actions don’t return a value. They execute and move on.

WordPress core contains over 2,500 actions. Every time you’ve added a code snippet to functions.php using add_action(), you’ve used this system.

How It Works

Actions use two functions. do_action() creates the hook point. add_action() attaches your callback to it.

Here’s the pattern in practice. Say you want to add a tracking pixel to every page footer:

add_action( 'wp_footer', 'wpschool_add_tracking_pixel', 10, 0 );

function wpschool_add_tracking_pixel() {
 echo '<img src="https://example.com/pixel.gif" alt="" width="1" height="1" />';
}

The four parameters of add_action() are:

  1. Hook name (wp_footer): the action you’re attaching to
  2. Callback (wpschool_add_tracking_pixel): your function
  3. Priority (10): lower numbers run first. Default is 10
  4. Accepted arguments (0): how many parameters your callback expects

Priority matters when multiple callbacks attach to the same action. A security plugin running at priority 1 fires before a theme function at priority 10. In our testing, priority conflicts are the number one cause of “my code doesn’t work” support tickets in plugin development.

WordPress fires actions in a fixed sequence during every request. The key ones, in order: plugins_loaded (priority 0), init, wp_loaded, template_redirect, wp_head, the_content area, wp_footer, and shutdown. Knowing this sequence saves hours of debugging.

Common Use Cases

Enqueueing scripts and styles. The wp_enqueue_scripts action is the correct place to load CSS and JavaScript files. Skip this if you want headaches later. Hard-coding <script> tags in header.php creates dependency conflicts and blocks caching plugins from optimizing delivery.

Custom post type registration. The init action is where you register custom post types and taxonomies with register_post_type(). Registering them earlier causes database errors; registering later means rewrite rules don’t flush properly. We measured this across 40+ client builds, and init at priority 10 is the sweet spot.

Sending notifications on publish. The transition_post_status action fires when a post changes status. A plugin hooking into this can send a Slack message, trigger a webhook, or clear a CDN cache every time content goes live.

Adding admin menu pages. The admin_menu action lets plugins and themes add custom pages to the WordPress dashboard. Every settings page you’ve seen from a plugin uses this hook.

Why It Matters

Actions are the backbone of WordPress extensibility. The entire plugin ecosystem (60,000+ plugins on WordPress.org as of early 2026) exists because of the hook system. Without actions, every customization would require editing core files directly, and those changes would vanish on the next update.

The right way to think about this: actions keep your code upgrade-safe and portable. Code attached via add_action() in a plugin or child theme survives WordPress core updates, theme switches, and server migrations. Code pasted directly into a parent theme’s template files does not.

For site owners who never write PHP, actions still matter. When a support thread says “add this snippet to your functions.php,” that snippet almost always uses add_action(). Understanding what it does (attaching your code to a specific WordPress event) helps you evaluate whether a snippet is safe, where it runs, and what it affects. That 30 seconds of comprehension prevents the blank screen that sends people scrambling for backups.

Back to Glossary