A child theme inherits everything from a parent theme and only defines what it needs to override or add. In practice, it’s a folder with a handful of files where your actual design decisions live.
The alternative — editing the parent theme directly — is a bad idea because parent themes get updated, and updates overwrite your changes. A child theme sits alongside the parent and survives updates intact.
The one line that makes it a child theme
In style.css, there’s a comment block at the top that WordPress reads as the theme’s metadata. The critical line is:
Template: twentytwentyfive
That’s it. That one line tells WordPress which theme to inherit from. Everything the parent theme defines is now available to the child by default.
What’s in the theme
twenty-twenty-five-child-caleb/
├── style.css — theme declaration and the Template line
├── theme.json — colours, typography, fonts, layout widths
├── assets/fonts/ — four Outfit font files (.woff2)
├── parts/
│ ├── header.html — the sticky header template
│ └── footer.html — the footer template
└── templates/
├── page.html — standard page layout
└── page-no-title.html — page layout without a visible title
theme.json as a design system
theme.json is where the design decisions live as structured data rather than CSS rules. For this site that means:
- A colour palette (eight named colours with their hex values)
- The Outfit typeface across four weights
- Heading styles for h1 through h6
- Body typography settings
- Layout widths (how wide the content column is, and the “wide” breakout width)
Having these values in a file means they’re version-controlled, readable, and portable. Change the primary colour in theme.json and it updates everywhere the colour is used throughout the site.
The font discovery
When I first extracted the child theme, the font file references in theme.json looked like this:
"src": "https://calebwhitefield.co.uk/wp-content/uploads/fonts/filename.woff2"These are hardcoded to the live server.
Import the theme anywhere else and the fonts could fail to load, because the browser would look for them at a domain that either doesn’t exist locally or isn’t serving them. Even if the live server is active, it’s not necessarily accessible because of CORS restrictions.
The simple fix is a relative path format that WordPress’s block theme system supports:
"src": "file:./assets/fonts/filename.woff2"
The file: prefix tells WordPress to look for the font relative to the theme directory. The font files live in assets/fonts/ inside the theme folder, so they travel with the theme wherever it goes. No domain, no dependency.
Styles in code, not the database
One of the more interesting discoveries in this process: the WordPress Site Editor saves design decisions — colours, typography, spacing — as a record in the database.
That record is tied to the theme it was created for.
Move to a different environment, import a different database, or switch themes, and those saved styles may or may not come with it.
The layout widths for this site (how wide the main content column is, how wide the “breakout” sections can be) were stored in the database rather than in theme.json.
The local copy was falling back to Twenty Twenty-Five’s defaults — a noticeably narrower layout — because the database record hadn’t been included.
Moving those values into theme.json means they’re part of the theme code, not the database.
Now they go wherever the theme files go, and they’re visible and editable in a text editor rather than buried in a database table.
Part of a series — back to the overview
Leave a Reply