De WooCommerce Troubleshooting Gids

Wat te doen, als WooCommerce er een rommeltje van lijkt te maken…

WooCommerce is een krachtig platform voor het online verkopen van je producten, maar af en toe kan dit platform een aantal problemen opleveren. In dit artikel wil ik nader ingaan op een aantal vaak- tot af en toe voorkomende technische problemen die in principe makkelijk zelf te verhelpen zijn, wanneer je maar weet waarnaar je moet kijken.

Vandaar dat ik hier voor je een eenvoudige ‘WooCommerce Troubleshooting Gids’ heb opgesteld. En regelmatig zal ik hier problemen die ik in de praktijk tegenkom hier aan toevoegen.

Ik wil hierbij niet ingaan op specifieke WordPress problemen -maar ook hierover kan je oplossingen vinden op deze site- en ook niet op meer functionele problemen van WooCommerce. Veel van de laatste kan je vinden in blogartikelen over specifieke woocommerce plugins en ook in de WordXPression snippetbase is hier heel wat over terug te vinden.

WooCommerce Tools en WooCommerce Status

Gelukkig helpt WooCommerce je al met een aantal krachtige gereedschappen, die standaard deel uitmaken van de WooCommerce plugin. In het WP Admin dashboard vind je onder ‘WooCommerce’ de ‘Status’ optie. En onder deze optie vind je ‘Systeem Status’, ‘Gereedschappen’, ‘Logs’ en ‘Geplande acties’.

Vervolgens krijg je een scherm te zien, wat op het onderstaande lijkt:

Onder de eerste tab (systeemstatus) zie je de verschillende instellingen van WordPress en WooCommerce. De instellingen die aanpasbaar zijn (de meeste echter wel buiten WordPress zelf om) kunnen een kleur hebben: Groen is goed, Geel/Oranje is ‘Liever niet, maar hoeft niet gelijk verholpen worden’ en rood wil meestal zeggen, dat er sprake is van een fout die van negatieve invloed kan zijn voor de goede werking van WooCommerce. Als je problemen hebt, zijn dit zeker de eerste zaken die je op wilt lossen. Meer informatie over de Systeem Status en de betekenis van de verschillende velden vind je in ‘Understanding the WooCommerce System Status Report‘

De tweede tab ‘Gereedschappen’ is echter veel interessanter en zal je waarschijnlijk vaker gebruiken, wanneer je problemen hebt.

Ook de logs zal je bij problemen regelmatig willen raadplegen. De tab ‘geplande acties’ is meer voor de gevorderde gebruiker. Hier kan informatie worden gevonden voor het oplossen van complexere problemen en valt buiten de scope van de WooCommerce Troubleshooting Gids.

Nu je weet waar je de tools kan vinden om je problemen op te lossen, duiken we nu de daadwerkelijke Troubleshooting Gids in.

Enkele afspraken om misverstanden te voorkomen.

In WooCommerce kan je zelf bepalen hoe je de verschillende ‘standaard pagina’s’ wilt noemen. In onderstaande problemen en oplossingen wordt soms naar deze pagina’s/ URL’s verwezen. Om duidelijk te zijn over welke pagina hoe genoemd wordt, heb ik hieronder een screenshot van deze pagina’s met daarnaast in het rood de namen die verder in deze WooCommercce Troubleshooting Gids gebruikt zullen worden.

Wanneer ik bijvoorbeeld aangeef, dat je iets met de /cart/ URL moet doen, en bij jou die URL ‘winkelwagen’ heet, vervang je voor de URL op jouw site /cart/ door /winkelwagen/.

1. Bij het plaatsen van een product in een winkelwagen via een directe URL, krijg je de melding ‘Dit product kan niet worden gekocht’.

Of een variatie op deze melding. Afhankelijk van de taalinstellingen en of je het standaard taalbestand gebruikt.

Wat doen we hier?

Bij een ‘standaard’ gebruik van WooCommerce zal deze melding niet voorkomen. Maar wanneer je WooCommerce ‘op de achtergrond’ gebruikt, en direct product ID’s meegeeft aan knoppen of andere aanklikbare pagina elementen, dan is het mogelijk dat je een dergelijke foutmelding krijgt.

