Van dik hout: Thema ontwikkeling met Twig en Timber

Van dik hout zaagt men planken…

De laatste jaren schrijf ik zo vaak over Elementor, dat mensen bijna zouden vergeten, dat WordXPression ook aan theme development doet zonder hierbij Elementor te gebruiken. Dus door complete maatwerk sites te maken voor klanten. Voor een groot deel van de klanten van WordXPression valt dit echter buiten budget, vandaar dat de nadruk de afgelopen jaren sterk om Elementor als basis van de website is komen te liggen.

Toch is Elementor niet altijd de meest geschikte oplossing. Ik bouw met WordXPression nog steeds conventionele WordPress websites bovenop het Genesis Framework. Nu is het Genesis Framework absoluut niet geschikt voor de ‘eindgebruiker’, want het op maat maken van Genesis doe je met allerlei PHP bestanden. Maar wanneer je als eindklant er geen moeite mee hebt om minimaal 2000 euro voor een WordPress website neer te leggen (dat is wat ongeveer de ontwikkeling van een eigentijdse WordPress website op basis van Genesis kost), dan is dit een goede optie. Het voordeel van een website gebouwd op het Genesis Framework is veel lichtere code dan op basis van page- of theme builders en voor high performance sites (reken vanaf zo’n zo’n 1000 bezoekers per uur) is Elementor zeker niet meer aan te raden. De meeste van mijn Elementor klanten zouden echter al blij zijn met dat aantal bezoekers per dag.

Maar in dit blogartikel wil ik met je naar een andere oplossing kijken. En die oplossing brengt eigenlijk ’the best of both worlds’ samen. Het grote nadeel van Genesis is namelijk, dat je het hele thema in PHP code moet bouwen. Door Twig en Timber te gebruiken, kan je dat werk een heel stuk vereenvoudigen. Maar wat zijn Twig en Timber, en waarom vereenvoudigen ze het ontwikkelen van een thema? Om dat duidelijk te krijgen moeten we eerst een heel stuk terug in de geschiedenis van WordPress.

WordPress 1.5 – De Prehistorie

WordPress 0.7 werk op 27 mei 2003 aan de wereld gepresenteerd. Het was gebaseerd op een ander blog systeem, b2/cafelog, wat al een tijdje niet meer onderhouden werd. De reden dat WordPress 0.7 zo werd genummerd en geen 1.0 of 0.1, was omdat de laatst gepubliceerde versie van b2/cafelog het versienummer 0.6 had gekregen. Vanaf het begin was dus al duidelijk, dat bedoeld was om een voortzetting van b2/cafelog te worden en niet een compleet nieuwe blog toepassing (wat het natuurlijk uiteindelijk wel is geworden, omdat het huidige WordPress op geen enkele manier meer lijkt op het oude b2/cafelog).

Op dat moment bestonden er mogelijkheden om WordPress ‘andere kleurtjes’ te geven door CSS bestanden aan te passen, maar eigenlijk was de layout van WordPress toch wel behoorlijk voorgedefinieerd.

Daar kwam verandering in met WordPress 1.5. Dat is overigens de eerste versie van WordPress waarmee ik zelf ooit serieus aan het werk ben gegaan. WordPress 1.5 introduceerde namelijk het ’template/thema systeem’ wat we nu nog steeds kennen. En door de jaren heen is daar weinig verandering in gekomen.

Template systemen

Voor WordPress is er destijds een bewuste keuze gemaakt (er is op heel wat fora behoorlijk wat afgediscussieerd of het ook een goede keuze was) voor het template systeem zoals we dat nu kennen. En om heel eerlijk te zijn, zit dat template systeem behoorlijk knullig in elkaar. Men had het anders en beter kunnen doen, maar dat zou behoorlijk wat meer werk zijn geweest.

Geschreven in PHP

WordPress is geschreven in PHP. Dat was in die tijd eigenlijk de enige technisch beschikbare optie die WordPress geschikt kon maken voor een groter publiek en dat is op zich een goede keuze geweest.

Een nadeel van PHP is dat het in eerste instantie nooit bedoeld was geweest als een programmeer taal. De ontwerper van de taal wilde eenvoudig wat informatie binnen HTML kunnen verwerken. En dat maakt PHP eigenlijk een taal die prima geschikt is om een enorme rommel van je broncode te kunnen maken.

