Have you ever found yourself in a situation where you need to pass a custom variable into a WordPress hook callback? If you have worked with the WordPress Hook API, you know that add_filter() and add_action() have a specific signature. By default, they only pass the arguments defined by the hook itself.

For example, the the_content filter passes the post content string. But what if you need to pass a custom configuration variable or a theme setting into your callback function? Attempting to pass a parameter like add_filter('the_content', 'my_content($my_param)') will result in a PHP error because WordPress expects a valid callback name, not a function call.

In this guide, we will explore several professional methods to pass custom parameters to your WordPress hooks, ranging from modern PHP closures to robust Object-Oriented Programming (OOP) patterns.

The Problem: Understanding Hook Limitations

To understand why we need workarounds, we have to look at how WordPress handles hooks. When you call add_filter, you are registering a callback that WordPress will execute later using apply_filters. 

// This will NOT work
function my_content($content, $my_param)
{
    // Do something with $my_param
    return $content;
}

// This triggers an error because 'my_content($my_param)' is not a valid callback string
add_filter('the_content', 'my_content($my_param)', 10, 1);

WordPress only knows how to pass the default arguments (like $content). It doesn't know about your local variable $my_param. To bridge this gap, we need to use techniques that "wrap" our logic and our data together.

Method 1: Using PHP Closures (Anonymous Functions)

Since PHP 5.3, anonymous functions (also known as closures) have become the standard way to solve this problem. Closures allow you to "inherit" variables from the parent scope using the use keyword.

This is the most concise and efficient way to pass parameters. Here is how you can implement it:

$my_param = 'Custom Prefix';

add_filter('the_content', function ($content) use ($my_param) {
    if (is_page()) {
        $content = '<strong>' . $my_param . ':</strong><br>' . $content;
    }
    return $content;
}, 10, 1);

In this example, the $my_param variable is brought into the scope of the anonymous function. When WordPress executes the filter, it passes the $content, but the function already has access to $my_param thanks to the use statement.

Separating Logic for Cleaner Code

If your logic is complex, putting it all inside an anonymous function can make your code messy. A better approach is to use the closure as a lightweight bridge to a named function or a class method:

private function my_plugin_init() {
    $my_param = 'my theme name';

    add_filter('the_content', function ($content) use ($my_param) {
        // The closure simply passes the data to a dedicated method
        return $this->process_content_logic($content, $my_param);
    }, 10, 1);
}

private function process_content_logic($content, $my_param) {
    // Execute complex logic here
    return $my_param . ': ' . $content;
}

Method 2: The OOP Storage Class Approach

While closures are great, they have a significant downside: they are difficult to remove using remove_filter() because the function has no name. If you are building a large-scale plugin where reusability and hook management are priorities, an Object-Oriented approach is superior.

You can create a "Storage" class that holds your custom values and executes the callback via the __call magic method.

/**
 * Stores a value and calls any existing function with this value.
 */
class WPSE_Filter_Storage
{
    private $values;

    public function __construct( $values )
    {
        $this->values = $values;
    }

    public function __call( $callback, $arguments )
    {
        if ( is_callable( $callback ) )
            return call_user_func( $callback, $arguments, $this->values );

        throw new InvalidArgumentException(
            sprintf( 'Not callable: %s', print_r( $callback, TRUE ) )
        );
    }
}

Now, you can use this class to wrap your functions. This allows you to use the same function multiple times with different parameters:

function wpse_add_numbers( $args, $numbers )
{
    $content = $args[0];
    return $content . '<p>Numbers: ' . implode( ', ', $numbers ) . '</p>';
}

// Add filter with one set of data
add_filter(
    'the_content',
    array (
        new WPSE_Filter_Storage( array ( 1, 3, 5 ) ),
        'wpse_add_numbers'
    )
);

// Add filter again with different data
add_filter(
    'the_content',
    array (
        new WPSE_Filter_Storage( array ( 2, 4, 6 ) ),
        'wpse_add_numbers'
    )
);

This method is highly reusable and keeps your global namespace clean.

Example output of multiple filters

Method 3: Function Factories

Another elegant way to pass parameters is to create a function that returns another function. This is often called a "factory" pattern for hooks.

public function create_admin_notice( $message = '')
{
    $class = 'error';
    $output = sprintf('<div class="%s"><p>%s</p></div>', $class, $message);

    // Return the closure
    return function() use ($output) {
        echo $output;
    };
}

// Generate the callback with a specific parameter
$callback = create_admin_notice('Critical System Update Required!');

// Pass the generated callback to the hook
add_action('admin_notices', $callback);

Method 4: The Filter Workaround (State Storage)

If you are working in a strictly procedural environment and want to avoid closures or classes, you can use WordPress's own hook system to "store" a variable temporarily. This is a bit of a workaround but can be effective in specific scenarios.

// 1. "Store" the parameter in a temporary filter
$param = 'My Secret Value';
add_filter( 'temp_storage_param', function() use ( $param ){ return $param; } );

// 2. Hook your actual function
add_filter( 'the_content', 'my_callback_function' );

// 3. Retrieve the param inside the callback
function my_callback_function($content)
{
   // Access the parameter via apply_filters
   $custom_param = apply_filters( 'temp_storage_param', '' );

   return $content . ' ' . $custom_param;
}

Frequently Asked Questions

Can I remove a filter that uses an anonymous function?

It is difficult. Because anonymous functions don't have a name, you cannot simply call remove_filter( 'hook', 'function_name' ). To remove it, you must have access to the specific variable instance of the closure created when the filter was added. If you need to unhook your functions later, the OOP approach is much safer.

Does using closures affect performance?

For most WordPress sites, the performance impact of using closures is negligible. However, if you are adding hundreds of filters inside a tight loop, the overhead of creating many closure objects might be measurable. In those cases, using a single class instance is more efficient.

Which method is best for Gutenberg blocks?

When working with Gutenberg and the REST API, closures are often preferred for their brevity, especially when passing block attributes into a server-side render callback.

Wrapping Up

Passing custom parameters to WordPress hooks is a common requirement that isn't supported out of the box by the add_filter syntax. However, by using PHP Closures, OOP Storage Classes, or Function Factories, you can easily inject the data you need into your callbacks.

Key takeaways: - Use Closures for quick, one-off implementation where you don't need to unhook the function later. - Use OOP Classes for complex plugins where reusability and unit testing are important. - Use Function Factories when you need to generate multiple similar callbacks with different data dynamically.

By mastering these techniques, you'll be able to write more flexible, modular, and professional WordPress code.