{"id":251384,"date":"2026-10-18T15:05:00","date_gmt":"2026-10-18T15:05:00","guid":{"rendered":"https:\/\/muhamedahmed.com\/wordpress-child-theme\/"},"modified":"2026-11-02T04:15:51","modified_gmt":"2026-11-02T04:15:51","slug":"wordpress-child-theme","status":"publish","type":"post","link":"https:\/\/muhamedahmed.com\/en\/wordpress-child-theme\/","title":{"rendered":"WordPress Child Theme Done Right: Customizer Options Instead of Hardcoding"},"content":{"rendered":"

A WordPress child theme<\/strong> 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<\/code> with a Template:<\/code> header naming the parent, and a functions.php<\/code> that enqueues styles.<\/p>\n

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.<\/p>\n

How do you create a WordPress child theme?<\/h2>\n

Create a folder in wp-content\/themes\/<\/code>, for example astra-child<\/code>. Add a style.css<\/code> with at least a Theme Name<\/code> and Template<\/code> header (the parent’s folder name), add a functions.php<\/code> that loads the stylesheets, then activate the child theme under Appearance \u2192 Themes.<\/p>\n

style.css<\/h3>\n
\/*\nTheme Name:   Astra Child\nTemplate:     astra\nVersion:      1.0.0\nText Domain:  astra-child\n*\/\n<\/code><\/pre>\n
functions.php<\/h3>\n
<?php\nadd_action( 'wp_enqueue_scripts', function () {\n    wp_enqueue_style(\n        'astra-child',\n        get_stylesheet_uri(),\n        array(),\n        wp_get_theme()->get( 'Version' )\n    );\n} );\n<\/code><\/pre>\n
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<\/code> in CSS: it delays stylesheet loading.<\/p>\n
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<\/a>).<\/p>\n
Overriding templates<\/h2>\n
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.<\/p>\n
The real problem: hardcoding<\/h2>\n
Here is a pattern I find in many inherited child themes:<\/p>\n
<h1>We build fast websites<\/h1>\n<a href="https:\/\/wa.me\/20100..." style="background:#0f766e">Chat now<\/a>\n<\/code><\/pre>\n
Every change to that headline or colour needs a developer and a deployment. Multiply this by every section and the site becomes frozen.<\/p>\n
Making a child theme editable<\/h2>\n
1. Customizer settings for site-wide options<\/h3>\n
Text, colours, toggles and links that appear on many pages belong in the Customizer:<\/p>\n
add_action( 'customize_register', function ( $wp_customize ) {\n    $wp_customize->add_section( 'mx_hero', array(\n        'title' => __( 'Hero', 'astra-child' ),\n    ) );\n    $wp_customize->add_setting( 'mx_hero_title', array(\n        'default'           => __( 'Websites that work', 'astra-child' ),\n        'sanitize_callback' => 'sanitize_text_field',\n        'transport'         => 'postMessage',\n    ) );\n    $wp_customize->add_control( 'mx_hero_title', array(\n        'label'   => __( 'Hero title', 'astra-child' ),\n        'section' => 'mx_hero',\n        'type'    => 'text',\n    ) );\n} );\n<\/code><\/pre>\n
And in the template:<\/p>\n
<h1><?php echo esc_html( get_theme_mod( 'mx_hero_title', __( 'Websites that work', 'astra-child' ) ) ); ?><\/h1>\n<\/code><\/pre>\n
Note three habits: a sanitize callback<\/strong> on every setting, escaping<\/strong> on output, and translatable defaults<\/strong>.<\/p>\n
2. A single options helper<\/h3>\n
Instead of calling get_theme_mod()<\/code> with different defaults in ten places, define defaults once in an array and read them through one helper function. Then defaults never drift apart.<\/p>\n
3. Post meta for per-page content<\/h3>\n
Content that differs per page or post (a summary box, FAQ items, an SEO title) belongs in post meta, registered with register_post_meta()<\/code> and show_in_rest<\/code> so it also works in the block editor.<\/p>\n
4. Custom post types for repeated items<\/h3>\n
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.<\/p>\n
5. CSS custom properties for design tokens<\/h3>\n
Output colours from settings as CSS variables once:<\/p>\n
:root { --accent: #0f766e; }\n.button { background: var(--accent); }\n<\/code><\/pre>\n
Then a palette change is one setting, not a search-and-replace.<\/p>\n
Child theme checklist<\/h2>\n