Stel, u laat een timmerman een keuken plaatsen en hij zaagt de aanpassingen rechtstreeks in de fabriekskasten. Ziet er prima uit, totdat de fabrikant een nieuw model levert en al het zaagwerk voor niets is geweest. Zo ongeveer werkt het ook met websites waarin aanpassingen direct in het thema zijn gemaakt. Bij de eerstvolgende update van dat thema is het maatwerk weg.

Een child-thema in WordPress is de oplossing die daarvoor is bedacht. Het is een klein extra thema dat bovenop uw eigenlijke thema ligt en alleen de afwijkingen bevat. Het bovenliggende thema kan daardoor vrij bijgewerkt worden, terwijl uw aanpassingen ongemoeid blijven. In dit artikel leggen we uit hoe dat werkt, hoe u controleert of uw site er een gebruikt en wanneer het de moeite is om er alsnog een te laten maken.

Wat een child-thema precies is

Een WordPress-thema is een map met bestanden die bepalen hoe uw site eruitziet: de opmaak, de indeling van de koptekst, de manier waarop een blogbericht wordt getoond. Bij een update wordt die hele map vervangen. Alles wat erin veranderd was, gaat verloren.

Een child-thema is een aparte map die tegen WordPress zegt: “Gebruik alles van dat andere thema, behalve wat hier staat.” Staat er in het child-thema een eigen versie van de voettekst, dan gebruikt WordPress die. Staat er niets over de koptekst, dan komt die gewoon uit het hoofdthema. Het is een laag met uitzonderingen, meer niet.

Het hoofdthema heet in dit verband het parent-thema. Het child-thema is technisch vaak niet meer dan twee bestanden: een stylesheet met een paar regels bovenaan die verwijzen naar de parent, en een functiebestand dat de opmaak van de parent inlaadt. Alles wat een bouwer daarna toevoegt, komt in die map terecht.

Wat er wél en niet in hoort

Een child-thema is bedoeld voor aanpassingen die de bouwer met code maakt. Bijvoorbeeld:

  • eigen CSS die verder gaat dan wat de Customizer toelaat;
  • aangepaste sjablonen, zoals een andere indeling van de productpagina of een bijzondere landingspagina;
  • kleine functies, zoals een extra veld in het bestelproces of een aangepaste datumweergave;
  • het inladen van eigen lettertypen.

Wat er niet in hoort, is functionaliteit die los van het thema moet blijven werken. Wisselt u ooit van thema, dan verdwijnt het child-thema mee. Zaken als een koppeling met uw boekhouding of een aangepaste zoekfunctie horen daarom in een plugin, niet in het thema. Een goede bouwer maakt dat onderscheid.

Ook instellingen die u zelf in het beheer aanpast, zoals kleuren in de Customizer of pagina’s in een paginabouwer, staan niet in het child-thema. Die zitten in de database en zijn sowieso veilig bij een update.

Zo controleert u of uw website een child-thema gebruikt

Dit kunt u zelf in een minuut nakijken. Ga in het beheer naar Weergave › Thema’s. Het actieve thema staat vooraan. Klik erop voor de details. Ziet u een naam met “Child” erin, of staat er een zin als “Dit is een child-thema van …”, dan is het geregeld. Ziet u alleen de naam van een bekend thema als Astra, GeneratePress, Divi of Avada, zonder toevoeging, dan draait u vermoedelijk direct op het parent-thema.

Dat laatste is op zichzelf geen ramp. Het wordt pas een probleem als er aanpassingen in dat thema zijn gemaakt. Bij een site die volledig met de Customizer en een paginabouwer is opgezet, is er vaak niets aangepast en dus ook niets te verliezen. Bij een site waar een bureau maatwerk heeft geleverd, is de kans groot dat er wel in het thema is gewerkt.

Weet u het niet zeker, dan is de veiligste aanname dat er iets is aangepast, totdat het tegendeel is aangetoond. Hoe u een thema-update in dat geval voorbereidt, staat beschreven in het stappenplan voor een veilige thema-update.

Wanneer u er alsnog een laat maken

Er zijn drie situaties waarin het verstandig is om achteraf een child-thema in te richten.

  1. U weet dat er in het thema is gesleuteld. Dan wilt u die aanpassingen zo snel mogelijk overzetten naar een child-thema, vóór de volgende update. Dat is precisiewerk: elke wijziging moet gevonden, gekopieerd en getest worden.
  2. U laat binnenkort maatwerk uitvoeren. Vraag de bouwer dan expliciet om in een child-thema te werken. Het is een kleine moeite vooraf en scheelt veel gedoe later.
  3. Het thema wordt al jaren niet geüpdatet omdat “dat riskant is”. Dat is meestal een teken dat er ooit iets in is gewijzigd en niemand meer weet wat. Een verouderd thema is een beveiligingsrisico, dus dit is een situatie die u niet moet laten voortduren.

Een voorbeeld uit de praktijk. Een installatiebedrijf in Apeldoorn had een thema dat drie jaar niet was bijgewerkt, omdat een vorige beheerder had gezegd dat updates de site zouden slopen. Bij een controle bleek er in vijf bestanden maatwerk te zitten. Die aanpassingen zijn overgezet naar een nieuw child-thema, waarna het parent-thema in één keer van versie 2.1 naar 4.3 kon. De site zag er precies hetzelfde uit, maar draaide opeens op actuele, veilige code.

Wat u er in de praktijk aan heeft

Het grootste voordeel van een child-thema is rust. Updates worden een routinehandeling in plaats van een gok. Dat betekent dat beveiligingslekken in het thema sneller gedicht worden en dat uw site meebeweegt met nieuwe WordPress-versies en PHP-versies. Wie het themabeheer onderbrengt in een onderhoudsabonnement met maandrapport, mag verwachten dat de beheerder als eerste controleert of er een child-thema is en anders voorstelt om dat te regelen. Bij WebMaintor hoort die controle bij de intake van elke nieuwe site.

Een tweede voordeel is overdraagbaarheid. Als alle aanpassingen netjes in één map staan, kan een volgende bouwer of beheerder in een oogopslag zien wat er ooit op maat is gemaakt. Dat scheelt uren zoekwerk als u ooit van bureau wisselt.

Volgende stap

Kijk vandaag nog onder Weergave › Thema’s. Ziet u een child-thema, dan is het goed. Ziet u er geen, stel dan de vraag of er ooit in het thema is aangepast, aan uw bouwer of aan wie de site nu beheert. Het antwoord bepaalt of de volgende thema-update een formaliteit is of een risico.