The WordPress `static` Keyword: Stop Using It Wrong

I was called in to fix a custom analytics plugin for a client’s site. It was a mess. The original developer had left, and the client wanted a “simple” change: track different events for logged-in users versus guests. The problem was, the entire plugin was built as one giant class with every method declared as `static`. The whole thing was a textbook example of how to misuse the WordPress static keyword.

Every event was tracked with a call like `Analytics_Plugin::track_event(‘page_view’)`. To figure out if a user was logged in, I’d have to litter that `track_event` method with conditional logic. It was already a 200-line monster, and doing this would just make it worse. It’s a classic case of procedural code hiding in a class wrapper.

Why Your Static Methods Are a Ticking Time Bomb

Here’s the kicker. The `static` keyword isn’t the enemy. It has its uses. But in WordPress, developers often use it as a crutch to avoid real object-oriented programming. They create a “Utilities” or “Helpers” class and dump everything in there. This happens because, as a great post over at carlalexander.ca points out, WordPress itself has a long procedural history, making this feel like a natural step.

My first thought was to just hack it. Add a check inside `track_event()` like `if (is_user_logged_in()) { … }`. And yeah, it would have worked. For now. But it’s a terrible fix. It adds complexity to a method that has no business knowing about user state. The real problem is that the method is static. It can’t hold any state on its own, so you end up checking for global state instead. Total nightmare.

A static method should be stateless. It should give you the same output every single time for a given input. It shouldn’t care if a user is logged in, what time it is, or anything else about the current state of the application. When you violate that, you create code that’s impossible to test and a pain to maintain.

<?php
// The better, object-oriented way
class AnalyticsTracker {
    private $is_user_logged_in;

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

    public function track_event(string $event_name) {
        $event_data = ['name' => $event_name];

        if ($this->is_user_logged_in) {
            $event_data['user_id'] = get_current_user_id();
        }

        // Send this data to your analytics service...
        // error_log(print_r($event_data, true));
    }
}

// Now the call is contextual
$tracker = new AnalyticsTracker();
$tracker->track_event('page_view');

So, What’s the Real Fix?

The real fix is to think in objects. Instead of a static class, I refactored it to a proper `AnalyticsTracker` class. When I need to track something, I instantiate it. The constructor checks if the user is logged in and stores that in a private property. Now, the `track_event` method can use that internal state (`$this->is_user_logged_in`) to change its behavior. It’s clean, it’s testable, and it’s not fighting the principles of OOP.

• Static methods are for stateless helpers. Think of a function that just sanitizes a string. It doesn’t need to know anything else. Perfect use for `static`.
• Objects are for managing state. If a method’s behavior needs to change based on conditions like user status, that logic belongs in an object that holds that state.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

Stop treating classes like folders for your functions. Using the WordPress static keyword correctly is less about the keyword itself and more about shifting your mindset from procedural hacks to robust, object-oriented solutions. Trust me on this, your future self will thank you.