I got a call from a new client. Their WooCommerce checkout page was throwing a fatal error, but only sometimes, a real ghost in the machine. They’d paid another developer to add a custom fee based on the payment gateway, and it worked for a week before things started falling apart.
After about ten minutes of digging, I found the problem. A twenty-line function in functions.php, copied straight from some tutorial blog. The dev who put it there knew how to write code, or at least how to copy and paste it. What he didn’t know was how to read code, and that was the whole problem.
The Stack Overflow trap: you’re just gluing parts together
We’ve all been there. You hit a problem, you Google it, and you find a snippet that looks right. You paste it in and the problem goes away. Ship it. The trouble is you’re just practicing your Google-fu. You’re not getting better at solving problems, you’re getting better at finding parts other people built.
My first instinct with this client’s site was to delete the function and write it properly myself. But I stopped. Instead of writing a single line, I spent the next 20 minutes reading the WooCommerce core files for the cart and checkout process. I wanted to see the architecture, the hooks, and the filters, and to understand the context of the problem. It’s a step worth taking.
The surprising part was that the original function was mostly right. The logic was basically sound, but it was hooked into woocommerce_cart_calculate_fees, which runs too early and didn’t have access to all the session data it needed. The fix wasn’t a full rewrite. It was moving the logic to a later hook and adding one conditional check.
// The WRONG way - hooked in too early
add_action( 'woocommerce_cart_calculate_fees', 'legacy_custom_gateway_fee' );
function legacy_custom_gateway_fee( $cart ) {
// This might fail because the chosen gateway isn't set yet
$chosen_gateway = WC()->session->get( 'chosen_payment_method' );
if ( $chosen_gateway == 'custom_gateway' ) {
$cart->add_fee( 'Custom Fee', 15 );
}
}
// The RIGHT way - found by reading core code
add_action( 'woocommerce_review_order_before_payment', 'correct_custom_gateway_fee' );
function correct_custom_gateway_fee() {
// This hook runs later, ensuring session data is available
$chosen_gateway = WC()->session->get( 'chosen_payment_method' );
if ( $chosen_gateway == 'custom_gateway' ) {
// Logic to add fee would be different here, maybe via JS or another hook
// The point is: the CONTEXT is correct.
}
}So what’s the actual fix?
Stop focusing only on writing code and start reading it, a lot of it. You’ll start to see patterns and build a mental map of how a complex system like WordPress or WooCommerce actually works. This idea builds on something I first read about on carlalexander.ca, and it’s one of the most important shifts a junior or mid-level developer can make.
- Next time you use
WP_Query, don’t just use it. Find the class in the WordPress core files and read through the constructor to see how it builds the SQL. - When a plugin breaks, don’t just deactivate it. Open the files and trace the function that’s throwing the error, and work out what it was trying to do.
- Look at how popular plugins like ACF or Gravity Forms structure their code. You’ll learn more from that than from ten blog tutorials.
Seniority isn’t about knowing every function. It’s about understanding the system well enough to know where to find the answer. And the answer is always in the code itself.
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.
