Improve Your WordPress Code

As we progress in our development careers, we regularly need to learn new things. Sometimes when learn how to do something, we consider it solved, and we stop learning. It happens to everybody at some point. Let’s see how we might improve your WordPress code.

Don’t write unnecessary code

The actions and filters within WordPress make it easy to customize your website. Part of that customization, is disabling functionality you don’t want. You can unregister an action with remove_action, unregister a filter with remove_filter, or you can alter the content of a filter by resetting it.

For example, people often want to prevent their WordPress version from being known. To do so, we need to modify the generator meta tag in the page head. To remove it, we’ll use the filter ‘the_generator’ to remove the version.

myplugin_remove_the_generator () {
    return '';
}

add_filter( 'the_generator', 'myplugin_remove_the_generator' );

Code like this is very common, and it works. However, it also unnecessary. We don’t need to create a new function. You can accomplish the same thing with less code. WordPress provides a number of simple utility functions for situations like this. In this case, the __return_empty_string function is up to the task.

add_filter( 'the_generator', '__return_empty_string' );

Here’s a list of these utility functions for this type of problem.

__return_null
__return_true
__return_false
__return_zero
__return_empty_array
__return_empty_string

Use Default Constants

Some things are universal. File size measurements and time are two such things. WordPress provides constants for both of them. Here are the constants for time.

MINUTE_IN_SECONDS
HOUR_IN_SECONDS
DAY_IN_SECONDS
WEEK_IN_SECONDS
MONTH_IN_SECONDS
YEAR_IN_SECONDS

By using these constants you’ll increase the readability of your code.

// It works, but meh
$weekdays = 5 * (24 * 60 * 60);

// Much better
$weeksdays = 5 * DAY_IN_SECONDS;

We can make similar improvement when dealing with filesize values.

KB_IN_BYTES // 1,024
MB_IN_BYTES // 1,048,576 
GB_IN_BYTES // 1,073,741,824
TB_IN_BYTES // 1,099,511,627,776

These constants simplify the use of filesize information. Look at this example

// it works, but uses magic numbers
$eight_mb = 8 * (1024 * 1024);

// much better
$eight_mb = 8 * MB_IN_BYTES;

Separate Objects From Actions

As more WordPress developers learn object-oriented programming, they naturallly want to use it in their plugins and themes. The procedural way in WordPress is to add a function to an action looks like the following:

function myplugin_hello_world() {
    echo "<h1>Hello World</h1>";
}

add_action( 'wp_footer', 'myplugin_hello_world' );

If this function were to be rewritten as a method in a class – How would we register it with add_action? We would need to call add_action like so:

add_action( 'wp_footer', array( 'Myplugin_Hello_World', 'say_hello' ) );

In this example, the class method must be defined as static. What is a static method?

Declaring class properties or methods as static makes them accessible without needing an instantiation of the class.

— PHP.net manual

A static method is easy to call. That makes it usefeul for simple things, but you aren’t really taking advantage of the power of OOP. Instead, the class is used as little more than a namespace. Also, static methods makes testing more difficult.

function myplugin_hello_world() {
    echo "<h1>Hello World</h1>";
}

 add_action( 'wp_footer', 'myplugin_hello_world' );

A better way to write your code, is to write it independently of your framework or CMS. In this case, that’s WordPress. Instead of writing a function to do the work directly, write your function to act as a thin wrapper to create any objects you need, and return a value if necessary. This allows you to write your classes normally – like you would for any other system.

function myplugin_wp_footer() {
    $hello_world = new Hello_World();

    echo $hello_world->say_hello();
}

add_action( 'wp_footer', 'myplugin_wp_footer' );

Separate Actions From Classes

A common mistake that many WordPress developers do, is using constructors to add actions and filters to WordPress. It’s the flip side of the problem just discussed. Why is this a problem? Because you’ve limited the usefullness of this code to work only with WordPress. Now you can’t re-use it. As professional developers, we should be striving to write code that is modular, and re-usable. You work hard on your code. Why wouldn’t you want to be able to re-use it on another project? Here’s an example of what I’m referring to.

class My_Class
{
    public function __construct() {
        add_action( 
            'action_name', 
            array( $this, 'action_method_name' ) 
        );
    }
}

It’s OK. We’ve all made this mistake in the past. Learn from the mistake, and move on. How can we improve your WordPress code? The techinque from the previous section, is also the solution to this problem. Use a thin wrapper function, that we attach to actions or filters, to call our objects.

function foo() {
    $my_class = new My_Class();
    $my_class->action_method_name();
}

add_action( 'wp_foo', 'foo'' );

This will result in code that is more re-usable, and simplify your use of objects.

Wrap Up

Those are just a few ways to improve your WordPress code. There are obviously more technique available, but those are best left for another day. I hope that helps.