Een aardig voorbeeld van wat ik bedoel -zonder de foutmelding dan- is bijvoorbeeld mijn pagina om een supportstrippenkaart te kopen. In plaats van een gewone winkelpagina laat ik een prijstabel zien.

Klik je op één van de knoppen, wordt het product direct in je winkelwagen geplaatst. Dat kan je doen, door een specifieke URL op te geven.

https://wordxpression.nl/afrekenen/?add-to-cart=123456

Het eerste deel van de URL is natuurlijk de website.

‘Afrekenen’ is de /checkout/ pagina, die bij mij ‘afrekenen’ heet, en het laatste deel geeft het product aan.

Nu kan je van alles fout doen in deze URL. Maar bij de meeste zaken die je fout doet, krijg je of een ‘404 – pagina bestaat niet’ melding, of je gaat naar de afrekenpagina toe, maar er zit niets in je winkelwagen. Dat zijn allemaal fouten die direct en makkelijk op te lossen zijn, door de URL nog eens goed te controleren. Maar wanneer je de melding krijgt ‘Dit product kan niet worden gekocht‘, dan is de situatie iets minder voor de hand liggend.

Wat er hier namelijk aan de hand is, is dat het product wel bestaat, maar het letterlijk ‘niet gekocht’ kan worden. Heb je voorraadbeheer voor WooCommerce aan staan en is de voorraad daadwerkelijk op, dan is het ook duidelijk: Het product kan letterlijk niet worden gekocht. Maar wat, wanneer het een virtueel product is -voorraad oneindig dus- of een product waarvan je nog voorraad genoeg hebt?

De tweede reden waarom deze melding kan worden gegeven is omdat het product geen prijs heeft. En dan bedoel ik dus niet ‘0 euro’, maar het prijsveld daadwerkelijk leeg is.

Als dat ook netjes is ingevuld en de melding blijft kan er nog een aantal andere zaken aan de hand zijn. WooCommerce roept namelijk een functie aan

$product->is_purchasable()

En die geeft ‘true’ of ‘false’ terug. En hierbij wordt een aantal zaken gecontroleerd:

• Is het product gepubliceerd (en dus geen concept)?
• Is de status ongelijk aan ‘uitverkocht’?
• Is de voorraad groter dan 0, of is ingeschakeld, dat backorders toegestaan zijn?

Wanneer al deze zaken in orde zijn -en dat kan je zelf vrij makkelijk checken- is de laatste controle of het product geassocieerd wordt met een prijs.

Geassocieerd worden met een prijs is niet hetzelfde als de prijs die je hebt ingevuld. Afhankelijk van coupons, speciale aanbiedingsperioden en eventuele andere extra plugins die de prijs kunnen bepalen -denk bijvoorbeeld aan staffelkortingen- kan die prijs aangepast worden. Omdat -vooral bij productoverzichten- het bepalen van de uiteindelijke prijs heel wat rekenwerk kan zijn, worden de uiteindelijke prijzen in een aparte tabel opgeslagen. En daar kunnen een paar dingen fout gaan.

Wanneer je bijvoorbeeld een prijs niet invult, en de kortingsprijs wel, met een bijbehoren periode, dan zal het product binnen die kortingsperiode gewoon een prijs hebben, maar voor die kortingsperiode of na afloop daarvan niet meer. En omdat het product geen prijs heeft, zal die functie $product->is_purchasable() geen bedrag teruggeven. En in zo’n geval wordt dus de foutmelding gegeven, dat het product niet verkocht kan worden.

Wanneer je extra plugins gebruikt kan iedere plugin die een invloed op de prijsberekening heeft op een vergelijkbare manier er voor zorgen, dat je een ‘lege’ prijs terugkrijgt.

Kijk dus goed bij een product of in alle velden waar een prijs verwacht wordt, die prijs ook daadwerkelijk is ingevuld.

