Nuttige Code Snippets voor WordPress

Welkom bij mijn nieuwe ‘Code Snippets voor WordPress’ bibliotheek!

Ik schrijf al sinds 2010 over WordPress in de WordXPression blog. Sinds een paar jaar waag ik het af en toe om ook een aantal ‘code snippets’ voor WordPress aan sommige van mijn blogposts toe te voegen. Op het moment dat ik hiermee mee begon had ik nog geen idee of mijn lezerspubliek did wel of niet op prijs zou stellen. Het bleek dus wel zo te zijn, en dat is dus mooi meegenomen.

Een tijdje terug kreeg ik van iemand het commentaar ‘dat het zo jammer was, ik had zoveel nuttige code snippets, maar ze waren zo moeilijk terug te vinden’.

En ik dacht… tja, hij heeft me daar een sterk punt. Want mijn code snippets voor WordPress zijn vaak in een hele lap blog-tekst ‘verstopt’. Bovendien heb ik in de loop der jaren een bibliotheek van enkele honderden code snippets opgebouwd. Die snippets lenen zich niet echt voor een blog artikel, maar het is ook zonde, wanneer niemand er gebruik van kan maken.

En dat is de reden, dat ik besloot om op de WordXPression site ook een ‘Snippet Base’ te implementeren. Een verzameling code snippets met enige uitleg erbij, die je vrijelijk kan gebruiken, daar waar je het nodig hebt.

Maar wanneer ik zoiets doe, dan wil ik dat wel doen met de nodige veiligheidswaarschuwingen. Want onoordeelkundig gebruik zal al snel leiden tot een website die ‘eruit’ ligt, zonder dat je weet wat je moet doen. Dus laten we afspreken, dat je wanneer je mijn ‘code snippets voor WordPress’ gebruikt, je je aan een aantal gedragsregeltjes zal houden. Om te voorkomen, dat je website straks niet meer beschikbaar is.

Maar voor we het doen, wil ik je iets uitleggen over hoe WordPress nu eigenlijk in elkaar zit.

HTML, CSS, JS, PHP en Haken en Ogen…

Jouw browser begrijpt maar een paar dingen. HTML, CSS en JavaScript. Nu was oorspronkelijk JavaScript niet echt goed geschikt om aan de server kant te programmeren (later is daar verandering in gekomen). Een taal die hier wel goed geschikt voor was, vooral omdat deze speciaal hiervoor bedoeld was, was PHP.

In de tijd dat WordPress werd ontwikkeld was PHP de meest populaire taal om web applicaties te ontwikkelen. Dus het lag voor de hand dat WordPress PHP gebruikte -of eigenlijk, het lag voor de hand, dat de voorloper van WordPress dit deed- omdat WordPress gebaseerd is b2/cafelog, wat al in PHP was geschreven.

Meestal zal je iets aan het gedrag van WordPress willen veranderen. En dat doe je aan de kant van de server. Je werkt dan dus met PHP. En dat is riskant, want iedere verandering die je maakt, kan leiden tot het ‘down’ gaan van je website.

Soms zal je dingen willen veranderen een het uiterlijk van je website. Dat kan je vaak al doen in HTML, CSS en/of JavaScript en daar heb je geen PHP bij nodig. Dat kan je redelijk veilig doen, en je loopt niet veel gevaar dingen ‘kapot’ te maken.

Moet je dingen in PHP doen, doe het altijd eerst op een kopie van je website. Dat kan je bijvoorbeeld doen door een ‘staging kopie’ van je website te maken, of je website lokaal te installeren.

Op die kopie van je website probeer je eerst die snippet code uit. Werkt het? Dan kan je het verplaatsen naar je live site. Maar niet voordat je eerst een backup van je live site hebt gemaakt.

Waar voeg je die code toe?

