Someone recently posted on LinkedIn about a client site that broke after a theme update. The reason? All the custom code had been added directly to the parent theme. The theme updated, the code disappeared, and the site broke.
It’s a common story, and the advice that followed was solid: never edit the parent theme. But one of the suggested alternatives — using a code snippets plugin — is something we’d push back on.
The Problem with Code Snippets Plugins
Code snippet plugins store PHP code in the WordPress database. That sounds convenient, but it introduces problems that aren’t obvious until something goes wrong.
There is no agreed way to encode special characters. PHP code stored in a database field has to survive serialisation, character encoding, and database collation. What you paste in is not always what gets executed. A curly quote that sneaked in from a copy-paste, an ampersand in a string, a backslash that gets escaped twice — these are the kinds of bugs that waste hours because the code looks correct in the editor.
AI agents make this worse, not better. If you’re using AI tools to generate or modify code — and increasingly, developers are — the code passes through even more layers of encoding before it lands in your snippet. The more transformations between the code you write and the code that runs, the more opportunities for silent corruption.
Snippets are invisible to future developers. When a new developer inherits a site, they look in predictable places: the theme, the plugins folder, the mu-plugins directory. Nobody’s first instinct is to check a snippets plugin for business-critical logic. Code that can’t be found might as well not exist — until it breaks something and nobody knows where to look.
Why a Custom Plugin Is Almost Always Better
A custom plugin takes five minutes longer to set up than a snippet, but it pays that back many times over.
It serves as documentation. A plugin sitting in the plugins list is a visible signal that someone has customised this site. A snippet buried in a database table is not.
It’s harder to accidentally delete. Deactivating a plugin is a deliberate action. Deleting a snippet — or losing it during a database migration — is surprisingly easy. And because plugins have distinct names, the chance of someone else’s work overwriting yours is effectively zero.
It tells you who wrote it and why. A plugin has a header with an author name, a description, and a version number. That’s metadata you get for free, and it answers the questions that matter most when something goes wrong: who built this, what does it do, and how do I get in touch with them?
It’s version-controllable. A plugin lives on the filesystem, which means it can be tracked in Git, deployed through a pipeline, and diffed when something changes. Database-stored code can’t do any of that without extra tooling.
What About the Child Theme?
Adding custom code to a child theme’s functions.php is better than editing the parent theme — your code will survive theme updates. But it has its own limitations.
A child theme’s functions.php tends to become a dumping ground. Six months in, it’s 400 lines of unrelated functions: a custom post type, a WooCommerce filter, a login redirect, and a snippet that removes the admin bar for subscribers. None of these things are related to the theme, and bundling them together makes the site harder to maintain.
If the code is about how the site looks, the child theme is the right place. If it’s about how the site behaves, a custom plugin is cleaner.
The Five-Minute Plugin
Creating a custom plugin is simpler than most people think. A single PHP file in wp-content/plugins/ with a standard plugin header is all it takes:
<?php
/**
* Plugin Name: Client Name - Custom Functionality
* Description: Site-specific customisations for clientname.co.nz
* Author: Your Agency Name
* Version: 1.0.0
*/
// Your custom code goes hereThat’s it. It appears in the plugins list, it can be activated and deactivated independently, and anyone who works on the site next will know exactly where to find it.
The Bottom Line
Where you put your custom code matters as much as what the code does. Parent themes will overwrite it. Snippet plugins will bury it in the database. Child themes will let it survive, but they’ll mix it in with everything else.
A custom plugin keeps your code visible, portable, and maintainable. It takes five minutes to set up and saves hours of confusion down the line. For any site you expect to maintain beyond next week, it’s the right choice.
