Zo los je de 4 meest voorkomende WordPress-fouten op

Matthias Held Laatst bijgewerkt op 07.10.2020
14 Min.
WordPress  Fout
Laatst bijgewerkt op 07.10.2020

Bij de support voeren we duizenden chatgesprekken per maand en helpen we onze klanten elke dag bij het oplossen van foutmeldingen en problemen met hun WordPress-pagina's. In ons artikel laten we je stap voor stap zien hoe je vier van de meest voorkomende WordPress-fouten wegneemt.

Geen enkel ander Content Management Systeem (CMS) is zo eenvoudig te gebruiken als WordPress: themes en plugins kunnen met een paar klikken worden geïnstalleerd en beheerd, zonder dat er uitgebreide technische kennis nodig is. Met een marktaandeel van meer dan 30 procent is WordPress quasi het besturingssysteem van het internet geworden.

Vanwege de gemakkelijke bruikbaarheid, de actieve community en de verschillende mogelijkheden om je pagina's te individualiseren is WordPress perfect voor het huidige web. Des te groter is de frustratie wanneer jouw WordPress plotseling problemen veroorzaakt. Maar geen reden tot paniek! Vandaag ga ik je laten zien hoe je vier typische WordPress-fouten snel, gemakkelijk en zelfstandig opllost.

Onze tips voor het oplossen van typische WordPress-fouten

Om je zo goed mogelijk bij het oplossen van problemen te ondersteunen en om de kennis uit onze jarenlange support-ervaring te delen, zal ik nu de mogelijke oorzaken en de bijbehorende oplossingen voor vier typische WordPress-problemen uitleggen.

WordPress-fout #1: White Screen of Death

WordPress -Fout: Wit scherm van de dood

Het "White Screen of Death" (WSOD) is een analogie van het Blue Screen of Death, dat in Windows bij een systeemcrash weergegeven wordt. Zoals de naam al zegt, blijft bij de WSOD de website, in de Frontend of Backend (wp-admin), gewoon wit - zonder foutmelding of verdere informatie.

Mogelijke oorzaken en oplossingen voor White Screen of Death

Oorzaak 1: Onverenigbare plugins of themes

De fout wordt vaak veroorzaakt door een verkeerde combinatie van plugins of themes, zoals bijvoorbeeld:

  • Een plugin is niet met een andere plugin of met het actieve theme compatibel.
  • Een plugin/theme werd twee keer geüpload via S/FTP in verschillende versies.
  • Aan plugin/theme is niet bruikbaar met de ingestelde PHP-versie.

Door een van deze fouten wordt WordPress verlamd en lokt het het White Screen of Death uit.

Zo los je de 4 meest voorkomende WordPress-fouten op
Probleemanalyse: zijn jouw plugins en themes niet compatibel?

De eerste benadering is het terugdraaien van de recente veranderingen. Denk na over welke veranderingen je hebt aangebracht. Misschien heeft u een nieuwe Plugin geinstalleerd of een Theme veranderd? Updates van Plugins en Themes kunnen ook dit gedrag veroorzaken.

Eerst moet je bepalen of de fout op alle of alleen op bepaalde pagina's voorkomt. Is bijvoorbeeld alleen je contactpagina getroffen? Als je net een contactformulier op die pagina hebt gezet, is het waarschijnlijk dat de plugin voor het contactformulier verantwoordelijk voor de WSOD is.

Verschijnt het White Screen of Death in de hele frontend op alle URL's? Dan kan dit het theme zelf of een plugin zijn die op alle pagina's is geïntegreerd - bijvoorbeeld een widget in de footer, een slider in de header of een plugin voor de navigatie.

Als het zelfs in de backend (yoursite.com/wp-admin) wit blijft, ligt het hoogstwaarschijnlijk aan het theme of aan een misconfiguratie van de webserver.

Controleer je debugging-log!

Vaak helpt een kijkje in de error.log van je server of de debugging-log WordPress zelf (WP-DEBUG). Je kunt deze activeren door de wp-config.php van je WP-installatie te bewerken en voor /* That’s all, stop editing! Happy blogging. */ volgende regels in te voegen:

define ('WP_DEBUG', true);

define ('WP_DEBUG_DISPLAY',true);

Als jouw installatie al een 'WP_DEBUG'-ingang heeft, maar deze is ingesteld op false kun je deze waarde eenvoudigweg instellen op true en hoef je er alleen maar de volgende regel onder te plaatsen:

