WordPress child theme: waarom je er een nodig hebt en hoe je er een maakt

Doel. Aan het einde van dit artikel heb je een werkend child theme dat de stijlen en templates van het parent theme overneemt, waarmee je alles kunt overschrijven zonder dat je aanpassingen verloren gaan bij een update van het parent theme.

Vereisten

• Een WordPress 5.9+ site met beheerderstoegang en de mogelijkheid om bestanden te bewerken via FTP, SSH of de bestandsbeheerder van je hosting. Als je een oudere versie draait, werken de classic-theme-stappen nog steeds, maar het block-theme (FSE) gedeelte niet.
• Een parent theme dat al geinstalleerd en geactiveerd is. Deze handleiding gebruikt Twenty Twenty-Four voor het block-theme-pad en Twenty Twenty-One voor het classic-theme-pad, maar het proces is hetzelfde voor elk parent theme.
• Toegang tot wp-content/themes/ op de server. Als je host geen toegang tot bestanden biedt, kijk dan of ze een ingebouwde child theme-generator in het hostingpaneel hebben.

Wat een child theme is en waarom je er een nodig hebt

Een child theme is een aparte themamap die een parent (het "template" theme) aanwijst en alle templates, stijlen en functionaliteit van dat parent erft. Elk bestand dat je in de child theme-map plaatst, overschrijft het overeenkomstige bestand in het parent. Bestanden die je niet overschrijft, blijven gewoon laden vanuit het parent theme.

Dit is een WordPress-kernmechanisme, geen plugin. WordPress ondersteunt child themes sinds versie 3.0, en de documentatie over child themes in het Theme Handbook is de officiële referentie.

Waarom dit ertoe doet: elke keer dat het parent theme een update krijgt (beveiligingspatches, nieuwe functies, compatibiliteitsfixes), overschrijft WordPress alle bestanden in de parent-map. CSS, PHP of templatebestanden die je direct in het parent had aangepast zijn dan weg. Een child theme zet je aanpassingen buiten het bereik van die overschrijving.

Wat er met parent theme-aanpassingen gebeurt bij een update

Drie scenario's die regelmatig misgaan:

• Directe bestandswijzigingen in het parent theme (bewerken van style.css, header.php, functions.php in de parent-map): volledig weg bij de volgende update. Geen herstelmogelijkheid, tenzij je een backup hebt.
• CSS toegevoegd via het veld "Aanvullende CSS" in de Customizer: opgeslagen in de database, dus het overleeft updates van themabestanden. Maar het is gekoppeld aan het actieve thema. Als je van thema wisselt of een child theme activeert, wordt die CSS inactief. En het Aanvullende CSS-veld in de Customizer bestaat alleen voor classic themes; block themes gebruiken de Global Styles in de Site Editor.
• Site Editor-aanpassingen (templates, stijlen en patronen opgeslagen via de block editor UI in block themes): opgeslagen in de database en overleven parent theme-updates zonder child theme. Een child theme is hiervoor niet nodig, alleen voor wijzigingen op bestandsniveau zoals theme.json-instellingen, PHP in functions.php of HTML-template overrides.

Het child theme dekt het eerste scenario volledig en het derde gedeeltelijk. Als al je aanpassingen CSS-only zijn op een classic theme, werkt het Customizer-veld prima. Voor al het andere is een child theme het juiste antwoord.

Een child theme maken voor een classic theme

Een child theme heeft minimaal twee bestanden nodig: style.css en functions.php. De mapnaam mag van alles zijn, maar de conventie is parentnaam-child.

Stap 1: maak de child theme-map aan

Maak een nieuwe map aan in wp-content/themes/. Voor een child van Twenty Twenty-One:

wp-content/themes/twentytwentyone-child/

Stap 2: maak style.css aan met de verplichte header

Maak style.css aan in de child theme-map met deze header:

/*
 Theme Name: Twenty Twenty-One Child
 Template:   twentytwentyone
*/

/* Je eigen CSS komt onder deze regel */

Twee velden zijn verplicht. Theme Name is een zelfgekozen naam voor je child theme. Template moet exact overeenkomen met de mapnaam van het parent theme, niet de weergavenaam. Het Theme Handbook is er duidelijk over: de waarde "must be a 100% match of the folder name of the parent theme, relative to the wp-content/themes folder."

