A legacy WooCommerce plugin had get_option and update_option calls scattered everywhere, with clashing prefixes resetting settings. The fix was one wrapper class that owns the options table and adds the prefix for you.
A client wanted a shortcode to highlight reader comments, but the inherited code crammed all the HTML into the shortcode function. Moving it into a dedicated generator class and a separate template file keeps the markup out of the PHP.
A custom events plugin where every class built its own dependencies was impossible to test or change. A small DI container built from closures gave one place to wire the objects together, without pulling in a framework.
I got a call from a client last week. Their last developer bailed, and they had a “simple” request: add a new delivery option to…
I inherited a Laravel project a while back. The client wanted a simple change: rename a few database columns for clarity. What should have been…
I got a call from a client running a membership site on a pretty old, third-party plugin. Their problem? They needed to sync a user’s…
Had a client come to me with a WooCommerce store that was starting to choke. They had about 30,000 products, and their admin dashboard, specifically…
A client’s Resources section had meta box code scattered across functions.php and two include files, so every small change broke something. One reusable meta box class moved the registration logic into a constructor and the form HTML into a template.
A junior dev passed a post object where my function wanted an integer, and it failed silently with no error. That is the trap of overly defensive WordPress code, and when you control the environment, failing loudly beats bailing quietly.
A sharp junior dev was stuck on a bug that only showed up on staging, because he was lost without a GUI. The command line is the most direct way to see what a server is doing, and a couple of basic commands found the error in minutes.