Veelgebruikte PHP-configuratie-instellingen en wat ze doen
Kort antwoord
Een handvol PHP-instellingen veroorzaakt de meeste supportvragen: memory_limit, upload_max_filesize, post_max_size, max_execution_time en display_errors. Ze staan meestal in php.ini, en op sommige omgevingen kun je ze per site of per directory overschrijven.
Waar deze instellingen staan
PHP leest zijn configuratie bij het opstarten uit een bestand met de naam php.ini. Op een typische Linux-server bestaan er vaak meerdere kopieën, bijvoorbeeld een aparte voor de command-line interface en een voor wat PHP voor de webserver draait (PHP-FPM of een Apache-module). Een wijziging in het verkeerde bestand lijkt daardoor soms geen effect te hebben. Sommige hostingomgevingen laten je ook een deel van deze instellingen per site of per directory overschrijven, via een .htaccess-bestand, een pool-configuratiebestand voor PHP-FPM, of instellingen in een control panel. Welke methode van toepassing is hangt af van hoe de server is ingericht. Zie Een control panel kiezen: cPanel vs. DirectAdmin vs. geen panel als er een panel bij komt kijken. Na een directe wijziging in php.ini moet de webserver of PHP-FPM-service meestal opnieuw starten voordat de nieuwe waarde actief wordt.
De instellingen die het vaakst voorkomen
| Instelling | Wat het regelt | Wat er gebeurt als de waarde te laag staat |
|---|---|---|
memory_limit | Het maximale geheugen dat één PHP-script mag gebruiken voordat PHP het script stopt. | Een script loopt halverwege vast met een fatale foutmelding "Allowed memory size exhausted". Dit is een veelvoorkomende oorzaak wanneer een grote bewerking, zoals een grote bestandsimport of een beeldbewerkingstaak, halverwege vastloopt in plaats van meteen bij de start. |
upload_max_filesize | Het grootste bestand dat een script via een upload kan accepteren. | Een upload die groter is dan deze limiet wordt geweigerd voordat het script de kans krijgt om die te verwerken. |
post_max_size | De maximale totale grootte van een volledig HTTP POST-verzoek, inclusief het geüploade bestand en eventuele andere formuliervelden die worden meegestuurd. | Het hele verzoek wordt geweigerd, inclusief eventuele bestanden erin, ongeacht hoe upload_max_filesize is ingesteld. |
max_execution_time | Hoe lang, in seconden, een script mag draaien voordat PHP het geforceerd stopt. | Een langlopende bewerking, zoals een import, export of het genereren van een rapport, lijkt vast te lopen en faalt vervolgens halverwege zonder bruikbare output. |
display_errors | Of PHP foutmeldingen, inclusief bestandspaden en stack traces, rechtstreeks op de pagina toont. | Aan: handig om problemen te vinden tijdens lokaal ontwikkelen. Aan gelaten op een openbare productiesite: een reëel risico op het lekken van informatie, omdat foutoutput bestandspaden, databasedetails of andere interne gegevens kan tonen aan iedereen die een fout veroorzaakt. |
Twee instellingen die je samen moet aanpassen
upload_max_filesize en post_max_size worden vaak ten onrechte gezien als onafhankelijke instellingen, maar ze werken samen. post_max_size begrenst het hele verzoek, niet alleen het bestand erin, en moet daarom gelijk zijn aan of groter zijn dan upload_max_filesize wil een hogere uploadlimiet daadwerkelijk effect hebben. Als je upload_max_filesize verhoogt om een bestand van 50 MB toe te staan, maar post_max_size op een kleinere waarde laat staan, wordt het verzoek alsnog geweigerd, maar dan bij de post_max_size-controle, met een foutmelding die verwarrend los lijkt te staan van de bestandsgrootte.
Een gebruikelijke combinatie in php.ini ziet er zo uit:
upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M
max_execution_time = 300
Door post_max_size iets hoger te zetten dan upload_max_filesize houd je wat marge over voor de andere formuliervelden die met het bestand worden meegestuurd. Dat is een redelijke standaard als je twijfelt.
Standaardwaarden voor productie versus ontwikkeling
display_errors verdient extra aandacht, want de juiste instelling verschilt per omgeving. Op een lokale ontwikkelmachine is de volledige foutoutput op de pagina echt nuttig: het is de snelste manier om te zien wat er is misgegaan. Op een openbare productiesite geeft datzelfde gedrag iedereen die een fout kan veroorzaken inzicht in interne bestandspaden, databasequery's of andere details die niet openbaar zouden moeten zijn. De gebruikelijke aanpak in productie is om display_errors uit te zetten en fouten in plaats daarvan naar een bestand te loggen (via log_errors en error_log), zodat de informatie nog steeds beschikbaar is voor wie het probleem debugt, zonder dat bezoekers het te zien krijgen.