De volgende vraag is natuurlijk, waar je die code toe moet voegen. Je zal vaak horen / lezen, dat je jouw code snippets voor WordPress toe moet voegen aan je ‘functions.php’. Dat is een bestand wat bij je thema hoort, waar allerlei functies in voorkomen, die door je thema gebruikt worden. Dat lijkt misschien een logische plek, maar hier kleven twee nadelen aan.

Thema updates

Het eerste -en grootste- nadeel is dat bij een update van je thema alle bestanden van het thema overschreven zullen worden door nieuwe bestanden. Of eigenlijk, meer correct : De hele folder van je thema zal leeg worden gegooid, en de nieuwe versie zal hier worden geïnstalleerd. Al jouw aanpassingen in de functions.php gaan hierdoor verloren. Dat is dus niet wat je wilt.

Gelukkig kun je voor WordPress zogenaamde ‘child theme’s’ maken. Een child theme erft alle eigenschappen van het ‘parent theme’, maar wordt niet overschreven bij een installatie van het parent theme. Nu klinkt dat ‘maken van een child theme’ misschien ingewikkeld, maar er zijn plugins die dat helemaal voor je doen.

Een nieuw thema

Maar wat nu als je een compleet nieuw thema wilt gaan gebruiken? Dan is het natuurlijk zaak, dat jouw code snippets voor WordPress in je functions.php niet verloren gaan. Gelukkig is het ‘veranderen van thema’ iets wat je niet zomaar doet en het gaat vaak gepaard met uitgebreid testen en vergelijken, en als het goed is kom je er vanzelf achter, dat je nog iets belangrijks bent vergeten.

Maar om toch te voorkomen, is het eigenlijk best een goede praktijk, dat je jouw code snippets voor WordPress die betrekking hebben op het uiterlijk van je site opslaat in de functions.php, maar die code snippets die betrekking hebben op de werking van de site in één plugin, waar je al je code snippets in plaats.

Plugins voor code snippets

Er zijn ook plugins die speciaal bedoeld zijn om code snippets makkelijk te gebruiken. Waarom zou je daar wel of niet gebruik van maken?

Het nadeel van deze plugins is dat de code snippets in de database wordt opgeslagen en het daarom meer tijd kost dit in te lezen. Dat kost net iets meer tijd. En één van de redenen, dat je liever gebruik maakt van code snippets dan van plugins die eenzelfde functie implementeren is juist die snelheid.

Een tweede probleem is de veiligheid. Wanneer de database wordt gehackt, is het vrij eenvoudig om ‘goed bedoelende’ code snippets te vervangen door ‘kwaadwillende codesnippets’. Het is dus ook een extra veiligheidsrisico, wat je liever niet wilt lopen.

Hoe voeg je code snippets toe?

Wanneer je een PHP code snippet ziet binnen de code snippets voor WordPress op deze site, dan beginnen die allemaal met <?php

Omdat PHP code in een HTML pagina geplaatst kan worden is die <?php nodig om tegen de server te vertellen, dat er nu PHP code aan zit te komen.

Wanneer je meerdere code snippets in één bestand plaatst, dan moet je dit eigenlijk maar één keer die <?php toevoegen. Stel dat ik hier twee (in het voorbeeld overigens onzinnige) code snippets zou hebben:

<?php 
add_shortcode('sayhello','wxp_say_hello');

function wxp_say_hello() {
   return 'Hello';
}

Zelfs wanneer je nog nooit van je leven een regel programmacode hebt gezien, kan je vast wel raden, wat dit codefragment doet.

Je zorgt ervoor, dat WordPress een ‘shortcode’ herkent met de naam [sayhello]. Gebruik je ergens [sayhello] in een tekst, zal dit vervangen worden door het woordje ‘Hello’.

