WordPress "HTTP-fout" bij het uploaden van afbeeldingen: een beslisboom die de oorzaak echt vindt

“HTTP-fout” is geen oorzaak. Het is de mediauploader die toegeeft dat hij je bestand naar de server heeft gestuurd en een antwoord terugkreeg dat hij niet als succes kon lezen — en minstens zes totaal verschillende storingen leveren exact dezelfde melding op. Ertussen gokken is precies waarom mensen een middag besteden aan het verhogen van upload_max_filesize op een site waarvan het echte probleem een firewallregel is.

De snelste weg naar buiten is één waarneming die de zes oorzaken in twee groepen splitst, gevolgd door één controle per tak.

Eerst: lees het daadwerkelijke antwoord

Open de ontwikkelaarstools van je browser, ga naar het tabblad Netwerk en upload het bestand opnieuw. Let op het verzoek naar async-upload.php. Wat daarop terugkomt, is je diagnose.

Wat je ziet	Wat het betekent	Ga naar
403 of 406, HTML-body	Firewall of mod_security weigerde het verzoek	Tak A
500, of leeg antwoord, of een afgekapte body	PHP crashte of raakte halverwege door zijn geheugen heen	Tak B
413	De request-body overschreed een serverlimiet	Tak C
200, maar de body is geen schone JSON	Een plugin of thema drukte uitvoer af vóór het antwoord	Tak D
Verzoek wordt nooit voltooid / loopt af	Limiet op uitvoeringstijd, meestal bij grote bestanden	Tak B

Die ene blik schrapt het merendeel van het internetadvies voor je. Kom je niet bij de browsertools, zet dan eerst het loggen aan in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Herhaal de upload en lees daarna wp-content/debug.log. Een regel met een kritieke fout noemt de tak meteen. Is de regel onleesbaar dicht, plak hem dan in de error log decoder — die vertaalt de gangbare foutmeldingen naar wat er werkelijk stukging.

Tak A — een firewall- of mod_security-regel

Een 403 met een HTML-pagina in de body betekent dat het verzoek WordPress nooit bereikt heeft. Iets ervoor — mod_security, Cloudflare, Wordfence, Sucuri of het regelset van je host zelf — vond de POST er kwaadaardig uitzien.

De controle: schakel beveiligingsplugins tijdelijk uit en upload opnieuw. Verandert dat niets, dan zit de regel op serverniveau en moet je host in het mod_security-auditlogboek kijken op het tijdstip van de mislukte upload. Zij kunnen dat specifieke regel-ID op de witte lijst zetten.

Wees eerlijk tegen jezelf over het advies dat je hier gaat tegenkomen. Fragmenten die zeggen dat je dit in .htaccess moet zetten:

SecFilterEngine Off
SecFilterScanPOST Off

zijn gericht op mod_security 1.x, dat vrijwel uitgestorven is. Op een moderne server doen die regels ofwel niets, of ze veroorzaken een 500 die de site verder sloopt. Modern mod_security gebruikt SecRuleEngine, en de meeste managed hosts blokkeren het per map overschrijven daarvan sowieso. Vraag het je host; plak niet.

Tak B — PHP-geheugen of uitvoeringslimieten

Dit is de meest voorkomende tak, en die met het duidelijkste signaal: het is wisselvallig. Hetzelfde bestand lukt bij de derde poging, of een foto van 2MB mislukt terwijl een PDF van 6MB probleemloos doorgaat. Harde configuratielimieten falen elke keer identiek. Geheugenproblemen niet, want hoeveel er beschikbaar is, hangt af van wat de server verder aan het doen is.

Waarom juist afbeeldingen: WordPress slaat het bestand niet alleen op, maar pakt het uit tot ruwe pixels om alle tussenformaten te genereren — medium_large, alles wat met add_image_size is geregistreerd, woocommerce_thumbnail als je een webshop hebt, plus een -scaled kopie als de afbeelding boven de big_image_size_threshold uitkomt. Een JPEG van 12 megapixel is een paar MB op schijf en zo’n 48MB in het geheugen, nog vóór de buffer voor het verkleinen. Een limiet van 128MB is dan zo weg.

Verhoog hem in wp-config.php, boven de regel “stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

De werkelijke prijs: WP_MEMORY_LIMIT kan nooit boven wat PHP zelf toestaat. Beperkt je host memory_limit tot 128M, dan is deze constante puur decoratief. Controleer de echte waarde onder Gereedschap → Websitediagnose → Info → Server, niet in wat jij hebt opgeschreven. Is de limiet van PHP zelf het plafond, dan kan alleen de host hem verhogen.

Tak C — bestandsgrootte en postlimieten

Bekijk de echte getallen onder Gereedschap → Websitediagnose → Info → Mediaverwerking. Twee instellingen doen ertoe, en mensen wijzigen er altijd maar één:

• upload_max_filesize — de limiet voor één afzonderlijk bestand.
• post_max_size — de limiet voor de volledige request-body.

Overschrijdt de hele POST post_max_size, dan gooit PHP het verzoek weg voordat WordPress ook maar één regel code uitvoert. Er is dus niets om terug te geven, de uploader krijgt een onleesbaar antwoord en zegt “HTTP-fout”. post_max_size hoort altijd ruim groter te zijn dan upload_max_filesize.

Eén kanttekening is het waard: als een bestand alleen upload_max_filesize overschrijdt, vangt de uploader dat meestal al in de browser af en meldt hij dat het bestand de maximale uploadgrootte overschrijdt — een duidelijkere melding. Een kale “HTTP-fout” wijst dus vaker op post_max_size of op tak B dan op de instelling die iedereen als eerste verhoogt.

Waar je ze aanpast, hangt af van je serversoftware. Op Apache met mod_php werkt .htaccess:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Op PHP-FPM, LiteSpeed of NGINX — en dat is het merendeel van de moderne hosting — doen die regels niets en kunnen ze een 500 veroorzaken. Gebruik dan het PHP-instellingenpaneel van je host of een .user.ini-bestand. NGINX hanteert bovendien zijn eigen client_max_body_size, die alleen de host kan verhogen.

Tak D — de beeldbewerkingsbibliotheek (Imagick versus GD)

WordPress geeft de voorkeur aan ImageMagick als de PHP-extensie aanwezig is, en valt anders terug op GD. Op shared hosts is ImageMagick vaak juist het probleem: het policybestand beperkt geheugen, schijfruimte en oppervlakte per bewerking, en zodra een verkleining tegen zo’n limiet aanloopt, sterft het proces zonder bruikbare melding. Je ziet dit meestal bij grote afbeeldingen terwijl kleine wel werken — wat op tak B lijkt maar het niet is.

Forceer GD om de theorie te testen:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

Zet dat in functions.php of in een kleine mu-plugin, probeer de upload opnieuw en haal het weg als er niets verandert.

De eerlijke afweging: GD is niet zonder meer beter. Het houdt de volledige onverpakte bitmap in het geheugen van PHP, dus bij zeer grote bestanden kan het tegen memory_limit aanlopen waar ImageMagick — dat deels buiten de geheugentoewijzing van PHP werkt — het wel had gered. Overstappen kan de ene storing voor de andere inruilen. Zie het eerst als diagnose en pas daarna als oplossing.

Tak E — rechten op de uploadmap

Zeldzaam bij managed hosting, veelvoorkomend direct na een migratie of een handmatige serververhuizing. Is wp-content/uploads niet beschrijfbaar voor de gebruiker van de webserver, of heeft een nieuw aangemaakte jaar/maand-submap de verkeerde eigenaar geërfd, dan mislukt het schrijven.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Mappen horen doorgaans 755 te zijn en eigendom van de gebruiker waaronder PHP draait. Zet ze niet op 777 omdat een forum dat zei: dat verhelpt het symptoom door de map beschrijfbaar te maken voor elk account op de server, wat op shared hosting een echt beveiligingsrisico is.

Tak F — de bestandsnaam

De goedkoopste controle van de lijst, dus doe hem vroeg, ook al is hij het minst waarschijnlijk. Hernoem het bestand naar gewone kleine letters, cijfers en koppeltekens — geen accenten, apostrofs, ampersands, # of niet-Latijnse tekens — en upload opnieuw. Speciale tekens triggeren af en toe een beveiligingsregel of lopen stuk op een bestandssysteem met afwijkende codering. Tien seconden om uit te sluiten.

Wat je niet moet doen

Begin niet met alle plugins uitschakelen. Het is ingrijpend en het test alleen tak A en tak D. Het netwerkantwoord vertelt je in vijf seconden meer.

Voeg geen willekeurige handler-regel toe aan .htaccess. De rondzingende fragmenten die een SetHandler- of AddHandler-regel toevoegen, gaan uit van de PHP-opzet van één specifieke host. Op de verkeerde server halen ze je hele site onderuit met een 500.

Neem geen genoegen met “het lukte bij de tweede poging”. Wisselend succes is de handtekening van tak B, en het komt terug zodra de server het druk heeft of iemand iets groters uploadt.

Kom je er niet uit?

Is het antwoord een schone 200 met geldige JSON en mislukt de upload alsnog, dan zit de breuk ná het landen van het bestand — meestal een plugin die zich in de verwerkingsketen van bijlagen haakt en een kritieke fout gooit, of een optimalisatieplugin die een eigen verzoek naar een externe dienst stuurt dat afloopt. Zet WP_DEBUG_LOG aan, herhaal de upload en haal de resulterende kritieke fout door de error log decoder om te zien welk bestand en welke hook werkelijk verantwoordelijk zijn.