Category: Development

Got a call from a client last week. They have a custom plugin for managing special events, built years ago. It started simple. Now, it’s a total nightmare. The original developer is long gone, and every time they try to add a small feature, something else breaks. They wanted to add a new ticketing tier, and suddenly the discount codes stopped working. That’s the kind of mess that lands on my desk.

The core of the problem wasn’t a single bug, but the plugin’s entire structure. It was a classic example of procedural code that had grown into a beast. If you’re a WordPress developer who feels like you’re constantly fighting your own code on complex projects, it’s time we talked about WordPress object-oriented programming. It’s the step up you’ve 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 the natural limit of procedural programming. You write code as a series of steps. Get users, loop through them, check a condition, return a result. It works great for simple tasks. But when complexity grows, you end up with a web of functions that are hard to manage, reuse, or debug. Just wrapping those functions inside a `class` doesn’t fix it. You’re 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,” rather than a sequence of steps. A great example of an OOP concept is already in WordPress core: the hooks and filters system. As explained in a foundational post over at carlalexander.ca, the hook system is a Mediator pattern. It lets different parts of the code talk to each other without being directly tied together. Your plugin can `add_filter` without knowing or caring what the theme or other plugins are doing. That’s decoupling. But its implementation relies 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`. Nothing outside this object can mess with it directly. It’s self-contained. This is the real power of OOP: creating reliable, predictable, and reusable components that don’t break when you look at them the wrong way.

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’re building a plugin that you know will need to grow and adapt, starting with an object-oriented structure is the only professional way to do it. It forces you to think about how your code is organized, making it more maintainable for you and anyone who comes after you.

• It keeps your code organized: Grouping related properties and methods in a class makes your code’s purpose 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.

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.

Are you still writing procedural PHP, or have you made the jump to OOP? What was the “aha!” moment for you?

Got a call from a client last week. Smart guy, running a solid blog, and he’s decided it’s time to get serious about building an audience. He wants to launch a product down the line, so he needs a mailing list. Someone told him to use a ‘popular’ marketing plugin to add a signup form to his site. Now, his admin dashboard is crawling and his PageSpeed scores are in the toilet. A total mess.

This is a classic problem. You need one simple thing—a form to capture an email—and you end up installing a monolithic plugin that brings in a dozen CSS files, a mountain of JavaScript, and adds five new tables to your database. It’s overkill, and it’s lazy. This kind of bloated solution is the core of so many WordPress performance issues. My job was to rip it out and build a proper, lightweight WordPress mailing list integration.

The Obvious Fix That’s Still Wrong

My first thought, the quick-and-dirty fix, was to just grab the raw HTML embed code from their ConvertKit account. You’ve seen them. Just paste it into a Custom HTML block and call it a day. And yeah, it works… for a minute. But it’s a terrible approach. You’re loading external styles you can’t control, the validation is all client-side, and it just feels fragile. Plus, it’s not a “WordPress” way of doing things. It’s a hack. I was reminded of this whole ‘building an audience’ challenge from a post over at carlalexander.ca, and it got me thinking about the right way to solve this for clients.

You lose all control. You can’t easily add honeypot fields, you can’t tie it into other WordPress hooks, and you’re at the mercy of a third-party service for your form’s performance and appearance. Not good. The real fix had to be at the integration level, not just slapping a bandage on the front-end.

Building a Simple Endpoint for True Integration

Instead of that mess, the right way is to use the provider’s API. All the big players—ConvertKit, Mailchimp, you name it—have a REST API. This means we can build our own form, style it perfectly with the site’s theme, and then just send the data to a custom endpoint that handles the submission on the back-end. All you need is an API key.

Here’s the kicker: it’s not even that much code. We can create a simple WordPress REST API endpoint to handle the AJAX request from our form. It’s clean, secure, and infinitely more professional.

add_action('rest_api_init', function () {
    register_rest_route('my-agency/v1', '/subscribe', [
        'methods'  => 'POST',
        'callback' => 'handle_subscription_form',
        'permission_callback' => '__return_true' // In production, you'd want a nonce here.
    ]);
});

function handle_subscription_form($request) {
    $email = sanitize_email($request['email']);
    if (!is_email($email)) {
        return new WP_Error('bad_email', 'Invalid email address.', ['status' => 400]);
    }

    $api_key = 'YOUR_CONVERTKIT_API_KEY';
    $form_id = 'YOUR_FORM_ID';
    $api_url = "https://api.convertkit.com/v3/forms/{$form_id}/subscribe";

    $response = wp_remote_post($api_url, [
        'headers' => ['Content-Type' => 'application/json; charset=utf-8'],
        'body'    => json_encode([
            'api_key' => $api_key,
            'email'   => $email,
        ]),
    ]);

    if (is_wp_error($response)) {
        return new WP_Error('api_error', 'Something went wrong.', ['status' => 500]);
    }

    return new WP_REST_Response(['message' => 'Success! Check your email.'], 200);
}

So, What’s the Point?

The point is to think like a developer, not a marketer who just clicks “install plugin.” Don’t solve a simple problem with a giant, complicated tool. A few lines of code gave the client exactly what they needed and nothing more:

• A form that perfectly matches their theme.
• Zero impact on site performance. No extra CSS or JS files loading everywhere.
• Full control over the submission process, error handling, and user feedback.

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

It takes an extra hour of dev time upfront, but it saves you from countless hours of performance headaches later. Trust me on this, it’s the only sane way to do it.

I once took over a WooCommerce project for a client selling complex configurable products. The previous developer had copied and pasted the same pricing logic across half a dozen different template files. The single product page, the cart, the mini-cart, checkout… everywhere. When the client asked for a simple tweak to their discount structure, what should have been a 30-minute job became a day-long, high-risk surgery. That’s the cost of ignoring the DRY principle.

DRY stands for “Don’t Repeat Yourself.” It’s a fundamental rule in software development. Taken literally, it means you shouldn’t have duplicate code. But it’s more than that; it’s a philosophy. It’s about making your code maintainable and sane. When you have the same logic in multiple places, you have multiple points of failure. Fix a bug in one spot? You better hope you remember to fix it in all the others. You probably won’t.

Why “WET” Code Will Drown Your Project

The opposite of DRY is WET—”Write Everything Twice” (or three times, or ten). A WET codebase is a nightmare. In my client’s case, the pricing logic was slightly different on the product page versus the checkout page. Not on purpose. No, a bug was fixed in one place and not the other, leading to confused customers and lost sales. That’s the kicker. This stuff has real financial consequences.

My first thought, and the trap many junior devs fall into, was to just do a project-wide find-and-replace for the logic. Quick and dirty, right? Wrong. That’s how you create even more problems. You might accidentally replace something you shouldn’t or miss a variation. Trust me on this, a band-aid on a broken leg doesn’t work. The only real fix was to refactor.

// The only way to fix the mess was to centralize the logic.
// Now, any change to pricing happens in ONE place.

function get_my_complex_product_price( $product_id ) {
    $product = wc_get_product( $product_id );
    if ( ! $product ) {
        return 0;
    }

    $price = $product->get_price();

    // ...
    // All the custom logic, special conditions, and discount rules live here.
    // And only here.
    // ...

    return apply_filters( 'my_custom_price', $price, $product );
}

I created one function that became the single source of truth for that pricing logic. Every template file that needed the price now calls that one function. The code is cleaner, the risk of regressions is almost zero, and the next time the client wants a pricing change, it’ll actually be a 30-minute job. This isn’t some new-fangled idea; it’s a core concept that developers have been talking about for years, and Carl Alexander even wrote a great piece on it over at his blog, which you can find at https://carlalexander.ca/harnessing-superpower-dry/.

So, What’s the Point?

The point is that writing code is only the first step. Writing maintainable code is the job. The DRY principle isn’t just about showing off how clever you are. It’s about respecting the next person who has to touch your code—which is often your future self. More importantly, it’s about building a stable, reliable foundation for your client’s business so that a small change doesn’t turn into a five-alarm fire.

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.

Got a call from a client last week. One of our junior devs had been tasked with a “simple” job: create a custom landing page at /welcome/ for a new campaign. But the page was throwing a 404. Total dead end. The client was getting anxious. The dev was stumped. They swore the page existed, the template was there, but WordPress just wouldn’t see it. This, my friends, is a classic case of getting tangled in the WordPress Rewrite API.

The Rewrite API is WordPress’s internal translator. It’s the magic that turns a pretty URL like /my-awesome-post/ into a query that WordPress understands, like ?p=123. Without it, we’d all be stuck with ugly URLs. But when you introduce custom rules, things can get messy. Fast.

The Obvious Fix That Makes Things Worse

My first thought was the usual suspect. “Did you flush the rewrite rules?” I asked. Of course, he had. He even showed me the code. He had hooked a function into init to add the new rule for the /welcome/ page, and to be “safe,” he added a call to flush_rewrite_rules() right after it. And that’s the kicker. I could feel the site groaning from here. He was regenerating the entire URL routing table on every single page load.

This is a total nightmare for performance. flush_rewrite_rules() is an expensive operation. It writes to the database and can even modify the .htaccess file. Running it on every request is like rebuilding your house every time you want to open a window. It “works,” but it’ll bring even a powerful server to its knees. This was my vulnerability—I’d made the same mistake years ago on a high-traffic site and almost took it down during a product launch. Trust me on this, you only learn that lesson once.

Flushing Rewrite Rules the Right Way

The rule itself was fine. The problem was the flushing strategy. You don’t need to flush rules all the time. You only need to do it once when the rules change. That’s it. On plugin activation, deactivation, or when a specific setting that affects URLs is changed.

The reliable way to handle this is with a database flag. You add your rewrite rules on init every time—that’s correct, because they need to be registered with WordPress on every load. But you only trigger the flush when you need it. This approach, which builds on a great concept I saw over at carlalexander.ca, is rock-solid.

// 1. Add your rule on every page load so WordPress knows about it
function my_custom_rewrite_rule() {
    add_rewrite_rule('^welcome/?$', 'index.php?pagename=welcome-page', 'top');
}
add_action('init', 'my_custom_rewrite_rule');

// 2. Set a flag when your plugin is activated
function my_plugin_activate() {
    add_option('my_plugin_flush_rewrite_rules', true);
}
register_activation_hook(__FILE__, 'my_plugin_activate');

// 3. Check for the flag, flush the rules ONCE, then delete the flag
function my_plugin_flush_rules_on_load() {
    if (get_option('my_plugin_flush_rewrite_rules')) {
        flush_rewrite_rules();
        delete_option('my_plugin_flush_rewrite_rules');
    }
}
add_action('init', 'my_plugin_flush_rules_on_load');

So, What’s the Real Takeaway?

The WordPress Rewrite API is powerful, but it demands respect. It’s not just about writing the right regex. It’s about understanding the performance implications of your actions. The key lesson is to separate rule registration from rule flushing.

• Register your rules on every page load using the init hook.
• Flush your rules only when they change. Use an activation hook or a settings-save callback to set a one-time flag.

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.

Get this right, and you’ll build robust, performant features. Get it wrong, and you’ll be wondering why your server is on fire. Simple as that.

Got a call a few weeks back. A new client, frustrated. Their WooCommerce dashboard was timing out constantly. Just loading the main admin screen took ages. They were convinced they needed a bigger server, but a quick look told me the problem wasn’t the hardware. It was a custom dashboard widget, meant to show low-stock products, that was bringing the whole system to its knees. This is a classic case of pragmatic WordPress development being ignored for something far more complex, and far worse.

The previous developer, who was clearly a smart person, had built an entire custom framework for this one widget. I’m talking custom database tables, a bespoke REST API endpoint to serve the data, and a slew of classes trying to follow SOLID principles to the letter. It was the kind of thing you’d read about in a software architecture textbook, an idea I’ve seen discussed on sites like Carl Alexander’s blog. But in a WordPress context? Total nightmare. It was a solution in search of a problem.

My First Commit Was a Mistake

And here’s the kicker: my first instinct was to try and fix it. That was my vulnerability. I dove into their code, thinking, “I’ll just optimize the queries on their custom tables. Maybe add some caching to their API endpoint.” I spent a solid two hours trying to untangle the mess. It was a fool’s errand. The entire foundation was wrong. Every line of code I wrote was just adding complexity to an already bloated system. It was a classic case of premature optimization creating more problems than it solved.

Sometimes, the best code you can write is the code you delete. The truly pragmatic solution wasn’t to fix the over-engineered mess. It was to get rid of it. Completely.

Replacing 1,000 Lines with 10

So that’s what I did. I deleted the custom tables, the custom endpoint, all of it. Then, I replaced the entire thing with a simple function that hooks into the WordPress dashboard and uses a built-in WooCommerce function. It leans on the core systems WordPress and WooCommerce already provide. Trust me on this, it’s almost always the right call.

add_action('wp_dashboard_setup', 'add_low_stock_dashboard_widget');

function add_low_stock_dashboard_widget() {
    wp_add_dashboard_widget(
        'low_stock_products_widget',
        'Products Low on Stock',
        'display_low_stock_products'
    );
}

function display_low_stock_products() {
    $args = array(
        'post_type'      => 'product',
        'posts_per_page' => 10,
        'meta_query'     => array(
            'relation' => 'AND',
            array(
                'key'     => '_manage_stock',
                'value'   => 'yes',
            ),
            array(
                'key'     => '_stock',
                'value'   => 5, // Or your low stock threshold
                'compare' => '<=',
                'type'    => 'NUMERIC',
            ),
        ),
    );

    $low_stock_query = new WP_Query($args);

    if ($low_stock_query->have_posts()) {
        echo '<ul>';
        while ($low_stock_query->have_posts()) {
            $low_stock_query->the_post();
            echo '<li><a href="' . get_edit_post_link() . '">' . get_the_title() . ' (' . get_post_meta(get_the_ID(), '_stock', true) . ' left)</a></li>';
        }
        echo '</ul>';
        wp_reset_postdata();
    } else {
        echo 'All products are sufficiently stocked.';
    }
}

So, What’s the Real Takeaway?

The lesson here isn’t that design patterns are bad. It’s that context is king. WordPress has its own way of doing things, its own APIs, and its own performance considerations. Fighting against the framework instead of using it is a recipe for disaster. The most elegant solution is often the simplest one that leverages the tools you’re already given. Don’t build a tractor when you just need to turn a screw.

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.