Niet echt spannend dus, maar wel even een goed voorbeeld van hoe de code snippets voor WordPress er in de Snippet Base uit zullen zien. Veel in mijn voorbeelden zal beginnen met ‘wxp’, vooral bij zogenaamde ‘functienamen’. In WordPress moeten functienamen uniek zijn. En om dat waarschijnlijker te maken, zorg ik ervoor dat al mijn code onderdelen die uniek moeten zijn met een prefix ‘wxp’ beginnen. Daarmee maak ik kans op conflicten veel kleiner. Zo’n stukje als ‘wxp’ wordt een ‘prefix’ genoemd. En het is een goede praktijk om wanneer je hier een codefragment ‘overneemt’, overal waar ‘wxp’ staat dit te wijzigen door een eigen door jou bedachte prefix.

Nu hebben we ook nog een tweede code snippet voor WordPress :

<?php
add_shortcode('sayworld','wxp_say_world');

function wxp_say_world() {
   return 'world';
}

Stel nu, dat ik beide snippets in één bestand wil gebruiken. Je zou dan denken, dat de code hieronder dan zou moeten werken, nietwaar?

<?php 
add_shortcode('sayhello','wxp_say_hello');

function wxp_say_hello() {
   return 'Hello';
}

<?php
add_shortcode('sayworld','wxp_say_world');

function wxp_say_world() {
   return 'world';
}

Omdat PHP code door een plugin die ik hier gebruik automatisch ‘gekleurd’ wordt, zie je eigenlijk aan de kleuren hierboven al, dat er iets fout gaat. Op regel 8 ziet <?php er anders uit dan <?php op regel 1.

Wat wat was ook al weer de functie van <?php… ? Het vertelt, dat nu de HTML stopt en de volgende code PHP code is. Maar omdat de snippet ‘Say Hello’ al PHP was, hoeven we dat helemaal niet te vertellen!

De code hierboven kunnen we op twee manieren syntactisch juist schrijven. Maar de manieren zijn niet gelijkwaardig!

De eerste manier is de niet-aanbevolen manier :

<?php 
add_shortcode('sayhello','wxp_say_hello');

function wxp_say_hello() {
   return 'Hello';
}
?>

<?php
add_shortcode('sayworld','wxp_say_world');

function wxp_say_world() {
   return 'world';
}

De ‘?>’ op regel 7 vertelt PHP, dat we nu stoppen met PHP, en weer terug gaan naar HTML. En wat gebeurt er met HTML? Dat wordt direct naar je browser gestuurd.

Omdat na regel 7 een nieuwe regel begint, weten we dat er op regel 7 minimaal 1 ‘nieuwe regel’ teken staat. Misschien ook nog wat spaties en tabs, dat kunnen we hier niet zien.

Op regel 8 staat ook minimaal één nieuwe regel tegen. En mogelijk ook nog andere tekens die we niet kunnen zien.

Dit wordt nu allemaal richting de browser gestuurd. Op zich hoeft dat geen bezwaar te zijn. Maar in één bepaald onderdeel van het communicatieproces tussen server en browser kan dit wel een bezwaar zijn. Of met andere woorden, het kan soms fout gaan. En persoonlijk heb ik een grote hekel aan dingen die soms fout gaan. Beter is het om de code als volgt te organiseren.

<?php 
add_shortcode('sayhello','wxp_say_hello');

function wxp_say_hello() {
   return 'Hello';
}


add_shortcode('sayworld','wxp_say_world');

function wxp_say_world() {
   return 'world';
}

We hebben nu geen ?> toegevoegd, maar we hebben juist de <?php op regel 8 van het eerste voorbeeld verwijderd. De server krijgt dus de melding dat de PHP code begint. En omdat er geen andere melding komt, dat de PHP code ook weer stopt, zal de server blijven denken, dat alle code als PHP code afgehandeld moet worden.

En dat is precies wat we willen.

Er staat al iets in de functions.php

Wanneer iemand anders een child theme voor je heeft gemaakt, of jouw child theme is gemaakt door een plugin, dan is de kans groot dat er al <?php aan het begin van het bestand staat. In de meeste gevallen is het dus juist van belang, dat je de ‘<?php’ aan het begin van een snippet verwijderd. Simpel toch?