PHP code is niet makkelijk leesbaar voor een leek. En dat is één van de redenen dat er her en der al zogenaamde ’template systemen’ waren die zonder PHP in de code voor presentatie werkten. De meest bekende uit die tijd -die nog steeds bestaat- is Smarty.

Stel, dat ik een drietal variabelen heb, die ik zichtbaar wil maken in een HTML tabel. Is er geen email adres gedefinieerd, dan wil ik geen regel in de tabel tonen.

Dit zou er als volgt in een PHP template uit kunnen zien.

<html>
   <head>Een titel</head>
   <body>
      <table>
         <tr><td><?php echo $user->first_name;?></td></tr>
         <tr><td><?php echo $user->last_name;?></td></tr> 
         <?php if (isset($user->email)) { ?>      
             <tr><td><?php echo $user->email;?></td></tr>
         <?php };?>
      </table>
   </body>
</html>

<html>
   <head>Een titel</head>
   <body>
      <table>
         <tr><td>{$user.firstname}</td></tr>
         <tr><td>{$user.lastname}</td></tr>
         {if isset($user.email)}            
            <tr><td>{$user.email}</td></tr>
         {/if}
      </table>
   </body>
</html>

Het bovenste voorbeeld laat een PHP template zien, het onderste voorbeeld een Smarty template.

Je ziet direct, dat het bovenste template al heel wat meer tikwerk bevat. Maar dat is niet het enige nadeel. Omdat je in het bovenste voorbeeld ook direct programmacode kan gebruiken, werd dit ook regelmatig gedaan. Sterker nog, voor er een ‘functions.php’ als onderdeel van het thema kwam, had je zelfs geen andere keuze. Je moest alle code die door het template uitgevoerd moet worden ook in je template file opnemen.

Met betrekking tot Smarty is het eigenlijk precies het omgekeerde. Je moet alle code in een PHP bestand plaatsen, alle template code in een apart template bestand.

Maar WordPress had dus niet gekozen voor een bestaande template engine, maar in plaats daarvan voor de quick and dirty methode van de PHP templates. Een keuze die we tot op vandaag mogen betreuren, omdat Smarty een eigen ingebouwd caching systeem had, wat eigenlijk super efficient werkte.

Smarty for WordPress

Zelf programmeer ik sinds medio 1999 in PHP. En dat is best lang, wanneer je bedenkt, dat PHP zoals wij het nu kennen sinds 1998 bestaat. De versies die aan PHP3 vooraf gingen (PHP/FI en PHP/FI 2.0) hadden absoluut de mogelijkheden niet, die PHP sinds 3.0 kreeg. En vandaag, met 8.x als de ‘gangbare’ versie, bouwen we nog steeds verder op dat fundament.

Toen ik met PHP aan de slag ging, was Smarty 1.0 bezig langzaam door 2.0 vervangen te worden.

Toen ik kennis maakte met WordPress had ik dus al uitgebreid kennis gemaakt met Smarty, en wat mij vanaf het begin heeft verbaasd was dat WordPress geen makkelijker ’template systeem’ had. Want hoewel ik als ervaren PHP programmeur mijn hand absoluut niet omdraaide voor het ontwikkelen van een PHP thema, was het voor iemand zonder programmeer ervaring, iemand die uitsluitend ervaring met betrekking tot HTML en CSS zou hebben vrijwel onmogelijk om zelf een thema te bouwen.

Toen de plugin ‘Smarty for WordPress‘ als initiatief werd aangekondigd, was ik gelijk geïnteresseerd. En ruim tien jaar heeft de maker van de plugin aangeploeterd met een in principe goed initiatief, maar door gebrekkige documentatie is het nooit een succes geworden.

Twig en Timber

Twig is als template engine heel wat nieuwer dan Smarty. Het is een ‘bijproduct’ van Symphony, een bekend PHP framework. Wanneer ik Twig en Smarty vergelijk, dan is Twig duidelijk een template engine die veel heeft geleerd van de tekortkomingen van Smarty. Wat ik wel jammer vindt, is dat Twig geen caching mechanisme zoals Smarty heeft, maar je kan niet alles hebben.

