U probeert een pagina op te slaan, een plugin te updaten of een grotere afbeelding te uploaden, en in plaats van een bevestiging krijgt u een witte pagina met een regel tekst: Allowed memory size of 134217728 bytes exhausted. Soms staat er alleen een kale foutmelding, soms helemaal niets en blijft het scherm leeg. Voor veel ondernemers is dit het eerste moment waarop ze horen dat WordPress überhaupt een geheugenlimiet heeft.
Het goede nieuws: de WordPress memory limit verhogen is meestal een kwestie van één regel in een configuratiebestand. Het minder goede nieuws: die ene regel lost lang niet altijd het echte probleem op. In dit artikel legt u de limiet eerst hoger, en kijkt u daarna kritisch of dat wel de juiste oplossing was.
Wat de geheugenlimiet precies is
Elke keer dat iemand een pagina opvraagt, draait PHP uw thema en plugins om die pagina samen te stellen. Dat proces mag een bepaalde hoeveelheid werkgeheugen gebruiken. Wordt die grens overschreden, dan stopt PHP het script en toont een foutmelding. WordPress zelf houdt daarbij twee waarden aan: een limiet voor de bezoekerskant (standaard 40 MB) en een ruimere limiet voor het beheer (standaard 256 MB). Daarboven zit nog de limiet van de server, ingesteld door uw hostingpartij in de PHP-configuratie. De laagste van die grenzen wint.
Dat verklaart waarom een aanpassing in WordPress soms niets doet. Als uw hostingpakket 128 MB toestaat, kunt u in WordPress 512 MB invullen, maar u krijgt nooit meer dan die 128 MB.
Het getal in de foutmelding is in bytes. 134217728 bytes is 128 MB, 268435456 is 256 MB. Zo weet u meteen welke grens u raakt.
Zo verhoogt u de WordPress memory limit stap voor stap
Maak eerst een back-up, of in elk geval een kopie van het bestand dat u gaat bewerken. Werk daarna in deze volgorde; stop zodra de fout verdwenen is.
- Controleer de huidige waarde. Ga in het beheer naar Hulpmiddelen → Sitegezondheid → Info → Server. Daar staat de PHP-geheugenlimiet die op dit moment geldt. Dat is uw uitgangspunt.
- Pas wp-config.php aan. Open het bestand in de hoofdmap van uw site via FTP of de bestandsbeheerder van uw hosting. Voeg boven de regel /* That’s all, stop editing! */ deze twee regels toe: define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); en define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ );. De eerste geldt voor de bezoekerskant, de tweede voor het beheer.
- Kijk of het werkt. Laad Sitegezondheid opnieuw. Staat er nog steeds de oude waarde, dan blokkeert de server de verhoging en gaat u naar de volgende stap.
- Verhoog de limiet bij uw hosting. Veel hostingpanelen (DirectAdmin, Plesk, cPanel) hebben een PHP-instellingenpagina waar u memory_limit kunt aanpassen. Op andere servers werkt een regel memory_limit = 256M in een php.ini- of .user.ini-bestand in de hoofdmap.
- Lukt dat ook niet? Dan is de limiet vastgezet op serverniveau. Een berichtje aan de helpdesk van uw hostingpartij is dan de enige route. Vermeld de exacte foutmelding en de gewenste waarde.
Een waarde van 256 MB is voor een gemiddelde bedrijfswebsite ruim voldoende. Webshops met veel plugins of een pagebuilder zitten vaak op 512 MB. Hoger dan dat is zelden nodig en een signaal dat er iets anders speelt.
Wanneer meer geheugen het probleem alleen verbergt
Hier zit de kern. Een site die opeens meer geheugen nodig heeft, had daar gisteren geen behoefte aan. Er is dus iets veranderd. Meer geheugen toestaan is dan als een grotere emmer onder een lekkende kraan zetten: het helpt even, maar de kraan lekt nog.
Veel voorkomende echte oorzaken in onze praktijk:
- Een plugin met een geheugenlek. Vaak na een update. De plugin laadt bij elke aanvraag te veel data in, bijvoorbeeld een complete productcatalogus of alle berichten tegelijk.
- Een import of export die te groot is. Duizend producten via CSV importeren in één keer vraagt veel. Knip de import in delen.
- Afbeeldingen van tientallen megabytes. WordPress maakt van elke upload meerdere formaten. Bij een foto van 8000 pixels breed ontploft dat geheugen. Verklein de foto eerst.
- Een oneindige lus in thema- of plugincode. Dan helpt geen enkele limiet; de fout komt alleen later.
- Verouderde PHP. Oude PHP-versies gaan minder zuinig met geheugen om. Een overstap naar een recente versie scheelt merkbaar.
Een goede test: verhoog de limiet tijdelijk en kijk of de fout terugkeert na een dag of week. Komt hij terug, dan groeit het verbruik en is er echt iets mis. Blijft het rustig, dan was het een eenmalige piek.
De boosdoener vinden
De foutmelding vermeldt meestal een bestandspad, bijvoorbeeld /wp-content/plugins/naam-van-plugin/includes/class-loader.php on line 214. Dat pad wijst niet altijd naar de schuldige (het is de plek waar het geheugen op was, niet per se de plek die het opmaakte), maar het is een goed startpunt. Staat er een pluginmap in, schakel die plugin dan tijdelijk uit en probeer de handeling opnieuw.
Ziet u geen pad, zet dan kort het foutenlog aan. Hoe u dat doet leest u in onze uitleg over de debug-modus. De regels in het log zijn preciezer dan wat er op het scherm verschijnt.
Een praktijkvoorbeeld: een installatiebedrijf uit Apeldoorn kreeg de geheugenfout alleen bij het opslaan van pagina’s. De limiet stond al op 512 MB. De oorzaak bleek een SEO-plugin die bij elke opslag alle interne links van de hele site opnieuw analyseerde, inclusief 1.400 oude nieuwsberichten. Na het uitzetten van die ene functie was 128 MB weer ruim voldoende. Meer geheugen had hier alleen de rekening voor een zwaarder hostingpakket opgeleverd.
Wat u zelf doet en wanneer u hulp inschakelt
Zelf doen: de waarde in Sitegezondheid opzoeken, de regels in wp-config.php toevoegen, en de instelling in uw hostingpaneel aanpassen. Dat is met een beetje voorzichtigheid goed te doen, mits u een kopie van wp-config.php hebt bewaard. Een typefout in dat bestand legt namelijk de hele site plat.
Hulp inschakelen als de fout na het verhogen terugkomt, als u de site niet meer in kunt om te testen, of als de melding naar een bestand wijst waarvan u niet weet wat het doet. Een specialist in het oplossen van WordPress-fouten zoekt dan met een profiler uit welke plugin het geheugen opslokt, in plaats van te gokken. Dat is meestal binnen een uur duidelijk.
Conclusie
De geheugenlimiet verhogen is een prima eerste stap en vaak genoeg. Doe het via wp-config.php, controleer in Sitegezondheid of de nieuwe waarde is aangekomen, en ga anders naar uw hostingpaneel. Maar noteer ook de datum. Keert de fout binnen enkele weken terug, dan is het tijd om de oorzaak te zoeken in plaats van de emmer nog groter te maken. Wilt u zeker weten dat uw site niet stilletjes tegen zijn grenzen aanloopt, laat dan een keer een vrijblijvende controle uitvoeren; geheugenverbruik is daar een vast onderdeel van.