define ('WP_DEBUG_DISPLAY',true);

Wanneer je dan opnieuw je probleempagina oproept, zie je de overeenkomstige redenen voor fouten in plaats van de witte pagina. De fouten die beginnen met Fatal of Parse-Error zijn meestal de fouten die het White Screen of Death veroorzaken.

Trouwens: bij RAIDBOXES kun je de debuggingslog eenvoudig met één klik in je BOX-instellingen instellen. Je kunt de output van de debug-log verkrijgen onder de link die vermeld staat in jouw instellingen.

WP Debug_RAIDBOXES

Nu kun je precies zien welk bestand op welke positie een fout genereert en waarom dit gebeurt. Ter illustratie geef ik je een voorbeeld.We zien hier in de Parse-Error de volgende informatie:

Debuggeren van het logboek

Dus de fout treedt op:

  • In het bestand /wp-content/plugins/contact-form-7/wp-contact-form-7.php
  • In regel 12
  • Blijkbaar is er daar een onverwacht teken, in dit geval een "<".
Bij incompatibele plugins & themes zijn er de volgende oplossingen:

Oplossing 1: Als je dat kunt, herstel dan een back-up. Dit zet je WordPress-installatie gewoon in de staat waarin deze zich bevond voordat de fout zich voordeed.

Oplossing 2: Als je geen back-up hebt, zit er niks anders op dan via S/FTP de map van de verdachte plugin of theme een andere naam te geven. Daardoor wordt hij gedeactiveerd. In ons voorbeeld zou het de map van de plugin "Contact Form 7" zijn.

Als je niet zeker weet welke plugin de fout veroorzaakt, probeer dan het volgende: verander alle plugin/thememappen één voor één van naam. Als de fout verdwijnt na het hernoemen van een map, heb je de boosdoener geïdentificeerd. Als RAIDBOXES-klant kun je voor deactivering ook gewoonweg het plugin- en themebeheer in het RB-dashboard gebruiken 

Tip: Vaak is het probleem gewoon een hernoemde theme-map, dus je moet hem via S/FTP op de juiste spelling controleren!

Zo los je de 4 meest voorkomende WordPress-fouten op

Oorzaak 2: Serverfout

1) Probleem: te weinig PHP Memeory Limit

De typische foutmelding in het error.log is
"Fatal error: Allowed memory size of XXXX bytes exhausted (tried to allocate XXXX bytes) in…”

Bovendien kan er een witte pagina zijn waarop de foutmelding Interne serverfout verschijnt.

Wat hier gebeurt is het volgende:
Een PHP-taak verbruikt meer werkgeheugen dan de door de hoster ingestelde waarde toestaat.

Oplossing: In dit geval is het meestal voldoende om de volgende regel toe te voegen aan wp-config.php

define('WP_MEMORY_LIMIT', '256M')

De '256M' staat voor de verbruikte hoeveelheid RAM in MB. Zo zou bijvoorbeeld ook '512M' voor 512MB denkbaar zijn.

Je moet er echter rekening mee houden dat een te hoge waarde een volledige crash van je site kan veroorzaken. Daarom moet je je PHP-geheugenlimiet alleen verhogen als je tarief de juiste hoeveelheid werkgeheugen biedt. Als je weinig RAM in je tarief hebt, moet je overwegen om je tarief te upgraden bij je hoster.

2) Probleem: Max Execution Time overschreden

Bij het installeren van grotere WordPress-themes of -plugins of bij grotere invoer of uitvoer van gegevens kan de volgende fout optreden, die meestal in de backend wordt weergegeven:

Fatal Error: Maximum Execution Time of XX Exceeded in XXX

Dit betekent: de tijd die een PHP-script mag draaien, is overschreden. Dit gebeurt vaak bij het importeren van veel producten in WooCommerce of het exporteren van bestelgegevens.

Oplossing: verhoog de max_executie_time. Een opmerking vooraf: normaal gesproken is de door de hoster opgegeven looptijd voldoende. Om onnodig lange laadtijden en problemen te voorkomen, moet de Max Execution Time alleen in bijzondere gevallen worden verhoogd (bijv. voor een grote bestandsupload) en vervolgens weer worden verlaagd.

