How to use the static keyword with WordPress

This site has a lot of object-oriented programming articles. Most of them focus on solving WordPress problems using object-oriented programming. This is great when you’re comfortable with object-oriented programming.

But most WordPress developers aren’t that comfortable with it. (You’d think there’d be a book on that or something.) It’s one thing to read about basic concepts like encapsulation and inheritance. It’s another to put them in practice. There are a lot of obstacles that you have to overcome.

One of these obstacles is the proper use of the static keyword. Static methods are a great object-oriented tool to use. But, like all good things, we can also abuse it if we’re not careful.

This happens a lot more in the WordPress development world than anywhere else. And there are good reasons for that. We’ll look at why that is and what you can do about it.

What is the static keyword?

The static keyword is a something that you only use with object-oriented programming. You use it when declaring class methods and properties. This allows you to access them without needing to instantiate the class.

Above is a small example demonstrating how the static keyword works. The A_WP_Class has a static actions property and a static get_actions method. And below is how we’d call the get_actions method without instantiating A_WP_Class.

You’ll notice that you can still use visibility keywords with the static keyword. The actions property uses the private keyword. This means that you can’t access it from outside A_WP_Class. You have to use the get_actions method.

And speaking of the get_actions method, you might be wondering what the self does in it. This is the static version of $this pseudo-variable. It’s a shortcut to access static class properties and method for the class that you’re in.

Static variables

It’s worth mentioning that there’s another well-known use for the static keyword: static variables. Unlike static methods and static properties, static variables have nothing to do with object-oriented programming. They’re variables that don’t persist the same way as normal variables.

In normal circumstances, PHP erases variables once it leaves a function or method. But when you define a variable using the static keyword that tells PHP not to erase the variable. The next time that PHP enters that function or method, it will use the value that was there when it left earlier.

The increment function above is pretty much the standard static variable example. We have the counter variable that we defined as static. We echo the current counter variable and then we increment it.

We initialized the counter variable with a value of 0. But what does that mean when you use a static variable? It tells PHP that the first time that it encounters the counter variable to give it the value of 0.

This will only happen the first time that we call the increment function. But after, the counter variable will exist and PHP will use the value stored when it was last in the function. That’s why the following calls to increment don’t echo the initial value of 0, but 1 and 2.

WordPress and the static keyword

But why are WordPress developers that attracted to the static keyword? There are a few factors at play here. And combined they are what makes the static keyword a natural choice for them.

WordPress’s procedural programming legacy

WordPress is an old piece of software. (Especially if you count the b2 years as well!) Back then, PHP didn’t support object-oriented programming that well. Instead of using it, WordPress developers used the procedural programming style. (This made a lot of sense at the time.)

At its core, procedural programming relies on functions working together to solve problems. That’s why WordPress for most of its life WordPress only had functions and didn’t use any classes. And that’s why most WordPress developers still use functions as well.

Namespacing in WordPress

This brings us to the practice of using namespaces in WordPress. This is an important aspect of plugin and theme development. Here’s how the codex describes the practice for WordPress:

All the functions in your Plugin need to have unique names that are different from functions in the WordPress core, other Plugins, and themes. For that reason, it is a good idea to use a unique function name prefix on all of your Plugin’s functions. A far superior possibility is to define your Plugin functions inside a class (which also needs to have a unique name).

The highlighted section is what we want to focus on. Let’s imagine that you’re a WordPress developer who only uses functions in their code. That statement doesn’t tell you to stop doing that. It just tells you to put your functions in a class.

Now, let’s continue to put ourselves in that developer’s shoes. They need to use a class but don’t know object-oriented programming that well or at all. They want to keep using functions like before.

What do they do? They use the static keyword! In their situation, a static method isn’t that different from a regular function. There’s no need to deal with instantiation or any other messy object-oriented stuff. Perfect!

WordPress isn’t object-oriented programming friendly

And why doesn’t that WordPress developer know how to use object-oriented programming that well? It’s because WordPress makes it hard to use it. Most of its APIs like the plugin API don’t translate well to object-oriented programming.

This reinforces the idea that the static keyword is the correct way to go. You’re programming the way WordPress intended you to. But you’re not any closer to using object-oriented programming in a way that makes sense.

How to use the static keyword

Alright, so we have a better idea why WordPress developers use the static keyword. We know that they’re not using it the way that we should. But what’s the correct way of using it?

The role of a static method

To begin, we need to take a look at the static method. So far, we’ve talked a lot about the static keyword. But, in practice, most WordPress developers are using it to create static methods.

We know that a static method (like a static property) doesn’t need an instance of a class to be accessible. This should also define the job of a static method. It should be a job that doesn’t need an instance of a class either.

The sanitize method above is a good example of such a job. We need it to sanitize text for our Post class. That said, it has no need for instances of it.

Everything should be stateless

