Stijlen van WordPress child-thema laden niet

De style.css van je child-thema laadt niet omdat WordPress hem niet voor je enqueuet. De stylesheet van het child-thema moet handmatig geregistreerd worden in de functions.php van het child-thema, en in die enqueue zit vrijwel altijd een van twee fouten: hij staat er helemaal niet, of hij laadt zonder de parent-stylesheet als afhankelijkheid op te geven, waardoor je regels op de verkeerde plek in de cascade belanden en overschreven worden. Herstel de enqueue en de stijlen komen terug. De oude @import-truc die je waarschijnlijk uit een tutorial van 2013 hebt gekopieerd is de verkeerde oplossing.

Waarom het gebeurt

Een klassiek child-thema bestaat uit twee verplichte bestanden: een style.css met een headerblok dat de parent benoemt, en een functions.php. De Template:-regel in de header vertelt WordPress van welke parent het templates moet overerven. Dat is het enige wat WordPress automatisch doet. Het leest de header, regelt de template-fallback en stopt daarmee. Het enqueuet nooit je child-style.css aan de voorkant.

Het parent-thema enqueuet ondertussen zijn stylesheet vanuit zijn eigen functions.php, gekoppeld aan wp_enqueue_scripts. Je child-functions.php draait eerst, daarna die van de parent, en daarna vuurt alles op die hook af. Als je child nooit wp_enqueue_style aanroept voor zijn eigen bestand, vraagt de browser het ook nooit op. De pagina ziet eruit als het kale parent-thema, want dat is precies wat het is.

De tweede fout is subtieler. Je enqueuet de child-stylesheet, hij laadt, maar je overrides doen niets. Dat is een probleem met de laadvolgorde. Als twee regels dezelfde specificiteit hebben, wint degene die als laatste laadt. Als je child-CSS vóór die van de parent laadt, wint de parent elke gelijkstand. De afhankelijkheidsarray op wp_enqueue_style is wat de volgorde afdwingt.

Nog iets waar mensen de mist mee ingaan: get_template_directory_uri() wijst naar de map van het parent-thema, en get_stylesheet_directory_uri() wijst naar de map van het actieve (child)-thema. Verwissel ze en je enqueuet de style.css van de parent een tweede keer en raakt die van de child nooit aan.

De oplossing, op volgorde

Controleer eerst wat er daadwerkelijk laadt. Open de kapotte pagina, bekijk de broncode en zoek naar de mapnaam van je child-thema. WordPress rendert geënqueuete stijlen als <link id="handle-css" href="..."> — de id is je handle plus -css. Als je child-style.css helemaal niet in de <head> staat, draait de enqueue niet. Staat hij er wel, maar worden de stijlen niet toegepast, dan is het een afhankelijkheids- of volgordeprobleem. Deze ene controle vertelt je welke van de twee fouten je hebt.

Zoek als tweede de echte handle van de parent. De meeste moderne thema’s (Astra, GeneratePress, de Twenty-*-thema’s) enqueuen hun eigen stylesheet al onder een specifieke handle — astra-theme-css, generate-style-css, twenty-twenty-four-style, enzovoort. Je hebt precies die string nodig. Grep het parent-thema, of lees hem af van de <link id="...-css"> in de broncode (laat de afsluitende -css weg).

Schrijf als derde de enqueue. Voor het veelvoorkomende geval waarin de parent zijn eigen stylesheet al laadt, enqueue je de parent niet opnieuw. Je enqueuet alleen de child en zet de handle van de parent als afhankelijkheid, zodat die van jou erna laadt:

<?php
add_action( 'wp_enqueue_scripts', 'child_enqueue_styles', 20 );

function child_enqueue_styles() {
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'astra-theme-css' ), // <-- the parent's REAL handle
        wp_get_theme()->get( 'Version' )
    );
}

Als het parent-thema zijn eigen stylesheet niet enqueuet (sommige oudere of minimalistische thema’s leunen op @import), enqueue dan beide en laat de child afhankelijk zijn van de parent:

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

function child_enqueue_styles() {
    wp_enqueue_style(
        'parent-style',
        get_template_directory_uri() . '/style.css'
    );
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'parent-style' ),
        wp_get_theme()->get( 'Version' )
    );
}

Het argument wp_get_theme()->get('Version') is je cache-buster. Verhoog de Version:-regel in de header van de child-style.css en browsers halen het bestand opnieuw op. Sla het over en je zit CSS te bewerken terwijl je zweert dat er niets verandert, terwijl het gewoon gecachet is.

Als functions.php een syntaxfout bevat, sterft het hele bestand stilletjes en draait geen van je enqueues — dat ziet er precies zo uit als “stijlen laden niet”. Zet WP_DEBUG aan, of plak je debug.log in onze WordPress error log decoder om de kritieke fout snel op te sporen.

Wat je niet moet doen

Gebruik geen @import. Het advies uit het Codex-tijdperk was om @import url("../parenttheme/style.css"); bovenaan de child-style.css te zetten. Het werkt, maar het is traag — de browser kan pas beginnen met het downloaden van de parent-CSS als hij de child-CSS heeft geparseerd, waardoor de twee requests achter elkaar in plaats van parallel lopen. WordPress’ eigen handbook raadt het al jaren af. Als je tutorial je dit heeft opgedragen, is die tutorial de reden dat je stijlen haperen.

Zet de handle 'parent-style' niet hard vast en enqueue het parent-bestand niet blind. De beroemde Codex-snippet doet precies dit, en het is fout voor elk thema dat zijn stylesheet al onder een andere handle registreert. Je laadt de parent-CSS dan dubbel en je afhankelijkheid wijst naar een handle die misschien niet bestaat.

Roep wp_enqueue_style niet aan op het topniveau van functions.php. Het moet binnen een functie draaien die aan wp_enqueue_scripts gekoppeld is. Te vroeg aangeroepen doet het niets.

Kopieer niet de hele functions.php van de parent naar de child. Ze laden allebei; die van de child draait eerst. Kopiëren veroorzaakt dubbele functiedeclaraties en een kritieke fout.

Één kanttekening: dit gaat allemaal over klassieke (PHP-template)thema’s. Als je parent een blok-thema is, verloopt de styling grotendeels via theme.json en de Site Editor, en gedragen style.css-overrides zich anders — daar zou ik minder op vertrouwen en het rechtstreeks testen in plaats van aannemen dat deze enqueue de oplossing is.

Kom je er nog steeds niet uit?

Controleer of de Template:-regel in de header van de child-style.css exact overeenkomt met de mapnaam van de parent, hoofdlettergevoelig — niet met de weergavenaam van de parent. Bekijk daarna opnieuw de broncode: handle aanwezig, laadt na de parent, versie-querystring verhoogd. Als de <link> er is, als laatste laadt en de CSS nog steeds niet wordt toegepast, dan is het geen enqueue-probleem meer — dan is het specificiteit, en verhuist de oplossing naar de regels zelf.