Bij RAIDBOXES kun je via de BOX-instellingen de max_execution time voor de frondtend en de backend afzonderlijk instellen:

Max. uitvoeringstijd

Bij andere hosters is het vaak voldoende om de .htaccess via S/FTP te bewerken en de regel php_value max_execution_time 300 in te voegen. Hier staat de 300 voor het maximum aantal seconden dat een script mag draaien. In dit geval vijf minuten.

WordPress-fout #2: Problemen met SSL

WordPress -Fout_SSL

Sinds de inwerkingtreding van de Algemene verordening gegevensbescherming (AVG) in mei 2018 zou een SSL-certificaat verplicht moeten zijn voor jou. Het is niet voor niets dat de meeste browsers nu een waarschuwingsbericht afgeven, als een webpagina niet versleuteld geleverd wordt. Dit maakt het des te vervelender als jouw WordPress-site SSL-fouten heeft.

Mogelijke oorzaken en oplossingen voor SSL-problemen

Oorzaak 1: Certificaat niet meer actueel

Uiterlijk met de gratis certificaten van Let's Encrypt zou deze fout tot het verleden moeten behoren. Er zijn echter bepaalde typen certificaten die een looptijd hebben. Als deze is verlopen, kan er mogelijk een SSL-fout optreden.

Oplossing: De eenvoudigste manier is om een SSL-certificaat te integreren zonder uitvoertijd, wat sommige hosters zoals ook RAIDBOXES gratis leveren en automatisch verlengen Als deze service niet wordt aangeboden door jouw hoster, zul je handmatig een certificaatvernieuwing moeten aanvragen. De beste manier om dit te doen is om een afspraakherinnering aan te maken en tijdig contact op te nemen met de leverancier van je certificaat om het te verlengen.

Oorzaak 2: Domein nog niet op het certificaat geregistreerd

Wanneer een SSL-certificaat wordt uitgegeven, leg je vast voor welke domeinen dit certificaat van toepassing moet zijn. Een mogelijke vermelding zou http://domain.nl kunnen zijn. Als er achteraf nog een omleiding van http://www.domain.nl wordt ingesteld, heeft dit domein geen SSL en wordt er een fout weergegeven.

Oplossing: Het nieuwe domein moet worden toegevoegd aan het SSL-certificaat en vervolgens worden vernieuwd. Aangezien dit een nogal moeizaam en ingewikkeld proces is, moet je hiervoor contact opnemen met je hostingprovider.

Bij RAIDBOXES is het genoeg om na het toevoegen van de extra domeinen in de BOX-instellingen de SSL uit en weer aan te zetten.

Oorzaak 3: Mixed Content Fout

Indien in WordPress SSL ingesteld is, moet standaard het http:// adres in de database worden vervangen door https://. Bij RAIDBOXES gebeurt dit automatisch wanneer SSL is ingeschakeld. In ongeveer 5-10 procent van de gevallen kan het toch gebeuren dat er nog delen via HTTP geladen worden. Dit kan het geval zijn bij bijvoorbeeld hardcoded images of CSS/JS-bestanden. In Chrome is de URL dan grijs en niet groen.

HTTPS-adresbalk Browser

Probleemanalyse en oplossing:

Eerst moet je controleren of je echt mixed-content-fouten op je site hebt.

  1. Druk op je website op F12 (op de MAC CMD+F12) en de ontwikkelaarsconsole wordt geopend. Onderaan in de "Console" verschijnen gele velden met "Mixed Content":
    Gemengde inhoud Fout
  2. Maak nu een back-up van je pagina. Je kunt dit bij RAIDBOXES eenvoudigweg in je BOX-backups in het dashboard doen.
  3. Installeer de plugin Better Search Replace. Na activering vind je de plugin onder "Hulpmiddelen" -> "Better Search Replace".
    In het veld "Zoeken naar" voer je in: http://
    en in "Vervangen door": https://
    Dan selecteer je alle tabellen in het tabelveld en onderin bij "Testrun?" moet een vinkje staan.
    Better Search Replace

    Klik nu helemaal onderaan op "Start zoeken/vervangen".
  4. Wanneer de testrun een aantal tabellen heeft gevonden, kun je het vinkje bij "Testrun?" weghalen en de echte run starten.
  5. Controleer na afloop van de echte run nogmaals op de pagina of je nog steeds Mixed-Content-fouten hebt (zie stap 1).
  6. Als er nog steeds Mixed-Content-fouten voorkomen, controleer dan de broncode of de bronnen nog steeds met "http" in plaats van "https" geïntegreerd zijn en vervang ze.

