Quick answer: A WordPress child theme inherits templates and options from a parent theme while storing your CSS and template overrides in a separate folder. Use one when you customise a third-party or shared parent and still want parent updates. Skip a child theme when you built the parent yourself and deploy it from version control as your own product. Never edit parent theme files directly on a site you expect to update.
Why parent edits are a trap
You install a theme, change style.css or a template inside it, then click Update when a security release appears. WordPress replaces the theme folder. Your edits vanish. A child theme keeps custom code outside that replaceable folder.
This pattern is standard WordPress practice and pairs with how the template hierarchy chooses files: a copy in the child wins over the parent for that template name.
When you need a child theme
Use a child theme if:
- You customise a theme from WordPress.org or a commercial shop
- You only need CSS tweaks, a few template overrides or
functions.phpsnippets - You want one-click parent updates
Consider skipping a classic child setup if:
- You develop a custom WordPress theme as the site’s product and ship updates yourself
- You use a carefully managed starter theme workflow with your own git releases
- Full site editing and block theme practices on newer WordPress versions change where customisations live (still verify update safety on your version)
Page builders complicate things: some store layouts in the database, not PHP templates. You may still want a child theme for CSS and hooks even when layouts are in the builder.
What a minimal child theme contains
At minimum:
- A folder like
wp-content/themes/mytheme-child/ style.csswith header fields pointing at the parentfunctions.phpthat enqueues the parent and child styles correctly
Optional:
- Template overrides (
single.php,header.php, copies of parent files you change) - Extra assets
Example style header fields (conceptual):
- Theme Name: My Theme Child
- Template: parent-folder-name
The Template line must match the parent folder name exactly.
Enqueue styles the modern way
Older tutorials told people to @import the parent CSS. Prefer wp_enqueue_style in the child functions.php so load order and dependencies stay correct. Enqueue the parent handle first, then the child stylesheet.
Test with caching plugins off, then on. Purge caches after switching themes.
Overrides without copying the whole theme
Copy only the templates you change. If you duplicate every parent file “just in case,” you inherit bugs and lose upstream fixes for files you never meant to customise.
Prefer hooks and filters in functions.php when the parent offers them. Template copies are for markup changes you cannot achieve with hooks.
Deep custom work often overlaps WordPress theme development skills: knowing which file the hierarchy loads matters more than memorising snippets.
Customizer, menus and theme mods
Menus, Customizer settings and widgets belong to the theme slug in many cases. When you activate a child, you may need to reassign menus or re-import Customizer settings. Plan a short checklist after activation. The WordPress Customizer remains a common options UI on classic themes in 2020.
Page templates in children
You can add page templates in the child for landing layouts while leaving the parent alone. Name them clearly so editors pick the right one.
Deployment and environments
Keep the child in git. Deploy child and parent versions together. On multisite, network-enable carefully and test per site. See WordPress Multisite when many sites share parents.
Never give Editors FTP access to “tweak” parent files. That is how drift returns.
Troubleshooting checklist
- White screen after activation: check PHP errors in the child
functions.php - Styles missing: enqueue order or wrong parent handle
- Template change ignored: wrong file name vs hierarchy, or page builder takeover
- Parent update broke something: compare changelog; your override may rely on removed functions
Use a staging site for parent updates when the child has many overrides.
Child theme vs plugin for features
Put features that must survive a redesign in a plugin (CPTs, shortcodes, integrations). Put presentation overrides in the child. Mixing business logic into the child theme makes future theme swaps painful.
Example child style.css header
/*
Theme Name: Example Child
Template: example-parent
*/
Then enqueue in functions.php. Keep PHP snippets small and commented with the ticket number that requested them so future developers know what can be deleted.
When to fold a child back into a custom parent
If the child overrides most templates, you are maintaining a fork. Plan a proper custom theme or a controlled upgrade path instead of endless overrides that fight every parent release.
Collaboration with designers
Designers often hand over CSS that was built against the parent. Map their selectors to the child stylesheet and delete unused rules. Large leftover CSS files from the parent copy-paste era slow editing and confuse audits.
Document which templates the child overrides in a short README inside the theme folder. Future you will not remember why header.php was copied in 2019.
Security updates
Parent theme security releases still matter. Apply them on staging, run through critical templates the child overrides and then deploy. Child themes do not isolate you from vulnerable parent PHP that still loads.
Build tools
Some teams compile child Sass into CSS in CI. That is fine if the compiled CSS is what WordPress enqueues and source maps do not ship to production. Keep the parent untouched so updates remain a folder replace.
Naming and packaging
Use a clear child folder name (brand-child) and keep the parent name visible in the theme selector. Zip both themes for handoff to another developer with a one-page note on overrides. Orphans without notes become archaeology projects.
If you use a commercial parent with a built-in “child theme generator,” still review the generated enqueue code. Generators sometimes rely on outdated @import patterns you should replace.
Multisite note
On Multisite, network admins sometimes drop a parent into the shared themes folder and let each site run its own child. That works well when brand CSS differs per site. Keep parent versions aligned across the network so you are not patching three parent releases at once.
FAQ
Can I use two parent themes?
No. A child has one parent. Switch parents only with a planned redesign.
Do I need a child theme for CSS only?
Additional CSS in Customizer can work for tiny tweaks. Larger CSS and any PHP belongs in a child (or a custom plugin) so it is portable and reviewable.
Will a child theme slow my site?
Negligibly if you enqueue cleanly. Bloated copied templates and huge CSS will, regardless of child vs parent.
Is it safe to update the parent always?
Usually yes, that is the point. Still test on staging when you override many templates.
Protect custom work the simple way
A WordPress child theme is cheap insurance: parent updates stay possible, your CSS and template changes stay put. Create the child before you customise, keep it in version control and override only what you must. If you want help structuring themes for safer long-term maintenance, see Turn visitors into customers.
