Een klant belde me op omdat zijn contactformulier “soms wel en soms niet” werkte. Niks veranderd aan de site, zei hij. Gewoon ineens traag, en af en toe een witte pagina. Na tien minuten graven bleek zijn database 4,2 gigabyte groot. Voor een site van acht pagina’s en een blog met veertig posts. Dat is geen hostingprobleem. Dat is rommel die zich jarenlang heeft opgestapeld.
Dit overkomt bijna elk WordPress-project dat niet actief wordt onderhouden. De site werkt prima, niemand kijkt ernaar om, en ondertussen groeit de database gestaag door. Totdat het fout gaat.
Wat er allemaal in die database terechtkomt
WordPress slaat meer op dan je denkt. Elke pagina die je bewerkt, maakt een revisie aan. Sla je een post tien keer op, dan staan er tien versies van in de database. Doe dat met veertig posts en tien pagina’s over een paar jaar, en je hebt al gauw honderden revisies die niks meer doen.
Dan zijn er de transients. Dat zijn tijdelijke gegevens die plugins opslaan in de database in plaats van in een apart cachebestand. Ze horen automatisch te verlopen, maar de opruimroutine werkt niet altijd even betrouwbaar. Verlopen transients blijven gewoon staan.
Plugins laten ook hun eigen rommel achter. Een plugin die je drie jaar geleden hebt verwijderd, heeft waarschijnlijk tabellen in je database achtergelaten. WordPress verwijdert die niet automatisch. En formulierplugins slaan standaard elke inzending op, inclusief alle testberichten die je zelf hebt gestuurd tijdens het bouwen.
Hoe je de omvang in kaart brengt
Ga naar phpMyAdmin via je hostingpanel. Klik op je WordPress-database. Je ziet een lijst van alle tabellen met daarbij de grootte. Sorteer op grootte, van groot naar klein.
De tabellen waar je op let:
- wp_posts — bevat posts, pagina’s én revisies
- wp_postmeta — metadata bij al die posts, kan enorm oplopen
- wp_options — hier zitten de transients en plugininstellingen
- wp_commentmeta en wp_comments — bij sites met veel spam
Als wp_options groter is dan een paar megabyte, heb je waarschijnlijk een transientprobleem. Als wp_posts onverwacht groot is, zijn het revisies. Dat zijn de twee meest voorkomende oorzaken.
Revisies beperken zonder alles te slopen
Je kunt het aantal revisies dat WordPress bewaart instellen via wp-config.php. Voeg deze regel toe:
define('WP_POST_REVISIONS', 5);
Dat beperkt het aantal revisies per post tot vijf. Bestaande revisies verwijdert dit niet, maar nieuwe ophoping stop je er wel mee. Voor de meeste mkb-sites is vijf meer dan genoeg. Je wilt zelden verder terug dan de laatste paar bewerkingen.
Bestaande revisies ruim je op met een plugin die daarvoor is gebouwd, of met een directe SQL-query als je weet wat je doet. Doe dit altijd met een verse back-up klaar staan. Een query op de verkeerde database is een klassieke manier om een middag kwijt te raken.
Transients opruimen
Verlopen transients verwijder je het makkelijkst via de databasebeheerder met een SQL-query. Maar eerlijk gezegd: als je niet gewend bent om rechtstreeks in de database te werken, gebruik dan een onderhoudsplugin die dit voor je doet. Er zijn er genoeg die een knop hebben voor “verwijder verlopen transients”. Dat is veiliger dan een query die je van internet hebt gekopieerd en niet helemaal begrijpt.
Wat je ook kunt doen: uitzoeken welke plugin die transients aanmaakt. Sommige plugins zijn berucht om het volstoppen van wp_options. Als je een plugin hebt die je eigenlijk niet meer gebruikt maar nog niet hebt verwijderd, is dit een goed moment.
Formulierinzendingen en andere plugindata
Contactformulieren die inzendingen opslaan in de database zijn handig als je een back-up wilt van berichten. Maar na een paar jaar heb je duizenden rijen met testberichten, spam die door het raster glipte, en echte berichten die allang zijn afgehandeld.
Ga na of je formulierplugin een instelling heeft voor automatisch verwijderen na een bepaalde periode. Stel dat in op dertig of zestig dagen als je de berichten toch via e-mail ontvangt. Je hebt de databaseversie dan niet nodig.
Kijk ook naar andere plugins die eigen tabellen hebben aangemaakt. Een back-upplugin die logs opslaat, een statistiekenplugin die elke paginabezoek wegschrijft, een plugin voor wachtwoordbeveiligde pagina’s die sessiedata bijhoudt. Al die tabellen groeien. Sommige ruimen zichzelf op, veel niet.
Een onderhoudsmomenten inplannen
Het probleem met databaseopruiming is dat het niet urgent voelt totdat de site traag wordt of een fout gooit. Dan is het al verder opgelopen dan nodig was.
Plan een vast moment in, bijvoorbeeld elk kwartaal, om de database door te lopen. Dat hoeft niet lang te duren als je het regelmatig doet. Een half uur per kwartaal is genoeg voor een gemiddelde WordPress-site.
Wat je elke keer doet:
- Controleer de totale databasegrootte en vergelijk met de vorige keer
- Verwijder verlopen transients
- Ruim oude revisies op als het er meer dan een paar honderd zijn
- Controleer of er tabellen staan van plugins die je niet meer gebruikt
- Optimaliseer de tabellen via phpMyAdmin of een onderhoudsplugin
Die laatste stap, tabeloptimalisatie, is het equivalent van defragmentatie. MySQL reserveert ruimte voor verwijderde rijen. Door de tabel te optimaliseren geef je die ruimte terug en wordt de tabel compacter. Op grote tabellen kan dit merkbaar verschil maken in querysnelheid.
De klant van het begin had in drie jaar tijd nooit naar zijn database gekeken. Zijn formulierplugin had elke inzending bewaard, inclusief de spam. Zijn thema sloeg bij elke paginalading tientallen transients op die nooit verliepen. En hij had een statistiekenplugin gehad die hij een jaar geleden had verwijderd, maar waarvan de tabellen nog gewoon aanwezig waren.
Na opruimen zat hij op 380 megabyte. Het formulier werkte weer. De witte pagina’s waren weg. Geen nieuwe server, geen dure interventie. Gewoon onderhoud dat te lang was uitgesteld.
De database is het deel van WordPress dat niemand ziet en waar iedereen mee wegkomt zolang het goed gaat. Tot het niet meer goed gaat.