WordPress-fout #3: 504 Gateway time-out

WordPress -Fault_Gateway-Timeout

Een 504 gateway time-out-fout kan heel vaak voorkomen als je een groot aantal plugins hebt die ook met externe diensten communiceren. De foutmelding betekent dat een PHP-proces langer dan 30 seconden nodig heeft.

Als websitebeheerder wordt de fout vaak direct in verbinding gebracht met een probleem op de server. Dit is echter niet altijd het geval.

Mogelijke oorzaken en oplossingen voor 504 gateway time-out

Een 504 Gateway Time-Out Error treedt op wanneer een server die als gateway fungeert, d.w.z. de server die verbinding met een andere server maakt, juist deze andere server niet binnen een bepaalde tijd kan bereiken.

Deze fout kan door verschillende elementen worden veroorzaakt. Het kan je lokale netwerk zijn, je browser, je ISP (Internet Service Provider), je webserver, of zelfs een externe plugin- of theme-aanbieder.

Oorzaak 1: Lokaal probleem

Browserinstellingen gewijzigd, een proxy geactiveerd, je internetprovider heeft problemen, je lokale DNS-cache is verouderd en vele andere mogelijkheden kunnen deze fout veroorzaken.

Oplossing:  Test de URL op de website http://www.isitdownrightnow.com/voor die tijd. Als je het bericht ontvangt dat de website online is ("YourUrl.com" is UP en bereikbaar), is er een lokaal probleem.

Server Status Check_Up

Maar als het resultaat van de test "YourUrl.com" DOWN is, dan wijst dit op een probleem met je DNS, je webserver of een WordPress-plugin of theme.

Server Status Check_Down

Oorzaak 2: DNS-problemen

Het DNS (Domain Name System) is verantwoordelijk voor het omzetten van jouw URL (zoals raidboxes.io) naar een IP (bijv. 94.130.145.82).

In het geval van een nieuwe registratie of een domeinverhuizing kan het enige tijd duren voordat alle computers, DNS-servers en providers de aanpassing hebben herkend. Dit kan tot 24 uur duren.

Oplossing: Eerst moet je kijken of er een lokaal probleem is. Leeg daarvoor je DNS-cache:

Om je DNS-cache op je apparaten te wissen, open je eerst als volgt je opdrachtregel.

  • Windows: Druk op [Windows-toets + R], daar cmd invoeren en op Enter drukken
  • Mac: Start de terminal via het Dock bij Programma's > Dienstprogramma's > Terminal

Dan voer je het volgende in:

  • Windows: ipconfig /flushdns
  • Mac: dscacheutil -flushcache

Daarna is je lokale DNS-cache leeg en kun je het opnieuw proberen.

