After a lot of coding over the past few weeks on cool projects for our WordPress agency, I remembered that I was going to write in detail about how we have built a code structure for the Themes we develop, and how we pay attention to the little, lesser known details of the WordPress codebase.
(If you’re interested in learning all about this in great detail, then drop me a line at firstname.lastname@example.org. We’d be more than happy to give you a quote for some personal coaching.)
How to use WordPress add_action
Whenever PHP code is run in WordPress, there are calls to
do_action scattered liberally through the code of WordPress and the plugins being used. By using an
add_action definition in your own code, you can tell WordPress to run a piece of code you’ve written at the appropriate moment.
For example, you can tell WordPress to load your CSS file when the
wp_enqueue_scripts action is called. When this action is called, your code will be run and the path to the CSS file will be added to the list of other files to be loaded on the website.
add_action('wp_enqueue_scripts', 'sht_register_assets', 10);
wp_enqueue_style('sht-base-style', get_template_directory_uri() . '/assets/styles/ui.min.css', , filemtime(get_template_directory() . '/assets/styles/ui.min.css'));
This code uses the action hook
wp_enqueue_scripts to call the
wp_enqueue_style function at the right moment. (If we run it too early or too late in the process, then WordPress won’t be ready for it, which might lead to errors or to it being ignored.)
As you can see, the
add_action call takes several parameters: the name of the “hook” (or action), the name of your function and the priority at which it should run. (It can also take a fourth parameter for the number of function arguments. More on that in a second…)
The example above is how examples like this appear all over the internet. However, if we check out the documentation of this particular function, we can see that while the action name and the function name are essential, the values for priority has a default value of 10.
This means that we don’t need to pass the priority 10, and our code becomes lighter. Most simple uses for
add_action can use priority 10. In some cases, you might need to use a lower number (which calls your function before those registered at priority 10) or a higher number (which calls it later).
It’s important to note that calling a function using
add_action doesn’t return any data or variable values to the place where it’s called. It simply says “do task X at this point”. To modify data, we need to use
add_filter, which brings me to the next Google-friendly subtitle.
How to use WordPress add_filter
add_filter allows us to take data which WordPress has prepared and modify it. For example, we can extend the list of file types which WordPress will allow us to upload using the
add_filter('upload_mimes', 'sht_upload_mimes', 10, 2);
The code above indicates that we want to modify the data which is passed into the
upload_mimes hook, using our function
sht_upload_mimes. The third parameter is, again, the priority at which our function should be run; the fourth parameter is the number of function arguments which we’ll receive.
Looking at the documentation for the
upload_mimes filter hook, we can see that it will give us two variables: an array of mime types which are already defined, and a variable containing the details of the current user.
function sht_upload_mimes($mime_types, $user)
$mime_types[ 'svg' ] = 'image/svg+xml';
Look at the function closely and you’ll see that we don’t use the variable
$user at all in our code. This means that we don’t need it, so we can tell WordPress through the
add_filter call that we’re not expecting it: we can say that we’re only expecting one function argument, not two. We do this by changing the last parameter.
add_filter('upload_mimes', 'sht_upload_mimes', 10, 1);
The default value of the fourth parameter to
add_filter is 1, so we could shorten this even further. However, this might lead to confusion, so it’s better to define it explicitly.
Clean code is efficient code
By defining the number of arguments in this way, we can increase how accurate our code is. If you’re using a “code sniffer” like PHPCS to adhere to coding guidelines and to flag up warnings and errors in your code, then it may well warn you that you have a pointless variable – in this example
$user – which you should ideally eliminate. By removing it without changing the fourth
add_filter parameter, then WordPress will issue a PHP warning.
This single example will only make a minuscule difference in the performance of your PHP code, but if you have a large amount of code, then it will lead to a proportionate improvement in clarity and performance.