But we don’t have to stop our description of the job of a static method there. There’s another important quality to good static methods. They’re stateless.

What does stateless mean? It’s a fancy way of saying that the static method never remembers anything. You can call it as often as you want and the result is always the same.

Both the get_actions and sanitize static methods from earlier are examples of stateless static methods. The get_actions static method always return the same array. And the sanitize static method always returns the same value for the same input.

Meanwhile, the Counter class above is an example (another counter example!?) of a class that uses a stateful (it’s the opposite of stateless) static method. You can’t guarantee that the get_count static method will always return the same value. That’s because increment static method increments the counter static property. This changes the state of the Counter class.

Don’t use static properties or variables

This is more or less a natural conclusion to the stateless requirement that we just saw. You should be wary of using static properties or variables. There are uses for them, but they’re not that common.

If you’re using a public static property, you should try to use a constant instead. That said, this isn’t always a valid solution. If you want to keep things private like we did with the actions static property, a constant doesn’t work.

While our initial version of A_WP_Class was stateless, there was no reason to use a private property like we did. We could have just put the actions array as the return value of the get_actions static method like we did above. This would ensure that it always remains stateless.

Moving away from the static keyword

Before we proceed into this section, let’s be clear on something. There’s no magic bullet that you can use to ween yourself off the static keyword. It’s a design problem which means that it varies from situation to situation.

Now, this isn’t a reason to despair. But it won’t be a walk in the park either. With that in mind, let’s look at what you can do to reduce your reliance on the static keyword.

Embrace object-oriented design

With the exception of static variables, the static keyword is an object-oriented programming tool. If you want to use it well, you have to be willing to program in an object-oriented way. This means building classes that are more than just containers for your procedural functions. For that to happen, you need to start designing classes that solve specific WordPress problems.

The plugin API is an example (if not THE example) of a WordPress problem that comes up over and over. We mentioned earlier that it wasn’t object-oriented programming friendly. That’s why you often see WordPress code that uses static methods like this:

Yes, the do_something_on_init static method is inside the A_WP_Class class. But you register it to the init hook outside the class. There’s nothing preventing us from turning the do_something_on_init static method into a regular PHP function.

Learning to make tradeoffs

There are different ways to move away from code like this. You can design the ability to register WordPress hooks into the class itself. Or you can design a system to manage everything.

And those are just the solutions that we’ve explored here. There are others out there as well. And, in the end, you have to pick which one you want to use.

That’s because there’s no perfect solution to this problem or any WordPress problem. Each solution has its tradeoffs. You have to decide which solution fits your situation best.

Focus on the class’s job

Of course, making this transition to object-oriented design is neither quick nor easy. (That’s why this site exists after all!) But there’s a concept that you can use right away to help you with this transition. We call it the single responsibility principle.

The single responsibility is an object-oriented design principle. It’s part of the larger design principle called SOLID. (It’s the “S” in SOLID.) It says that, when you design a class, it should only have one job.

Why is this concept so useful compared to others? It’s because it forces you to think about the job of each class that you create. This is a common struggle when you’re getting started with object-oriented programming.

For example, a class like MyPlugin_Utilities doesn’t have a job. It doesn’t solve a specific WordPress problem. It’s the name that you’d give to a container for procedural functions like is_plugin_active.

Finding good class names

Meanwhile, in the following single responsibility principle article (it’s worth a read!), there are no classes with names like Utilities. Instead, there are classes with names like AdminPage and Shortcode. These class names are much more descriptive.

This reflects the desire to design classes that solve specific problems. Because of that, each class has a job. And you can get a good idea of that it is just from reading its name.

The MyPlugin_Plugin class has a bit of a redundant name. That said, its name is a lot clearer than MyPlugin_Utilities. We have a much better idea of what it represents from an object-oriented perspective.

We can tell that it’s a class that represents the plugin as a whole. In turn, we know that it should contain methods that solve plugin related problems. Such as answering the question “Is MyPlugin active?”. Which is what the is_active static method does.

This helps with the static keyword too

But do we need is_active to be a static method? That’s not always an easy question to answer. (More often than not, the answer is “no”.) That said, this is also something that the single responsibility principle can help you with.

You can use it to determine if you should use the static keyword or not. The trick is to look at it within the context of the job that your class has to do. There are some elements of a class’s job where the keyword makes sense. (For example, interacting with the plugin API.) There are others where it doesn’t.

So does the is_active method need to the static keyword to help the MyPlugin_Plugin class do its job? Well, if its job is to represent the plugin itself, it should track whether it’s active or not. This means that it needs to a way to track that active state.

This is a stateful behaviour. And, like we’ve seen before, a static method should be stateless. This means that is_active shouldn’t be static.

Here’s how the is_active method could look like without the static keyword. We have the active internal variable which tracks whether the plugin is active or not. And the is_active method returns the current value of that variable.