Als de fout blijft bestaan, kijk dan wat andere servers in de wereld erover te zeggen hebben. Om dit te doen ga je naar www.whatsmydns.net en voer de URL in de zoekregel in (Opmerking: zorg ervoor dat "A" is geselecteerd in het tweede selectieveld, zodat alleen het A-record gecontroleerd wordt. Deze is verantwoordelijk voor de juiste opheffing van de domeinnaam naar het IP-adres. Start dan de scan!

DNS-controle

Als het DNS-record op alle servers up-to-date is, zou je overal een groen vinkje en hetzelfde IP-adres moeten zien. Dit IP zou in de meeste gevallen moeten verwijzen naar het IP van je server (uitzondering: als een CDN voorgeschakeld is).

Als er fouten worden weergegeven in de vorm van een rode "X", heeft deze server nog niet de juiste vermelding. Als er verschillende IP's staan, heeft de server nog steeds de oude vermelding en is nog niet naar de nieuwe geactualiseerd. Hier helpt alleen afwachten.

Oorzaak 3: Serverprobleem (bijv. prestaties of hosters)

Bezoekersintensieve websites en e-commerce-sites zoals winkels die op WooCommerce draaien, genereren veel aanvragen naar de server, die niet kunnen worden gecached vanwege hun inhoud en dus tot een hoge serverbelasting leiden - tot aan het crashen van de server.

Oplossing: Als de prestaties van je hostingpakket niet voldoende zijn voor je website, kan het zijn dat je deze moet upgraden. Als alternatief is het vaak nuttig om over te stappen naar een ander hostingbedrijf waarvan de serverarchitectuur betere prestaties biedt. Je bent van harte welkom om met je WordPress-site een gratis testverhuizing naar RAIDBOXES uit te voeren. Jouw livepagina wordt in de werking niet gestoord, omdat je een volledig eigen omgeving krijgt met een eigen URL, die niet door zoekmachines wordt geïndexeerd. In meer dan 80 procent van de gevallen is er sprake van een aanzienlijke toename van de prestaties en een vermindering van de 504-fouten naar 0.

Oorzaak 4: Traffic-spam, DDOS-aanvallen, botaanvallen

DDOS-aanvallen en SPAM-verkeer kunnen je site laten crashen omdat ze zoveel (ongecachte) aanvragen genereren dat je server crasht.

Oplossing: Om dergelijke aanvallen te filteren, helpt vaak een CDN zoals Cloudflare, die de toegang tot je website filtert en spambots en aanvallen blokkeert. In zeer hardnekkige gevallen kun je de IP-adressen van de aanvallers voor toegang tot jouw website uitsluiten (blokkeren).

Met RAIDBOXES kun je dit gewoon via jouw BOX-instellingen regelen:

IP-blokkering_RAIDBOXES

Oorzaak 5: Problemen met plugins en themes

In individuele gevallen kunnen zeer lange aanvragen van plugins of themes tot 504 Gateway Time-Out-fouten leiden. Als je net een theme of plugin geüpdatet hebt, probeer ze dan eerst te deactiveren.

Bij RAIDBOXES kun je dit via je plugin/theme-instellingen in je BOX doen - zelfs als je niet meer in je WordPress-backend kunt komen.

RAIDBOXES _Plugin en Themebeheer

Als je bij andere hosters geen toegang tot je WordPress-backend hebt, kun je via S/FTP verbinding maken en in de map ../wp-content/Themes of ../wp-content/Plugins de corresponderende theme/plugin zoeken en de map herbenoemen. Hierdoor wordt het betreffende element automatisch gedeactiveerd.

Als je niet zeker weet welke plugin of theme het probleem veroorzaakt, schakel eerst over op een standaard-theme zoals twentyseventeen.

Als dit het probleem oplost, is het hoogstwaarschijnlijk te wijten aan het theme of aan de aansluiting van theme en plugins. Neem hiervoor contact op met de producent van het theme. Zo niet, deactiveer dan alle plugins en activeer ze een voor een totdat je het overeenkomstige "probleem-plugin" hebt geïdentificeerd.

Probeer dan om de plugin opnieuw te installeren. Als dat ook niet helpt, neem dan contact op met de plugin-maker.

WordPress-fout #4: Error Establishing a Database Connection

Error Establishing a Database Connection

De fout "Establishing a Database Connection" is de zwaarst mogelijke storing onder de WordPress-fouten. De foutmelding betekent dat je server geen toegang meer heeft tot de database of deze niet meer kan bereiken.

Je WordPress-database slaat bijna alle informatie op die je site nodig heeft om correct te kunnen werken. Niet alleen de inhoud van je pagina's en berichten, maar ook de inloggegevens van je gebruikers en plugin- en theme-instellingen worden in de database opgeslagen.

Alleen afbeeldingen, plugin- en theme-bestanden en WordPress-core-files worden niet opgeslagen in de database, maar in het bestandssysteem van je website, dat je bijv. via S/FTP kunt bereiken.

Mogelijke oorzaken en oplossingen voor Error Establishing a Database Connection

Dus als je site wit blijft en alleen de foutmelding "Error Establishing a Database Connection" verschijnt, kan je site geen verbinding maken met je database of ontbreekt de benodigde informatie of is deze niet correct. Meestal kun je in dit geval niet inloggen op de WordPress-backend.

Oorzaak 1: Onjuiste gegevens in WP-Config

Meestal is het gewoon onjuiste informatie over de databaseverbinding die de fout veroorzaakt. Deze fout treedt vaak op na een verhuizing naar een nieuwe server of hoster en is vrij eenvoudig te verhelpen:

Oplossing: Voor alle systeemrelevante fouten (en deze in het bijzonder!) dien je vooraf een back-up van je site te maken. Klanten bij RAIDBOXES maken gemakkelijk een handmatige back-up in hun BOX-back-ups. Bij andere hosters moet je eventueel de hele site of in ieder geval de bestanden die je wijzigt, vooraf lokaal opslaan.

Nu krijg je de informatie die nodig is om verbinding te maken met de database. Deze zijn:

  • Databasenaam (DB_NAME)
  • MySQL User Name (DB_USER)
  • MySQL User Password (DB_PASSWORD)
  • MySQL Hostname (DB_HOST) [Dat is de server].
  • Table Prefix ($table_prefix) [meestal 'wp_'].

Over het algemeen kun je deze informatie vinden in het dashboard van je hoster. Meestal is niet alle informatie nodig. Je hebt bijvoorbeeld bij RAIDBOXES alleen de Table Prefix nodig, omdat de overige gegevens automatisch worden gelezen en gecontroleerd.

Als je over de nodige informatie beschikt, download je via S/FTP de "wp-config.php" uit de rootdirectory van je WordPress-installatie, maak je er een lokale kopie van als back-up en bewerk je het origineel met bijv. Notepad++.

Daar vind je de volgende regels (let op: $table_prefix wordt niet in alle gevallen opgenomen):

WP-Config

Je vergelijkt deze informatie met de informatie die je zojuist hebt verkregen.

Sla deze wijzigingen op en laadt het bestand opnieuw in de rootdirectory van je server (overschrijf het originele bestand, je hebt al een lokale back-up).

Als de informatie nu correct is, zou je je website weer normaal moeten kunnen gebruiken.

Oorzaak 2: Defecte database

Er kan een fout in je database zijn geslopen.

Oplossing: WordPress kan eventueel de database automatisch repareren. Ga hiervoor naar DEINEURL.de/wp-admin. Als je hier ziet dat je database kan worden gerepareerd, voeg dan direct voor “/* That’s all, stop editing! Happy blogging. */” de volgende regel toe in de WP-Config:

define('WP_ALLOW_REPAIR',true);

Ga dan naar DEINEURL.de/wp-admin/maint/reparatie.php.

Als dit je problemen heeft opgelost, vergeet dan niet om de regel weer uit de wp-config.php te verwijderen.

Oorzaak 3: Problemen met je hoster

Onder bepaalde omstandigheden is de SQL-server down en niet bereikbaar. Mogelijk is ook een maximum met betrekking tot de omvang van de database bereikt. Of de ressources van je hosting provider zijn opgebruikt.

Helaas is dit vaak het geval bij Shared Hosting. Want daar deel je een server met veel andere websites. Als er daar een site veel ressources gebruikt, gaat dit natuurlijk ten koste van jouw site. Om deze reden raden wij je altijd een speciaal op WordPress aangepaste High-Performance-Hostingaan, om dergelijke overbelastingen te voorkomen.

Oplossing: Neem contact op met je hostingprovider of controleer hun statuspagina (indien beschikbaar) om te zien of er momenteel problemen zijn met de server. Laat indien nodig de CPU-belasting van de provider zien en schakel over op een andere server als de last te hoog is. Als dit geen verbetering oplevert, moet je overwegen om naar een andere hoster over te stappen.

Conclusie

Iedere WordPress-gebruiker kent het gevoel van paniek als je plotseling naar een wit scherm staart of niet meer in de WordPress-backend kunt inloggen. Het belangrijkste is om het hoofd koel te houden, de oorzaak systematisch te achterhalen en vervolgens de juiste stappen te nemen om het probleem op te lossen. Ik hoop dat dit artikel je in de toekomst zal ondersteunen bij het analyseren en herstellen van deze typische WordPress-fouten.

Met welk WordPress-probleem heb je tot nu toe het meest te maken gehad? Geef je feedback in de commentaren.

Matthias is Chaos Calmer bij RAIDBOXES. Als plugin- en theme-ontwikkelaar, WordCamp Speaker en actieve Hosting Community Contributor is hij regelmatig op WordCamps en andere evenementen, die voor WordPress relevant zijn, te vinden en is hij altijd klaar voor een hapje en een drankje. Als hij daar niet is, zitten er katten op zijn schoot.

Gerelateerde artikelen

Commentaar op dit artikel

Schrijf een opmerking

Je e-mail adres wordt niet gepubliceerd. Verplichte velden zijn met * gemarkeerd.