I’ve lost count of how many times a client has said “the site broke after we updated the theme” and the culprit was the same thing: custom code sitting in functions.php.
It’s the classic WordPress trap. You need a small tweak — hide something, change a WooCommerce label, add a custom order status — and the quickest path is open the theme’s functions.php, paste a snippet, ship it. Job done. Until the theme updates. Or someone switches to a child theme. Or a page builder “reset”. Or a well-meaning colleague “cleans up” the file.
I’ve been burned by that enough times that I stopped putting client customisations in the theme years ago. These days I reach for the Code Snippets plugin (or a small custom plugin when it’s something I want properly versioned). Same code. Different place to put it. Much less drama when themes move.
What actually goes wrong
Theme updates overwrite functions.php. That’s the big one. Child themes help, but plenty of sites I inherit don’t have one, and even when they do someone has still stuck “just one more thing” in the parent.
There’s also the mess factor. A functions.php that started with two helpers becomes a dumping ground — half-commented experiments, copy-pasted Stack Overflow, three different people’s naming styles. When something breaks at 4pm on a Friday you don’t want to be spelunking through that.
And for WooCommerce work especially, customisations tend to grow. One hook becomes five. Order emails, checkout fields, admin columns. That stuff belongs somewhere you can turn off without hunting.
Why Code Snippets works for me
I add the Code Snippets plugin (or I already have it on care-plan sites) and each change is its own named snippet. I can:
- turn one thing off without touching everything else
- leave a short note in the snippet description about why it exists
- export / copy snippets between similar client sites
- keep the theme as a theme, not a junk drawer
When I’m teaching a client or another developer what’s on a site, a list of named snippets is a lot kinder than “scroll to line 847 of functions.php”.
I’m not precious about the plugin brand. A tiny must-use plugin with the same code is fine for projects I control end-to-end. The point is: don’t marry your custom code to the theme file that will get replaced.
When I still touch functions.php
Almost never for client work. Maybe a throwaway local experiment. Maybe a one-line thing I’m about to move into a snippet. If it’s going to live on a production store, it doesn’t live in the theme.
Wrap Up
If you’ve got WooCommerce tweaks living in functions.php right now, that’s your weekend job: lift them into snippets (or a small plugin), name them, and sleep better next time the theme wants an update.
Have you been bitten by a theme update wiping custom code, or is it just me?
Need a hand?
If you’d rather not dig through an old functions.php yourself, hire me — fixed-price quote, no obligation.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece and chose to publish it. He did not write these words. Augmented publishing by Neil Matthews.