Maar wat, indien er <?php en ?> midden in een snippet staan, die je over wilt nemen? Dat kan ook gebeuren. Laat ik eens een eenvoudig voorbeeld geven.

<?php 
add_shortcode('helloworld','wxp_hello_world');

function wxp_hello_world() {
   ob_start();
   $first = 'Hello';
   $second = 'World';
   ?>
   <h1> <?php $first;?> <?php $second;?> </h1>
   <?php $content = ob_get_contents();
   ob_end_clean();
   return $content;
}

In deze code staat toch wel heel vaak <?php en ?>. Gaat dat niet helemaal fout?

Maak je geen zorgen. Je hoeft de code in de snippet niet echt te begrijpen, maar door het gebruik van de functies die hierboven staan en met ob_ beginnen, wordt er het één en ander met ‘output buffering’ gedaan. Ondanks dat de code zeer zeker HTML is, wordt deze niet naar de browser gestuurd maar ‘omgeleid’ naar een variabele, die later -op het moment dat het juist is- gebruikt wordt. In sommige code snippets voor WordPress zal je mogelijk zien, dat ik dit soort constructies gebruik. Dat is verder helemaal in orde.

Enkele belangrijke voorzorgmaatregelen

Wanneer je ook maar iets doet met het zelf toevoegen van code aan WordPress is het altijd belangrijk, dat je de FTP gegevens bij de hand hebt. In het ergste geval is het mogelijk dat je site niet meer toegankelijk is, en zal je via FTP toegang moeten verkrijgen.

Ik zeg altijd, dat je back ups moet maken, maar het terug zetten van een back up kost tijd. Je wilt -met name met een live site- natuurlijk dat je site zo snel mogelijk weer in de lucht is. Gaat het fout, begin niet gelijk met het terug zetten van je back up, maar verwijder eerst de code die je hebt toegevoegd. En die code verwijderen, dat doe je het best als je weet welke code je zojuist had toegevoegd.

Om dat zichtbaar te maken, is het goed om commentaar in je snippet file (of het nu een plugin of de functions.php is) te gebruiken.

Hoe ziet commentaar in PHP er uit?

In PHP heb je twee soorten van commentaar. Een commentaar wat over één regel gaat, of een commentaar wat zich over meerdere regels uitstrekt.

<?php
//Dit is één regel commentaar
echo 'En dit is weer PHP code';

/* 
Dit zijn meerdere regels commentaar 
Handig als je wat meer tekst kwijt moet, 
hoef je niet iedere regel met // te beginnen. 
*/
echo 'En dit is weer PHP code';

Ik denk dat deze voorbeelden voor zich spreken.

Met code snippets voor WordPress is het een goede gewoonte om deze op een volgende manier toe te voegen aan je ‘snippet file’. Laten we nogmaals kijken naar ons voorbeeld met de twee snippets. Ditmaal van commentaar voorzien.

<?php 
/*
   Shortcode om 'Hello' te zeggen. 
   Bron : https://wordxpression.nl/een-pagina-met-die-snippet/
   Toegevoegd : 01-01-2022
*/
add_shortcode('sayhello','wxp_say_hello');

function wxp_say_hello() {
   return 'Hello';
}

/* Shortcode om 'World' te zeggen
   Bron : https://wordxpression.nl/een-andere-pagina-met-de-andere-snippet/
   Toegevoegd : 02-02-2022
*/


add_shortcode('sayworld','wxp_say_world');

function wxp_say_world() {
   return 'world';
}

Ieder commentaar begint met een beschrijving, wat de code precies doet. Dat is natuurlijk handig, want wanneer je over een jaar dertig snippets in je snippet file hebt staan, dan is het mogelijk, dat je niet meer precies weet, wat wat doet. Al helemaal niet, wanneer je zelf niet echt een programmeur bent.