Hoe makkelijk Twig eigenlijk is, wordt op de pagina’s van Twig zelf al duidelijk gemaakt.

Stel, je hebt HTML in een database opgeslagen en je wilt ook dat dit als HTML, en niet als het eindresultaat van die HTML getoond wil worden.

Wanneer ik uit een database zou lezen

<strong>En zo maak je tekst vet</strong>

en ik zou het zomaar zonder meer op een pagina plaatsen, dan zie je dit :

En zo maak je tekst vet

Wanneer ik dit in een PHP template zou willen laten zien, moet ik ongeveer de volgende code ingeven. Uitgangspunt is, dat we hier de waarde al hebben opgeslagen in de variabele die we ‘var’ hebben genoemd.

<?php echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>

In Twig is dat iets makkelijker.

{{ var|e }}

‘e’ staat hier voor ‘escape’, je mag het dus ook schrijven als

{{ var|escape }}

Timber! (van onderen!)

Nu kan je Twig niet zomaar in WordPress gebruiken. WordPress heeft een groot aantal ‘globale variabelen’ en het zou behoorlijk complex worden om dit per template door te moeten geven. Gelukkig heeft iemand dat al voor ons gedaan. Binnen WordPress horen Twig en Timber eigenlijk gewoon bij elkaar. Timber is een plugin die dat allemaal al vast voor ons gedaan heeft, zodat we ons daar geen zorgen over hoeven te maken.

Een ander mooi ding van Timber is dat Timber gebruikt kan worden binnen bestaande thema’s!

Om eens een voorbeeld te geven. Jij hebt een website. En binnen die bestaande website wil je een online leeromgeving.

Omdat jouw thema onvoldoende voorbereid is op Custom Post Types, kunnen jouw lessen, modules en cursussen niet getoond worden in de layout die jij graag zou zien.

Eén optie is je hele website om te laten zetten naar Elementor Pro. Afhankelijk van de grootte en complexiteit van je website kan dat een hele operatie zijn.

Een andere mogelijkheid is om een child theme van je website te laten maken en de specifieke templates de laten ‘bouwen’ door een WordPress developer. Iets waarvoor ik mijn hand niet omdraai.

Wanneer je echter die extra templates niet in PHP maar in Twig zou laten bouwen, zou je hiervoor voor de bouw ongeveer 60% van de tijd kwijt zijn, die je met een compleet in PHP geschreven template kwijt zou zijn.

Bovendien, wanneer je later die Twig templates zou laten onderhouden, zou je voor de aanpassingen minder dan 40% van de tijd kwijt zijn, dan wanneer de templates in PHP gebouwd zouden zijn.

Samenvatting

Wanneer je meer dan 1000 bezoekers per uur op je website hebt, dan wil je echt niet, dat je site met welke page- of theme builder dan ook gebouwd is, maar heb je liever een site in ‘pure code’.

Pure code is echter prijzig, omdat het behoorlijk wat meer tijd kost. Template engines kunnen hier een behoorlijk positieve bijdrage in leveren. Op dit moment is de combinatie van Twig en Timber de enige serieus te nemen template engine voor WordPress. En het mooie van de Twig en Timber combinatie is, dat dit niet afhankelijke is van een specifieke keuze.

Wanneer je Child Theme gerelateerde aanpassingen aan je website wilt hebben, kan je zo’n 40% besparen, wanneer de aanpassing met Twig en Timber uitgevoerd zou worden. In het onderhoud van de visuele presentatie kan je nog meer (tot 60%) besparen.

Wil je met mij van gedachten wisselen hierover, spreek mij aan via de chat (rechtsonder op de pagina) wanneer ik online ben.

Wil jij WordPress Developer worden?

Wil jij zelf WordPress thema’s ontwikkelen, plugins bouwen en meer? Kijk dan eens naar mijn cursus voor WordPress developer. Tijdens een cursus van drie maanden, bestaande uit online en ‘real life’ lesdagen leer jij hoe je zelf thema’s en plugins voor WordPress kan bouwen. Met betrekking tot de thema’s gaan we ook uitgebreid in op het werken met Twig en Timber.

Interesse? Lees dan verder.