This is a pretty simple example. In practice, the job of a Plugin class can be pretty complicated. That said, you can see how the single responsibility principle can help you with the static keyword.

Use this site as a resource

This last suggestion might seem like a lame plug, but it’s not! We mentioned earlier that you need to embrace object-oriented design to move away from the static keyword. Well, this is one of the main topics covered on this site.

That’s why this article has links to over a dozen articles already. But there are even more for you to read. These are articles are an important resource that you need to leverage.

Most of these articles show you how to solve WordPress problems without using static methods. But some of them also show you the opposite. They teach you about WordPress problems where static methods are the correct tool to use.

It’s a mindset change

There’s no question that moving away from the static method is a challenge. You can’t do it without changing your programming mindset. And that’s never easy for anyone.

That’s why you should see the excessive use of the static keyword as a sign. It’s telling you that your mind still hasn’t made the transition yet. You’re still thinking in a procedural way.

This is nothing to feel ashamed of! (It might even be where you want to be.) But, if your desire is to use less static methods or properties, then your path is clear. You have to move away from procedural programming.

P.S. If you have a static method or property that you don’t know how to remove, feel free to ask how in the comments below. I’ll do my best to help out!

  • “This means building classes that are more than just containers for your procedural functions”

    What would you do about generic utility functions then? Would you just write them as functions so they can be used across several classes? I really like WordPress template tags for things and when I write plugins I like to follow the same grammar (the_thing() get_the_thing(), is_thing()). A lot of times I write the logic within a class and then have a simple function to access the class and do whatever needs to be done. Is there a better way to handle such situations?

    I’ve worked with classes that abstract out things like a WP Post class and custom post types inherit from this WP Post class. After a while it gets messy and confusing since multiple classes are inheriting methods from other classes making it hard to debug or piece together what is coming from where. Its reasons like this that I want to fall back to procedural functions instead. Over abstraction is a beast.

    • I think template tags (and themes) are a different beast entirely. That’s why I haven’t covered them yet. So, in that sense, template tags as you describe them make sense. I wouldn’t stop using functions (not to be confused with static methods here) for that right now.

      In terms of utility functions, it’s really a question of how far down the rabbit hole you want to go. In general, you put utility functions inside the class that uses them. A “sanitize” method would make sense inside the “Post” class for example.

      If you need to reuse these utility methods a lot, then they have a job inside a plugin. Therefore they deserve their own class in my mind. The “sanitize” method would be part of a “Sanitizer” class for example.

      Over abstraction isn’t something you want to aim for. It’s hard for me to diagnose without seeing your code. That said, the way Posts work in WordPress makes this messy a lot of the time. I discuss this a bit here:
      https://carlalexander.ca/saving-wordpress-custom-post-types-using-interface/

  • I found usefull to use static property when I have to add data to it in particulary situation, for example in one of my plugin I use a class with static property for adding some css or js when it’s generated from other classes, you can look at https://github.com/overclokk/italystrap-extended in the core/Asset directory.
    The implementation is:
    Inline_Script::set( ‘add some script’ );
    or
    Inline_Style::set( ‘add some style’ );

    I can call them every time I need to add scripts or style, also in widgets classes, and then I can call:

    Inline_Script::get();
    or
    Inline_Style::get();
    To print the content of the static property in an HTML tag.

    If you have a better way to solve this problem I’m here to learn 🙂

    • I think that in the context of themes and templates it’s a lot trickier to not use procedural programming. I haven’t talked about using object-oriented programming in that context yet.

      That said, I’m not sure I’d use static methods either. I’d be more inclined to use an object who’s job it is to store the inline scripts and styles. I’d then make template tag functions like “italystrap_get_inline_styles()” to generate and print the HTML content using the object.

      • The problem is when I want to print css on ‘wp_head’ but the css is added for example by a method called later than the ‘wp_head’ I can’t add that style, with widget or shortcode you can preregister a css files but this is not a good solution because those files are registered in every page and this is not good for performance reasons.

        • The problem that you describe is going to happen even without the static methods no?

          • The problem happens only without static property.

          • I think I’d need to see a code sample to understand better 🙂

          • I’m sorry, I made a mistake, that class is not for adding data after a hook is called (because it is too late) but it is for storing data and passing it between classes, adding other data from different classes and then print it at some time in the page, for example echo $css on wp_head.
            Some time i need to add small piece of css or js inline in the page from different classes and then I use that class for doing that.
            Maybe I can replace that class with apply_filters and add_filter, I have to try.

  • wpcontent

    I’m confused about this tutorial https://carlalexander.ca/design-system-wordpress-event-management/ where get_subscribed_events() is a static function. Why is that static? Thanks!

    • Good question! get_subscribed_events() is a static method in that context because it’s a stateless property of an EventSubscriber. Each EventSubscriber class subscribes to specific events and those events should never change. Using a static method achieves that purpose.

      • wpcontent

        Thanks for explaining!