WordPress Hooks Explained: Actions and Filters in Plain English

On this page

1. What a hook is
2. Actions: do something at the right moment
3. Filters: change something before it's used
4. Why hooks beat editing core or plugin files
5. Where custom code should live
6. The risks of pasting random snippets
7. What business owners should ask

Ask a WordPress developer how they changed something on your site and you may hear "I used a hook". Hooks are why WordPress can be customised so heavily without anyone editing its core files. Understanding them, even roughly, helps business owners judge whether work has been done properly, and helps junior developers avoid changes that break after updates. Here are actions and filters in plain language, with one tiny example of each.

What a hook is

As WordPress builds a page, it passes through hundreds of named checkpoints: loading plugins, preparing the page header, fetching a post, printing the content, building the footer. At each checkpoint it effectively asks, "Does anyone want to do something here, or change this?"

Those checkpoints are hooks. WordPress core places them, and well-built themes and plugins add their own; WooCommerce, for example, has hooks throughout its product pages, cart, checkout and order emails. Your custom code "hooks in" by telling WordPress which checkpoint to listen for and which function to run when it gets there.

There are two kinds, and the difference is simple:

• Actions let you do something at a particular moment
• Filters let you change a piece of data before WordPress uses it

Actions: do something at the right moment

An action runs your code when something happens: the page head is being printed, a post is saved, a user registers, an order is placed. This action adds a site verification tag to the head of every page:

add_action( 'wp_head', function () {
    echo '<meta name="example-verification" content="your-code-here">';
} );

wp_head is the name of the hook, and the function is what runs when WordPress reaches it. Nothing is handed back; the action simply does its job. Other common actions include init (WordPress has finished loading), wp_enqueue_scripts (the right place to load CSS and JavaScript files), save_post (a post was saved) and woocommerce_thankyou (a customer reached the order confirmation page).

Filters: change something before it's used

A filter receives a value, lets you modify it and expects you to hand it back. This one shortens automatic post excerpts from WordPress's default of 55 words to 30:

add_filter( 'excerpt_length', function ( $length ) {
    return 30;
} );

Filters sit behind many everyday tweaks: changing a button label such as WooCommerce's "Add to cart", adjusting the wording of an email, adding a class to menu items or changing how page titles are built.

The golden rule: a filter must always return a value. If a filter on post content forgets to return anything, posts across the site can appear blank. It's one of the most common mistakes in copied snippets.

	Action	Filter
Purpose	Do something at a moment	Change a value
Added with	add_action()	add_filter()
Must return a value?	No	Yes, always
Business example	Notify the sales team when an order is placed	Change the "Add to cart" button text

Both accept an optional priority number, 10 by default. Lower numbers run earlier, which matters when several plugins hook into the same place.

Why hooks beat editing core or plugin files

The tempting shortcut is to edit a plugin or theme file directly. It works until the next update replaces the file and silently wipes out the change. Editing WordPress core files is worse: updates overwrite them too, and a mistake can affect every page.

Hooks keep your changes in your own file, separate from code you don't control. WordPress, the theme and plugins can all be updated, and your customisation keeps working as long as the hook still exists. Hooks can also undo things: remove_action() and remove_filter() switch off behaviour a theme or plugin adds, without touching its files.

Theme templates follow the same principle: rather than editing the parent theme, a child theme lets you override them safely.

Where custom code should live

Hook code has to go somewhere. There are three sensible homes:

• A child theme's functions.php: for design-related code that belongs to the current theme. It stops running if you switch themes, which is fine for styling tweaks but not for business features.
• A small site-specific plugin: for functionality that should survive a redesign, such as custom post types, WooCommerce rules or integrations. It can be as simple as one PHP file in wp-content/plugins with a short header:

  <?php
  /*
  Plugin Name: Site Functions
  Description: Custom code for this website.
  */

• A code snippets plugin: tools such as Code Snippets or WPCode store small snippets in the database and let you switch each one on or off from the dashboard. Handy for a handful of tweaks, but anyone with admin access can edit them, and they're easy to forget about.

Never put custom code in a parent theme, a third-party plugin or WordPress core. For a fuller decision guide, see plugin or custom code.

The risks of pasting random snippets

Search for almost any WordPress tweak and you'll find a snippet ready to copy. Many are fine. Some are years out of date, written for a different setup, or simply wrong. Common problems:

• Site crashes: one missing bracket, or a function your PHP version no longer supports, can take the site down; see fixing the WordPress critical error
• Security holes: snippets that print data without escaping it, skip permission checks or switch off security features
• Hidden slowdowns: code that runs a heavy database query on every page load
• Conflicts: two snippets, or a snippet and a plugin, doing the same job in different ways
• Mystery code: six months later, nobody remembers what a snippet does or whether it's safe to remove

A safer routine

1. Understand what each line does before adding it, or ask a developer
2. Take a backup and test on a staging copy first; see staging sites explained
3. Keep SFTP or hosting file manager access handy, so a broken snippet can be removed even if the dashboard won't load
4. Add a comment above each snippet: what it does, why, and when it was added
5. Avoid editing PHP through the dashboard's theme file editor, which has no proper version history

What business owners should ask

You don't need to write hooks to manage a developer who does. Ask:

• Were any theme, plugin or core files edited directly? The answer should be no.
• Where does our custom code live, and is it backed up or in version control?
• Is each customisation documented, so another developer could take over?
• Will this keep working after updates, and what should we check if it doesn't?

Need a feature added, or a tangle of old snippets cleaned up? I write hook-based customisations that survive updates as part of WordPress website development, or you can hire a WordPress developer for ongoing work.