A WordPress child theme is a small theme that inherits everything from a parent theme and lets you override only what you change, so updating the parent never erases your work. To create one you need a folder, a style.css with a Template: header naming the parent, and a functions.php that enqueues styles.
That part is in every tutorial. What I want to add is the part most child themes get wrong: they become a pile of hardcoded text, colours and markup that only a developer can change.
How do you create a WordPress child theme?
Create a folder in wp-content/themes/, for example astra-child. Add a style.css with at least a Theme Name and Template header (the parent’s folder name), add a functions.php that loads the stylesheets, then activate the child theme under Appearance → Themes.
style.css
/*
Theme Name: Astra Child
Template: astra
Version: 1.0.0
Text Domain: astra-child
*/
functions.php
<?php
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_style(
'astra-child',
get_stylesheet_uri(),
array(),
wp_get_theme()->get( 'Version' )
);
} );
Whether you also need to enqueue the parent stylesheet depends on how the parent loads its own CSS; many modern parents already do it. Check the page source to avoid loading it twice. Avoid @import in CSS: it delays stylesheet loading.
Versioning the stylesheet with the theme version means browsers fetch the new file after each release, which matters when you use long cache headers (see caching and LCP).
Overriding templates
Copy a template file from the parent into the child with the same relative path, then edit it. WordPress loads the child’s version first. Keep overrides minimal: every copied template is code you now maintain when the parent changes. Prefer hooks and filters when the parent offers them.
The real problem: hardcoding
Here is a pattern I find in many inherited child themes:
<h1>We build fast websites</h1>
<a href="https://wa.me/20100..." style="background:#0f766e">Chat now</a>
Every change to that headline or colour needs a developer and a deployment. Multiply this by every section and the site becomes frozen.
Making a child theme editable
1. Customizer settings for site-wide options
Text, colours, toggles and links that appear on many pages belong in the Customizer:
add_action( 'customize_register', function ( $wp_customize ) {
$wp_customize->add_section( 'mx_hero', array(
'title' => __( 'Hero', 'astra-child' ),
) );
$wp_customize->add_setting( 'mx_hero_title', array(
'default' => __( 'Websites that work', 'astra-child' ),
'sanitize_callback' => 'sanitize_text_field',
'transport' => 'postMessage',
) );
$wp_customize->add_control( 'mx_hero_title', array(
'label' => __( 'Hero title', 'astra-child' ),
'section' => 'mx_hero',
'type' => 'text',
) );
} );
And in the template:
<h1><?php echo esc_html( get_theme_mod( 'mx_hero_title', __( 'Websites that work', 'astra-child' ) ) ); ?></h1>
Note three habits: a sanitize callback on every setting, escaping on output, and translatable defaults.
2. A single options helper
Instead of calling get_theme_mod() with different defaults in ten places, define defaults once in an array and read them through one helper function. Then defaults never drift apart.
3. Post meta for per-page content
Content that differs per page or post (a summary box, FAQ items, an SEO title) belongs in post meta, registered with register_post_meta() and show_in_rest so it also works in the block editor.
4. Custom post types for repeated items
Testimonials, clients, projects: anything that is a list of similar items should be a custom post type, not a hardcoded array. Register post types in a plugin, so they survive a theme switch.
5. CSS custom properties for design tokens
Output colours from settings as CSS variables once:
:root { --accent: #0f766e; }
.button { background: var(--accent); }
Then a palette change is one setting, not a search-and-replace.
Child theme checklist
style.cssheader correct; theme activates without errors.- Styles enqueued with versions, no
@import. - No hardcoded copy, links, phone numbers or colours in templates.
- Every setting sanitised; every output escaped.
- Strings translatable with the theme’s text domain (needed for an Arabic or multilingual site).
- Functionality that must survive a theme change lives in a plugin.
- Code checked with PHP_CodeSniffer and the WordPress Coding Standards.
Common mistakes
- Editing the parent theme directly; the next update wipes it.
- Copying the entire parent template folder “just in case.”
- Storing API keys in theme files.
- Inline styles everywhere, impossible to theme later.
Why a child theme still matters in 2026
WordPress now ships block themes and Full Site Editing, so some people assume child themes are obsolete. They are not. The official Theme Handbook still recommends a child theme whenever you change a theme you did not write, because a parent update replaces every file in the parent folder (WordPress Theme Handbook: Child Themes). What changed is where the customisation lives. With a classic theme, you mostly override PHP templates and enqueue a stylesheet. With a block theme, a child theme can ship its own theme.json, block templates and template parts, and WordPress merges them over the parent’s settings (Global Settings and Styles).
One trap with block themes: changes made in the Site Editor are saved in the database, not in files. They survive updates, but they are also invisible in your Git repository. For client sites I export those changes back into the child theme files before handover, so the next developer can see what was customised.
Classic theme vs block theme child: what to put where
| Change | Classic parent | Block parent |
|---|---|---|
| Colours, fonts, spacing | Child style.css |
Child theme.json |
| Header or footer layout | Copy header.php / footer.php |
Template parts in parts/ |
| Page layout | Copy the template file | Block template in templates/ |
| New behaviour | functions.php hooks |
functions.php hooks |
| Business logic (post types, integrations) | A small plugin, not the theme | |
The last row is the one most projects get wrong. If a custom post type or payment integration lives in the theme, switching themes later breaks the site’s data. The Plugin Handbook’s guidance is simple: themes handle presentation, plugins handle functionality (Plugin Developer Handbook).
Keeping overrides maintainable
Every template you copy into a child theme is a copy you now own. When the parent theme fixes a bug or adds accessibility improvements to that template, your copy does not get them. A few habits keep this under control:
- Prefer hooks and filters over copies. Many themes and WooCommerce expose actions around their markup. Adding a hook is a few lines; maintaining a copied template is a permanent job.
- Record the parent version. Add a comment at the top of every copied file with the parent version it came from, so you can diff it after updates.
- Watch WooCommerce template notices. WooCommerce reports outdated template overrides under WooCommerce › Status, which is a quick check after every major update (WooCommerce: Template structure and overriding templates).
- Keep the child theme in version control. Even a small agency benefits from Git: you can see who changed what and roll back a bad deploy in minutes.
Bilingual sites: translate the child theme properly
For Arabic and English sites, hardcoded English strings in a child theme are the most common reason an Arabic page still shows “Read more” or “Contact us”. Wrap every string in translation functions such as __() and esc_html_e() with your own text domain, then translate them through your multilingual plugin’s string translation or a .po file (Theme Handbook: Internationalization). Use logical CSS properties like margin-inline-start instead of margin-left so the layout mirrors correctly in RTL without a second stylesheet. More on that in the multilingual WordPress guide.
Handover notes for agencies and freelancers
Clients in Egypt and the Gulf often change developers every few years. A child theme that the next person can understand protects the client and your reputation. Before handover I include:
- A short README in the child theme listing every overridden template and why.
- Which settings live in the Customizer, the Site Editor or ACF options, so content editors know where to look.
- The parent theme name, version and licence, and where updates come from.
- A note of any custom functionality that lives in a companion plugin.
This takes an hour and saves the client days later. It also makes routine work such as WP-CLI updates and a periodic plugin audit much safer.
A child theme should make the site easier to own, not harder. If your current theme is full of hardcoded content and you want it made editable, get in touch. For the bigger platform question, read Laravel vs WordPress.
Frequently asked questions
What is a WordPress child theme?
A child theme is a theme that inherits the templates and styles of a parent theme and overrides only what you change, so parent updates do not erase your work.
Do I still need a child theme with block themes?
For block themes many changes can be saved in the Site Editor, but code changes such as PHP functions, custom templates and assets still belong in a child theme or a plugin.
Should custom functionality go in the child theme or a plugin?
Design and presentation belong in the theme. Functionality that should survive a theme change, such as custom post types, belongs in a plugin.
