How to Customize an Old WordPress Theme with a Child Theme

The problem with editing theme files directly

Almost everyone does it once. You open the theme editor, change a colour in style.css or add a line to header.php, the site looks right, and you move on. Months later the theme updates, or you reinstall it to fix something else, and the change is gone. WordPress replaces the theme folder as a whole, so anything you added inside it goes with the old files.

With an actively maintained theme that is an annoyance. With an older theme it is worse, because there may be no updates at all to worry about, only the day you move to a new server and copy the files back from a stale backup. A child theme solves both situations with the same trick: your changes live in a separate folder that WordPress never overwrites.

What a child theme actually is

A child theme is a small folder inside wp-content/themes/ that points at a parent theme. WordPress loads the parent first and then lets the child override pieces of it. In the smallest version the child contains just two files: a style.css with a header comment, and a functions.php.

The header comment in the child’s style.css needs a theme name and a Template: line. The value of Template: must be the exact folder name of the parent theme, in lower case if that is how the folder is named. A typo here is the most common reason a new child theme refuses to appear under Appearance → Themes.

Step 1: Create the folder and the stylesheet

Create a folder next to the parent, for example arras-child, and put a style.css in it that starts with the header comment. Below the comment you write only your own rules. You do not copy the parent’s stylesheet. The child’s rules are meant to be a short list of overrides, and keeping it short makes it easy to see later what you changed and why.

Step 2: Load the parent’s styles

Older tutorials tell you to use @import inside the child stylesheet. It works, but it makes the browser fetch the files one after another, and the better method is to enqueue both stylesheets from functions.php with wp_enqueue_style().

There is one thing to check before you copy a snippet from the web. Some themes, Arras among them, keep their real CSS in a subfolder such as assets/styles/css/ and enqueue it from their own code instead of relying on the root style.css. If you only enqueue the parent’s root file, the page can come out unstyled. Open the parent’s functions.php, find how it registers its styles, and make the child load things in an order that matches. View the page source and make sure every stylesheet you expect answers with a normal page load and not a 404.

Step 3: Override a template file

This is where a child theme earns its place. If you copy a template file, for example single.php, from the parent into the child folder with the same name and path, WordPress uses your copy instead of the original. Edit the copy and leave the parent untouched.

• Copy only the files you actually change. Every copied file is one more file you have to compare by hand if the parent ever changes.
• Keep the relative path. A file at parent/templates/content.php must sit at child/templates/content.php to be picked up.
• functions.php is the exception: the child’s file does not replace the parent’s, it runs in addition to it, just before. Do not copy the parent’s version into it.

Step 4: Put your own PHP in functions.php, carefully

Small additions such as a new image size, a changed excerpt length or an extra widget area belong in the child’s functions.php. Watch the function names. If your function has the same name as one in the parent, PHP stops with a fatal error and the site shows a blank page. Prefix everything with something unique, such as the child theme’s name. Also make sure the file begins with <?php and has no stray characters or blank lines before it, since those can break headers and feeds.

Where translations fit

If you translate a theme, the language files are another thing a parent update can wipe. Storing them in wp-content/languages/themes/ keeps them outside both folders, and the child theme can still load its own text domain for any strings you add. The details of that workflow are in our walkthrough on translating a theme with Poedit.

Why this matters more for an unmaintained theme

When the original developer slows down, as is the case with Arras (see The End — Mostly.), you inherit the job of keeping the theme working across new PHP and WordPress versions. A child theme gives you a clean place to put those fixes. If a community fork or a new release of the parent does appear, you switch the parent, check your handful of overrides, and delete the ones that are no longer needed.

A short checklist before you go live

• Test on a copy of the site first, or at least take a backup of the theme folder and the database.
• Activate the child theme and compare the front page, a single post, an archive and the search page with the parent. Missing sidebar or broken menus usually mean a template file was copied from the wrong place.
• Check that widgets and menu locations are still assigned. Theme settings and widget placements are stored per theme, so after switching to the child you may have to assign them again, or copy the customizer settings across.
• Keep a note in the child’s style.css or in a README listing every file you overrode and what you changed in it. Six months from now it will be the only documentation you have.

None of this takes more than half an hour on a small site, and it is the difference between a customization you can trust and one that quietly disappears the next time the files are replaced.

Photo: Close-up of a computer keyboard, Wikimedia Commons, CC0.