De maximale uploadgrootte in WordPress verhogen

Drie instellingen bepalen je WordPress-uploadlimiet, en ze moeten alle drie op elkaar aansluiten. De effectieve limiet is de kleinste van upload_max_filesize, post_max_size en de request-limiet van je webserver. Verhoog er één en laat de andere twee laag staan, en er verandert niets — precies de reden waarom de meeste mensen concluderen dat hun oplossing “niet werkte”. Controleer eerst je huidige waarden met de WordPress max upload size tool; die leest dezelfde waarden uit die WordPress rapporteert en laat zien welke je tegenhoudt.

Waarom de limiet bestaat en waar hij zit

WordPress stelt de uploadlimiet niet in. Het rapporteert hem alleen. Als je “The uploaded file exceeds the upload_max_filesize directive in php.ini” ziet, komt die melding rechtstreeks uit PHP.

Drie afzonderlijke waarden bepalen of een upload doorgaat, en het echte plafond is de laagste daarvan:

• upload_max_filesize (PHP) — het grootste losse bestand dat PHP accepteert.
• post_max_size (PHP) — de grootste totale POST-body. Je bestand reist mee in het POST-request samen met andere formuliervelden, dus deze moet groter zijn dan upload_max_filesize.
• De body-limiet van de webserver — client_max_body_size op Nginx, of LimitRequestBody op Apache. Deze staat volledig los van PHP, en daarom mislukken PHP-only oplossingen stilletjes achter Nginx.

Een vierde waarde, max_execution_time, begrenst de grootte niet, maar breekt wel een trage grote upload halverwege af bij een slechte verbinding. Dat is een apart symptoom, geen onderdeel van het groottelimiet.

De valkuil: je zet upload_max_filesize = 256M, herlaadt, en kunt nog steeds geen bestand van 100 MB uploaden — omdat post_max_size nog steeds op 8M staat. PHP wijst het request af op de totale body voordat het het bestand überhaupt inspecteert. De limiet negeerde je niet. Een andere limiet ving hem eerst op.

Hoe je het oplost, in volgorde

Werk van meest-waarschijnlijk-succesvol naar laatste redmiddel.

1. Bewerk php.ini (de juiste plek). Zoek het bestand dat je site daadwerkelijk laadt — draai een pagina met <?php phpinfo(); en lees “Loaded Configuration File”, of vraag het je host. Stel beide PHP-waarden in en houd post_max_size groter dan upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Herstart PHP-FPM (sudo systemctl restart php8.2-fpm) of Apache. Wijzigingen doen niets totdat het PHP-proces herstart.

2. Geen toegang tot php.ini? Gebruik .htaccess (alleen Apache + mod_php). Voeg toe aan de .htaccess in je WordPress-root:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Dit werkt alleen wanneer PHP draait als Apache-module. Onder PHP-FPM, CGI of FastCGI gooit php_value een 500-fout — die fout betekent dat je op het verkeerde spoor zit, niet dat het getal verkeerd is. Schakel over naar .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Verhoog de webserverlimiet — de stap die iedereen vergeet. Op Nginx ziet PHP het te grote request nooit; Nginx geeft eerst 413 Request Entity Too Large terug. In je server block:

client_max_body_size 256M;

Herlaad met sudo nginx -t && sudo systemctl reload nginx. Als je op Nginx zit en je PHP-aanpassingen “niets deden”, is dit vrijwel altijd de reden.

Controleer na elke wijziging opnieuw de gerapporteerde waarden. De max upload size tool vertelt je het nieuwe effectieve plafond en genereert de exacte snippet voor jouw configuratie, zodat je niet hoeft te gokken welke van de drie nog te laag staat.

Wat je niet moet doen

Bewerk wp-config.php niet in de verwachting dat het de limiet verhoogt. De veelgekopieerde regel doet niet wat de blogposts beweren:

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize is PHP_INI_PERDIR. Het kan tijdens runtime niet vanuit PHP worden gewijzigd met ini_set(). Het accepteert alleen nieuwe waarden uit php.ini, .htaccess of .user.ini — nooit vanuit applicatiecode. De regel draait zonder fout en doet niets, waardoor het een van de meest zelfverzekerd herhaalde stukjes verkeerd advies in WordPress is.

Plak ook @ini_set('post_max_size', ...) er niet in — dezelfde beperking, dezelfde stille no-op.

Stel WP_MEMORY_LIMIT niet in en denk dat het de uploadlimiet is. Dat regelt PHP’s memory limit voor het draaien van code. Het staat los van hoe groot een bestand is dat de server accepteert.

Stop niet bij één bestand. De allervaakst voorkomende misser is alleen upload_max_filesize aanpassen en de oplossing kapot verklaren. Wijzig alle drie, en houd post_max_size boven upload_max_filesize.

Zet limieten niet absurd hoog “voor de zekerheid”. Een limiet van 2 GB nodigt uit tot problemen met uitputting van resources en helpt niet — als je echt bestanden van meerdere gigabytes nodig hebt, upload ze dan buiten de browser om (SFTP, of een chunked-upload plugin) in plaats van ze door één PHP-POST te forceren.

Nog steeds vast?

Als alle drie de waarden verhoogd zijn en je toch tegen een muur loopt, wordt het request ergens stroomopwaarts van je server begrensd: een CDN of proxy (het dashboard van Cloudflare begrenst zelf de upload-body-grootte), een platformlimiet van een managed host die je php.ini negeert, of een .user.ini die nog niet is ververst — die respecteert PHP’s user_ini.cache_ttl, dus hij kan na het opslaan een paar minuten achterlopen. Bevestig wat de server daadwerkelijk rapporteert, niet wat je in een bestand hebt geschreven, en fix de laag die nog te laag staat. Zodra het gerapporteerde getal eindelijk overeenkomt met je doel, werkt de upload.