Maar dit zijn allemaal ‘fouten’, die makkelijk voorkomen kunnen worden, door gewoon goed het product na te lopen. Krijg je deze melding, dan check je dus of het product daadwerkelijk gepubliceerd is, of het product niet uitverkocht is, en indien je voorraadbeheer gebruikt, of er nog voorraad is. Tenslotte loop je alle ‘prijsvelden’ in het product na.

Is dat allemaal in orde, en het werkt nog steeds niet, dan is er nog andere mogelijke oorzaak. Zoals aangegeven, worden de berekende prijzen in een aparte -onzichtbare- tabel opgeslagen. En daarbij kan wel eens wat fout gaan. Bijvoorbeeld door een foutje in een plugin, of een storing van het systeem: Je krijgt een 500 error, of de server gaat down. En hierdoor kan die tijdelijke tabel ‘kapot’ gaan, en kunnen bepaalde bedragen niet meer gevonden worden. In zo’n geval kan je vrij eenvoudig de tabel opnieuw laten vullen. En dat kan dus via de ‘Tools’ voor WooCommerce die ik hierboven heb besproken.

Je gaat naar de ‘Gereedschappen’ tab en klikt op ‘Transients Wissen’ achter ‘WooCommerce Transients’. Hierdoor wordt deze tabel met berekeningen leeggemaakt, en bij iedere opvraag van het product met verse informatie gevuld.

2. De prijs in het Dashbord en de prijs op de site wijken onderling af

Je hebt een prijs aangepast, je kijkt op je site en -grote schrik- de prijzen wijken van elkaar af. Hoe is dat mogelijk? De meest waarschijnlijke oorzaak is dat het een caching probleem is. En hierbij kan je nog een verschil maken tot de ‘browser cache’ en de ‘server cache’.

Browser cache

Om pagina’s snel te kunnen laden, slaat de browser (elementen van) die pagina op op je PC, telefoon of tablet. Dus de eerste keer wordt hij van het internet geladen, maar de keren daarna wordt dit geladen van je computer. Na een bepaalde tijd -die vaak als ‘suggestie’ door de server wordt meegegeven aan de browser- zal er weer opnieuw gekeken worden of de pagina aan vernieuwing toe is. Klopt je pagina niet met wat het had moeten zijn, kan je als eerste stap CTRL-F5 (Windows/Linux) of CMD-Shift-R (Mac) ingeven. Dan wordt de pagina ‘gedwongen’ opnieuw geladen. Let er wel op, dat je hiermee alleen voor jezelf de pagina opnieuw laadt. Heeft een andere bezoeker ook een oude versie in zijn browsercache, dan blijft hij de oude pagina zien.

Server cache

Een WordPress pagina wordt niet als pagina opgeslagen, maar bij iedere opvraging opnieuw opgebouwd uit code en gegevens in de database. Dat is een proces wat aardig wat tijd kan kosten, en daarom wordt ook aan de serverkant een gecachte versie van de pagina aanwezig. Om zo’n pagina te cachen gebruik je een zogenaamde ‘caching plugin’. Iedere caching plugin heeft een aantal instellingen, waarmee je het gedrag van de plugin kan bepalen, en de mogelijkheid de cache in zijn geheel leeg te maken, of een bepaalde pagina uit de cache te verwijderen. Vaak wordt dit ‘flushen’ of ‘purgen’ genoemd.

Je wilt niet dat alle pagina’s gecached worden. Pagina’s als ‘/my-account/’, ‘/cart/’ en ‘/checkout/’ zijn pagina’s die niet gecached mogen worden. Gelukkig kan je bij caching plugins ook aangeven wat niet gecached moet worden. Daar vul je dus deze pagina’s in, met daarachter een asterisk (‘sterretje’), dus bijvoorbeeld:

