A year ago someone added a purchase order field to your checkout. They found the code on a blog, the instructions said to paste it at the bottom of your theme’s functions.php file, and it worked.
Today the field is gone. Nobody touched it. The theme updated.
Themes replace their own files
When a theme updates, its files are overwritten with the new versions from whoever built it. Anything added to functions.php goes with them.
A child theme avoids that particular problem, because updating the parent theme doesn’t touch the child’s files. Plenty of tutorials skip that detail and tell you to edit whatever theme is active.
Theme switches are quieter
A redesign brings a new theme, and the new theme has its own functions.php. Everything the old one was doing stops.
Nothing announces it. You find out when a customer asks where a field went, or when an order comes through missing information you’ve been collecting for two years.
One bad character takes down the whole site
functions.php runs on every page load, front end and admin. A missing semicolon can break the public site and lock you out of the dashboard at the same time.
WordPress has a recovery mode that catches most of these and emails you a link to get back in with the theme paused.1 When that doesn’t work, the fix involves editing files directly on the server, which isn’t something you can do from a browser.
The built-in editor makes it easier to get here
Appearance > Theme File Editor writes straight to the live site. There’s no staging step, no undo, and no record of what the file looked like before you clicked the button.
WordPress does run a safety check on the active theme and reverts an edit that crashes the site.2 That catches the worst case. It does nothing about an edit that works today and breaks something else in November.
If you have a developer, ask them to turn the editor off. It’s one line in a configuration file, and it stops anyone from changing code on a live site through a browser.
What belongs where
Anything about how the site looks belongs to the theme. Anything about what the site does belongs somewhere else.
The test is whether it should survive a theme switch. A checkout field should. So should a shipping rule, a custom post type, a redirect, or a connection to another system.
Layout, colors, and template changes are appearance. Those stay in a child theme, where they belong.
If you don’t have a developer, use a snippets plugin
Code Snippets and WPCode are both good answers for site owners. You install them like any other plugin, paste the code into a form, and give it a name.
The snippets survive theme updates and theme switches. Each one can be switched off on its own if it starts causing trouble, and WPCode refuses to activate code that throws an error instead of taking the site down with it.3
Both plugins store your code in the database rather than in a file.45 That’s fine in one direction. A developer copying the site to work locally pulls the database down along with the files, so the snippets come with it.
Going the other way is where it gets awkward. Deploying a change normally pushes files and leaves the live database alone, since that database holds your orders and content. A snippet written or fixed locally has to be exported and imported by hand.
There’s also no history. Nobody can look up who changed a snippet, when they changed it, or what it said before.
Write a real description on every snippet: what it does, why it exists, and the date. That note is the difference between a developer deleting a mystery block of code and understanding why it’s there.
If you do have a developer, ask for a site plugin
A plugin is a folder with a PHP file in it, and a comment at the top of that file telling WordPress what it is. Nothing more complicated than that.
wp-content/plugins/acme-site-functionality/acme-site-functionality.php
<?php
/**
* Plugin Name: Acme Site Functionality
* Description: Custom functionality for this site.
* Version: 1.0.0
*/
defined('ABSPATH') or die;
One plugin holds everything custom about the site. You don’t need a separate plugin for every snippet, and you shouldn’t have one. Activate it and it survives theme updates, theme switches, and redesigns, and it can be switched off in one click if something goes wrong.
Ask where the code lives
A plugin file keeps the code from disappearing. It still doesn’t tell anyone what changed and when, which is the other half of the problem.
That’s what a Git repository is for. Every change gets recorded with a date, the person who made it, and a note about why. When the site starts throwing errors on a Thursday, someone can look at what shipped Wednesday and undo it.
It’s reasonable to expect that from anyone you pay to write code for your site. It’s also reasonable to ask where the repository is and to have access to it, because that code belongs to you.
For any custom code on your site, there are two questions worth being able to answer: where does it live, and what is it for. If nobody can answer either one, it’s going to vanish eventually and nobody will know what used to be there.
Make WordPress Core, “Fatal Error Recovery Mode in 5.2,” April 16, 2019. ↩︎
WordPress Developer Resources, “wp_edit_theme_plugin_file().” ↩︎
WPCode, “PHP Error Handling and Safe Mode.” ↩︎
Code Snippets, “Database Structure.” ↩︎
WordPress.org Support Forums, “Where does WPCode store my snippets?.” ↩︎