De regel daaronder geeft aan, waar de code vandaan komt. Dat hoeft natuurlijk niet een externe source te zijn, je kan het ook zelf gemaakt hebben, in zo’n geval zet je er je naam neer, of de naam van die vriendelijke buurman of buurvrouw die de code voor je heeft geschreven. Zelf weet ik graag waar een snippet vandaan komt, omdat het in de praktijk goed denkbaar is, dat de code later wordt verbetert. Loop ik tegen problemen aan met het gebruik van de snippet kan ik altijd terug naar de site, om te zien, of de maker van de code hem inmiddels niet heeft geupdate.

En daarna heb ik nog een indicatie wanneer de code is toegevoegd. Handig om te weten, vooral wanneer ik code wil verwijderen, omdat hij iets doet ‘breken’.

De snippets

Hieronder vind je de meest recent toegevoegde snippets aan de snippet base. Op dit moment heb ik enkele honderden snippets die ik beschikbaar wil gaan stellen om te delen, maar aangezien iedere snippet toch wel van een verhaaltje vergezeld moet worden, zal het even duren voor al die snippets toegevoegd zullen zijn. Mijn streven is er in ieder geval dagelijks 1-2 toe te voegen.

Ben je op zoek naar specifieke snippets? Geef het hieronder aan in het commentaar en ik zal kijken of ik hieraan prioriteit kan geven.

Voornamelijk WooCommerce

Het zal je ongetwijfeld opvallen, dat het grootste aantal snippets in de snippet base betrekking hebben op WooCommerce. Dat is niet helemaal zonder reden. WooCommerce is een prachtig e-commerce platform, maar het heeft ook zo zijn beperkingen. Je kan immers niet iedere gebruikerswens in zo’n groot pakket stoppen. Dat is ook één van de redenen, dat WordPress een plugin architectuur heeft.

Maar om voor WooCommerce voor iedere tweak een aparte plugin te installeren… dat is echt teveel overhead en dat zou WooCommerce een nog veel zwaardere plugin voor WordPress maken, dan het al is.

In het verleden heb ik meer dan eens voor klanten met een ’trage WooCommerce’ WooCommerce behoorlijk wat sneller kunnen maken, door een aantal plugins te verwijderen en de functies van die plugin direct in de site te implementeren.

Een aardig voorbeeld is bijvoorbeeld met ‘checkout velden’. Er zijn diverse plugins voor WooCommerce checkout velden beschikbaar. Plugins waarmee je velden kan toevoegen, verwijderen en verplichte velden niet verplicht, en niet verplichte velden verplicht maken. Door die plugin te verwijderen, maar via code dezelfde ’tweaks’ toe te passen, kun je de opbouw van je checkout pagina met 80-120 ms versnellen. Wat is 120 milleseconden, zal je je afvragen. Dat merk je toch niet?

Inderdaad. Maar als je nog meer van dit soort plugins kan verwijderen ten behoeve van een stukje custom code, dan worden 120 milliseconden er al snel 600 tot 1000. En een seconde verschil. Dat is merkbaar. Blader dus rustig door de snippet base en kijk eens hoe jij jouw website zou kunnen versnellen door bepaalde functies niet meer door een plugin, maar door een code snippet uit te laten voeren.

Of hoe je jouw gebruikerservaring kan verbeteren door het implementeren van features waar je nog niet eens aan had gedacht!

Ben jij niet zo’n ‘codeertype’?

Blijf jij het liefst zo ver mogelijk van programmacode vandaan of doet een snippet net niet wat je wilt? Dan is er natuurlijk altijd nog de WordXPression Support Strippenkaart. Kleine codeer klussen (maximaal 2 uur) kunnen ook in het kader van de WordXPression Support Strippenkaart worden uitgevoerd.

Wist je trouwens, dat ook verschillende WordPress Professionals een strippenkaart hebben lopen bij WordXPression? Ben jij een WordPress Professional, maar is design meer jouw ding dan coderen, dan kan je helemaal ‘white label’ via een support strippenkaart codeerdiensten van WordXPression inroepen.