Als Template niet klopt, herkent WordPress de parent-child-relatie niet en zal het thema niet activeren of zonder parent-stijlen tonen.

Stap 3: maak functions.php aan en laad de parent stylesheet

Maak functions.php aan in de child theme-map:

<?php
// Laad eerst de parent stylesheet, dan de child stylesheet
add_action( 'wp_enqueue_scripts', 'twentytwentyone_child_enqueue_styles' );

function twentytwentyone_child_enqueue_styles() {
    // Laad de parent stylesheet als eerste
    wp_enqueue_style(
        'twentytwentyone-style',
        get_template_directory_uri() . '/style.css'
    );

    // Laad de child stylesheet als tweede, met parent als dependency
    wp_enqueue_style(
        'twentytwentyone-child-style',
        get_stylesheet_uri(),
        array( 'twentytwentyone-style' ) // zorgt voor de juiste cascade-volgorde
    );
}

get_template_directory_uri() wijst naar het parent theme. get_stylesheet_uri() wijst naar de style.css van het child theme. De $deps-array vertelt WordPress om het parent eerst te laden, zodat je child-CSS later in de cascade komt. De wp_enqueue_style()-documentatie legt de dependency-parameter in detail uit.

Gebruik geen @import url('../twentytwentyone/style.css') in de child style.css. Dat patroon duikt op in oudere tutorials maar voegt een extra HTTP-verzoek toe en blokkeert de rendering. De enqueue-aanpak is wat WordPress aanbeveelt.

Stap 4: activeer het child theme

Ga naar Weergave > Thema's in wp-admin. Je child theme staat in de lijst. Activeer het.

Verwacht resultaat: de site ziet er identiek uit als daarvoor. De parent-stijlen laden eerst, je lege style.css van het child voegt niets toe, en het visuele resultaat is pixel-voor-pixel hetzelfde. Als de site er ongestyled uitziet, klopt de Template-waarde niet of zit er een typfout in de enqueue-functie.

Correct enqueueing wanneer het parent zichzelf al laadt

Sommige parent themes registreren en laden hun eigen style.css al met een bekende handle. In dat geval hoef je het parent niet zelf te laden; je hoeft alleen het child te laden met de handle van het parent als dependency.

Kijk in de functions.php van het parent theme naar een regel als:

wp_enqueue_style( 'parent-theme-handle', get_stylesheet_uri() );

Als die handle bestaat, wordt de functions.php van je child eenvoudiger:

<?php
add_action( 'wp_enqueue_scripts', 'my_child_enqueue_styles' );

function my_child_enqueue_styles() {
    wp_enqueue_style(
        'my-child-style',
        get_stylesheet_uri(),
        array( 'parent-theme-handle' ) // gebruik de echte handle van het parent
    );
}

Bij twijfel: laad beide gewoon expliciet (zoals in stap 3). Een stylesheet twee keer laden onder verschillende handles is verspilling maar geen probleem. Nul keer laden is wel een probleem.

Parent theme-templates overschrijven

De template hierarchy van WordPress geldt ook voor child themes, met een belangrijke regel: de kopie in het child theme gaat voor op die van het parent op hetzelfde specificiteits-niveau.

Om een template te overschrijven, kopieer je het bestand van de parent-map naar de child-map met dezelfde bestandsnaam en relatief pad. Bijvoorbeeld, om single.php te overschrijven:

1. Kopieer wp-content/themes/twentytwentyone/single.php naar wp-content/themes/twentytwentyone-child/single.php.
2. Bewerk de kopie in het child. De parent-versie wordt nu genegeerd voor dat template.

Verwacht resultaat: pagina's die single.php gebruiken, renderen nu vanuit de child-versie. Alle andere templates komen nog steeds van het parent.

Een specificiteits-kanttekening die mensen verrast. De generieke category.php van een child theme overschrijft niet de specifiekere category-recepten.php van het parent theme. WordPress kiest het meest-specifieke overeenkomende bestand, ongeacht of het in het child of het parent staat. De template hierarchy-documentatie is hier duidelijk over: specificiteit wint van themahierarchie.