/my-account/*
/cart/*
/checkout/*

Dat sterretje geeft aan, dat niet alleen die url niet gecached moet worden, maar ook alles wat daarachter komt.

En nogmaals, de transients

En net zoals bij het eerste probleem, waar je de producten niet te zien kon krijgen door missende prijzen, kan er door een crash natuurlijk ook een foute prijs in de prijstabellen terecht zijn gekomen. De meest waarschijnlijke oorzaak is een caching probleem, maar als alle pogingen niet helpen, dan is het ook mogelijk, dat je -net zoals onder punt 1- de transients zal moeten verwijderen via de WooCommerce tools.

3. WooCommerce mail wordt niet verzonden of komt niet aan

Wordt je WooCommerce mail niet verzonden? Daar heb ik al enkele jaren geleden een blogartikel over geschreven onder de titel ‘Wat te doen wanneer je WooCommerce mail niet aankomt‘ en begin 2025 voor het laatst bijgewerkt. Hier wordt heel uitgebreid aangegeven wat je kunt doen wanneer je mail niet wordt verzonden, of niet aankomt.

4. Melding ‘Nonce vertification failed’ op winkelmand of checkout

Dit is geen fout, maar een beveiliging. Een nonce in WordPress/WooCommerce is een tijdelijk, uniek beveiligingstoken dat gebruikt wordt om te controleren of een verzoek (bijv. “voeg toe aan winkelmand”, “update adres”, “plaats bestelling”) écht afkomstig is van een legitieme gebruiker op jouw site, en niet van een bot, hacker of kwaadwillende externe site.

Dit beveiligingstoken heeft een beperkte geldigheidsduur. Is deze geldigheidsduur afgelopen, dan kan je niet meer verder gaan in het proces en moet je opnieuw beginnen. Het is overigens wel zo, dat die geldigheidsduur best lang is. Maar onderbreekt iemand het bestelproces, bijvoorbeeld omdat hij wordt afgeleid om iets anders te doen, dan kan hij tegen deze melding aanlopen.

5. Orders blijven hangen in de ‘pending payment’ status, terwijl de klant toch betaald heeft

Deze foutsituatie ken ik alleen van Stripe, maar dit kan in principe ook bij andere betaalproviders gebeuren. De oorzaak is dat de betaalprovider een boodschap naar de server door wil geven, dat de betaling is afgerond. Dit bericht wordt echter niet verwerkt. De mogelijke oorzaken met de oplossing zijn

Conflicten met de firewall

Wanneer je een firewall gebruikt, is het mogelijk dat het antwoord geblokkeerd wordt door die firewall. Je kunt dit oplossen door de IP adressen van de betaalprovider te ‘whitelisten’. Normaal gesproken zal er ergens in de handleiding van de betaalprovider aangegeven worden, wat de mogelijke IP adressen kunnen zijn, anders kan je deze bij hun helpdesk opvragen.

Specifiek voor Varnish caching, maar mogelijk ook van toepassing op andere caching diensten: De antwoord URL is gecached

De URL’s die verantwoordelijk zijn voor het antwoord zijn gecached. Dus in plaats van een script aan te roepen wat antwoord geeft, wordt een ‘oud’ antwoord opgehaald uit de cache. Wanneer je tegen dit probleem aanloopt, kan je het best iemand met ervaring met Varnish cache erbij halen, omdat hier in het configuratiescript van Varnish zelf zaken gewijzigd moeten worden. Dat is geen ‘beginnerstaak’.

In dat script (vcl_recv) zet je

sub vcl_recv {
    # WooCommerce API no-cache
    if (req.url ~ "^/wc-api/") {
        return (pass);
    }

    # WordPress REST API no-cache
    if (req.url ~ "^/wp-json/") {
        return (pass);
    }
}

Wordt vervolgd

In de komende weken zal aan deze WooCommerce Troubleshooting Guide een aantal nieuwe problemen met oplossing worden toegevoegd. Heb jij een technisch probleem met WooCommerce en ben je op zoek naar een oplossing, dan kan je in het commentaar hieronder je probleem vermelden. Heb je een probleem, en je hebt het inmiddels opgelost, en je wil dit met de wereld delen, dan kan je dit ook hieronder in de commentaren vermelden.

Heb je een probleem en het urgent, dan kan de WordXPression supportstrippenkaart een goede manier zijn om dit probleem op te laten lossen.