A client called last week. They have a custom plugin for managing special events that was built years ago. It started out simple, and now it is a total nightmare. The original developer is long gone, and every time they try to add a small feature, something else breaks. They wanted a new ticketing tier, and suddenly the discount codes stopped working. That is the kind of mess that lands on my desk.
The real problem wasn’t one bug, it was the plugin’s whole structure. This was procedural code that had grown into a beast. If you are a WordPress developer who feels like you are always fighting your own code on complex projects, it is worth talking about WordPress object-oriented programming. It is the step up you have been avoiding.
When good intentions create spaghetti code
When I first opened up the client’s plugin, I found a handful of PHP files, each packed with dozens of functions. My initial thought was to just isolate the broken discount function. “Should be a quick fix,” I told myself. But as I started tracing the logic, I saw the problem. The function relied on a bunch of global variables, and its logic was tangled up with three other functions in another file. Changing one thing had unpredictable consequences. The code was too tightly coupled. Sound familiar?
This is where procedural programming hits its limit. You write code as a series of steps: get users, loop through them, check a condition, return a result. That is fine for simple tasks. Once complexity grows, though, you end up with a web of functions that are hard to manage, reuse, or debug. Wrapping those functions inside a class doesn’t fix it. You are just putting disorganized functions into a box.
Thinking in objects, not just files
Object-oriented programming (OOP) is about managing that complexity. It organizes code around concepts, or “objects,” instead of a straight sequence of steps. One example of an OOP idea already lives in WordPress core: the hooks and filters system. A foundational post over at carlalexander.ca explains that the hook system is a Mediator pattern. It lets different parts of the code talk to each other without being wired directly together. Your plugin can add_filter without knowing or caring what the theme or other plugins are doing. That’s decoupling. Its implementation does lean on a global variable, $wp_filter, which isn’t ideal.
A true object-oriented approach would encapsulate that logic, protecting it from outside interference. Imagine if the filter system was a class:
class Hook_Manager {
private $hooks = [];
public function add( $tag, $function, $priority = 10 ) {
// Logic to add the function to the private $hooks array
$this->hooks[$tag][$priority][] = $function;
}
public function apply( $tag, $value ) {
if ( ! isset( $this->hooks[$tag] ) ) {
return $value;
}
// Logic to loop through hooks and apply them
foreach ( $this->hooks[$tag] as $priority => $functions ) {
foreach ( $functions as $function ) {
$value = call_user_func( $function, $value );
}
}
return $value;
}
}
// $my_hooks = new Hook_Manager();
// $my_hooks->add('my_custom_filter', 'my_callback');
// $data = $my_hooks->apply('my_custom_filter', 'some_data');See the difference? The $hooks array is private, so nothing outside this object can touch it directly. It is self-contained. That is what OOP buys you: components that are reliable and reusable, and that don’t break the moment you look at them sideways.
So, what’s the point?
The goal isn’t to use OOP for everything. A simple function in your theme’s functions.php is fine. But if you are building a plugin that you know will need to grow and change, an object-oriented structure is the right way to start. It pushes you to think about how the code is organized, which keeps it maintainable for you and for whoever comes after you.
- It keeps your code organized: grouping related properties and methods in a class makes the purpose of your code clear.
- It prevents conflicts: Encapsulation avoids polluting the global namespace and reduces unintended side effects.
- It makes your life easier: Well-structured objects are far easier to debug and reuse in other projects.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, get in touch with my team. We have probably seen it before.
Are you still writing procedural PHP, or have you made the jump to OOP? What was the “aha!” moment for you?