Eigen functies toevoegen aan functions.php

De functions.php van het child theme vervangt die van het parent niet. Beide bestanden worden geladen, waarbij het child eerst geladen wordt. Dat betekent dat je hooks, filters en nieuwe functies kunt toevoegen in het child zonder de code van het parent te dupliceren.

Kopieer geen functies uit de functions.php van het parent naar het child. Als het parent function mytheme_setup() declareert en jij dezelfde functie in het child plakt, geeft PHP een fatale fout door een dubbele functiedeclaratie. Het Theme Handbook waarschuwt hier expliciet voor.

Als je het gedrag van een parent-functie moet aanpassen, gebruik dan de hooks die het parent biedt. Goed gebouwde themes wikkelen hun functies in een if ( ! function_exists() )-check zodat child themes ze kunnen overschrijven door de functie als eerste te declareren (omdat het child voor het parent laadt). Als het parent dat patroon niet gebruikt, gebruik dan remove_action() of remove_filter() in de functions.php van het child om de hook van het parent los te koppelen en je eigen hook te koppelen.

Een child theme maken voor block themes (FSE)

Block themes (Full Site Editing, geintroduceerd in WordPress 5.9) gebruiken een ander aanpassingsmodel. Templates zijn HTML-bestanden, geen PHP. Stijlen worden gedefinieerd in theme.json, niet in style.css. Maar child themes werken gewoon, en het principe is hetzelfde: zet je overrides in de child-map, laat het parent de rest afhandelen.

De minimale bestanden

Een block child theme heeft nodig:

1. style.css met de Theme Name- en Template-header, identiek aan de classic versie. WordPress gebruikt dit bestand nog steeds om het child theme te herkennen. Voor een child van Twenty Twenty-Four:

/*
 Theme Name: Twenty Twenty-Four Child
 Template:   twentytwentyfour
*/

2. theme.json met minstens een version-veld. Hier zet je je stijl- en instellingsoverrides in plaats van CSS:

{
    "$schema": "https://schemas.wp.org/wp/6.7/theme.json",
    "version": 3
}

Het version-veld is verplicht. Weglaten zorgt ervoor dat instellingen stilletjes falen. Versie 3 is geintroduceerd in WordPress 6.6; gebruik versie 2 als je WordPress 6.5 of eerder moet ondersteunen.

3. functions.php is optioneel voor block child themes. Omdat block themes style.css niet laden voor de rendering (stijlen komen uit theme.json), heb je functions.php alleen nodig als je PHP-hooks, filters of custom post types toevoegt. Als je toch wilt dat de style.css van het child als daadwerkelijke stylesheet geladen wordt, moet je die expliciet enqueueen, net als bij een classic child theme.

theme.json-instellingen overschrijven

De theme.json van het child wordt samengevoegd met die van het parent via WP_Theme_JSON_Resolver::get_merged_data(). De samenvoegprioriteit, van laag naar hoog:

1. WordPress-kerndefaults
2. Block-level data
3. Theme (parent, daarna child op hetzelfde origin-niveau)
4. Gebruikersaanpassingen vanuit de Site Editor (hoogste prioriteit)

Om bijvoorbeeld de primaire kleur van het parent te overschrijven:

{
    "$schema": "https://schemas.wp.org/wp/6.7/theme.json",
    "version": 3,
    "settings": {
        "color": {
            "palette": [
                {
                    "color": "#1a3d5c",
                    "name": "Primary",
                    "slug": "primary"
                },
                {
                    "color": "#f5f1eb",
                    "name": "Base",
                    "slug": "base"
                }
            ]
        }
    }
}

Een kritieke kanttekening: de samenvoeging is niet diep op array-niveau. Als je het kleurenpalet overschrijft, moet je de hele palette-array opnemen, niet alleen het item dat je wilt wijzigen. De Full Site Editing child theme-documentatie is hier expliciet over: "Settings and styles in the child theme.json replace the equivalent in the parent; it is not possible to make partial edits" op array-niveau.

Block templates overschrijven

Block theme-templates staan in een templates/-map als .html-bestanden. Om er een te overschrijven, kopieer je het van de parent's templates/ naar de child's templates/ met dezelfde bestandsnaam. De laadvolgorde die WordPress volgt:

1. Child .html-template
2. Child .php-template (fallback)
3. Parent .html-template
4. Parent .php-template (fallback)

Template parts werken op dezelfde manier, in de parts/-map.

Wanneer je GEEN child theme nodig hebt

Niet elke aanpassing vraagt om een child theme. Sla het over wanneer:

• Al je stijlwijzigingen via de Site Editor (block themes) of de Aanvullende CSS in de Customizer (classic themes) gaan. Beide slaan wijzigingen op in de database, buiten de themabestanden.
• Je maar een paar CSS-regels nodig hebt en geen templates of PHP aanpast. Een kleine custom CSS-plugin of het Customizer-veld is dan eenvoudiger.
• Je een volledig eigen thema vanaf scratch bouwt in plaats van een bestaand thema aan te passen.

Je hebt wel een child theme nodig als je PHP-bestanden van het thema bewerkt, templatebestanden overschrijft, theme.json direct aanpast (buiten de Site Editor), of functionaliteit via functions.php toevoegt die thuishoort in het thema en niet in een plugin.

Controleer het eindresultaat

Na het activeren van het child theme, controleer je drie dingen:

1. De front-end ziet er correct uit. Bekijk de homepage, een enkel bericht, een categorie-archief en de 404-pagina. Vergelijk met de weergave van het parent theme. Visuele problemen wijzen op een ontbrekende enqueue of een kapotte Template-header.
2. Het child theme wordt getoond in Weergave > Thema's. WordPress toont het als child van het parent. Als de parent-relatie niet zichtbaar is, klopt de Template-waarde in style.css niet.
3. Je overrides werken. Als je CSS hebt toegevoegd, inspecteer dan het element in de dev tools van de browser en bevestig dat de child-stylesheet na het parent laadt. Als je een template hebt overschreven, bekijk dan een pagina die dat template gebruikt en verifieer dat de wijziging zichtbaar is.

Veelvoorkomende problemen

• Site ziet er volledig ongestyled uit na activeren. De parent stylesheet wordt niet geladen. Controleer of de enqueue-functie in functions.php de juiste parent handle of pad gebruikt, en of get_template_directory_uri() naar de daadwerkelijke parent-map wijst.
• "Stylesheet is niet leesbaar" of "Het parent theme ontbreekt"-fout. De Template-waarde in style.css komt niet overeen met de mapnaam van het parent theme. Mapnamen zijn hoofdlettergevoelig op Linux-servers.
• Wijzigingen in theme.json worden genegeerd. Ontbrekend "version"-veld in de theme.json van het child, of het versienummer past niet bij het ondersteunde schema van de WordPress-versie. WordPress 6.6+ gebruikt versie 3; WordPress 5.9 tot en met 6.5 gebruiken versie 2.
• Fatale fout door dubbele functie. Je hebt een functie uit de functions.php van het parent naar het child gekopieerd. Verwijder het duplicaat en gebruik hooks.
• CSS van het child overschrijft de parent-stijlen niet. De cascade-volgorde klopt niet. Zorg dat de child-stylesheet de handle van het parent als dependency opgeeft, zodat het na het parent geladen wordt.

Voor prestatieproblemen na het activeren van een nieuw thema of child theme, zie waarom WordPress traag kan aanvoelen na een update, waar de effecten van cache-legen en OPcache bij themawijzigingen worden behandeld.

Wanneer escaleren

Als het child theme zich na het volgen van deze handleiding niet gedraagt zoals verwacht, verzamel dan het volgende voordat je hulp inschakelt:

• WordPress-versie (zichtbaar in Dashboard > Updates)
• PHP-versie (zichtbaar in Hulpmiddelen > Site Health > Info > Server)
• Naam en versie van het parent theme
• De volledige inhoud van de style.css-header van het child theme
• De volledige inhoud van de functions.php van het child theme
• Voor block themes: de theme.json van het child
• Eventuele foutmeldingen uit de browserconsole of wp-content/debug.log

Met die informatie kan een developer of de support van je host het probleem reproduceren zonder te hoeven gissen. Voor een uitgebreid overzicht van de debug-flags die debug.log produceren, zie de wp-config.php-naslag.