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.
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.
