WordPress "HTTP error" sa Pag-upload ng Larawan: Isang Decision Tree na Talagang Nakakahanap ng Sanhi

Hindi sanhi ang “HTTP error”. Ito ay pag-amin ng media uploader na ipinadala nito ang file mo sa server at ang naibalik ay isang response na hindi nito mabasa bilang tagumpay — at may hindi bababa sa anim na magkakaibang pagkabigo ang naglalabas ng magkaparehong tatlong salita. Ang paghula sa pagitan ng mga ito ang dahilan kung bakit may mga taong gumugugol ng isang hapon sa pagtaas ng upload_max_filesize sa site na ang totoong problema pala ay isang firewall rule.

Ang pinakamabilis na labasan ay isang obserbasyon na naghahati sa anim na sanhi sa dalawang grupo, tapos isang pagsusuri kada sanga.

Una: basahin ang aktuwal na response

Buksan ang developer tools ng browser mo, pumunta sa Network tab, at i-upload muli ang file. Bantayan ang request papunta sa async-upload.php. Kung ano man ang bumalik, iyon ang diagnosis mo.

Ang nakikita mo	Ano ang ibig sabihin	Pumunta sa
403 o 406, may HTML body	Tinanggihan ng firewall o mod_security ang request	Sanga A
500, o walang laman na response, o putol na body	Nag-crash ang PHP o naubusan ng memory sa gitna ng proseso	Sanga B
413	Lumampas ang request body sa limitasyon ng server	Sanga C
200, pero hindi malinis na JSON ang body	May plugin o theme na naglabas ng output bago ang response	Sanga D
Hindi natatapos ang request / nag-ti-timeout	Limitasyon sa oras ng pagpapatakbo, kadalasan sa malalaking file	Sanga B

Ang isang tingin na iyon ay nag-aalis na ng halos lahat ng payo sa internet. Kung hindi ka makapunta sa browser tools, buksan muna ang logging sa wp-config.php:

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

Ulitin ang pag-upload, tapos basahin ang wp-content/debug.log. Tuwirang tinutukoy ng linya ng fatal error ang sanga. Kung magulo ang linya, i-paste ito sa error log decoder — inuugnay nito ang karaniwang mga fatal signature sa kung ano talaga ang nasira.

Sanga A — isang firewall o mod_security rule

Ang 403 na may HTML page sa body ay nangangahulugang hindi nakarating sa WordPress ang request. May isang bagay sa harap nito — mod_security, Cloudflare, Wordfence, Sucuri, o ang sariling hanay ng rule ng host mo — na nagpasyang mukhang mapanganib ang POST.

Ang pagsusuri: pansamantalang i-deactivate ang anumang security plugin at mag-upload muli. Kung walang nagbago, nasa antas ng server ang rule, at kailangan mong ipatingin sa host mo ang mod_security audit log para sa timestamp ng nabigong upload. Puwede nilang i-whitelist ang partikular na rule ID.

Maging tapat ka sa sarili mo tungkol sa payong makikita mo rito. May mga snippet na nagsasabing ilagay ito sa .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

Para ito sa mod_security 1.x, na halos wala nang gumagamit. Sa modernong server, ang mga direktibang iyan ay walang epekto o kaya naman ay nagbubunga ng 500 na lalong sumisira sa site. Ang modernong mod_security ay gumagamit ng SecRuleEngine, at karamihan sa mga managed host ay bina-block ang per-directory na pag-override nito. Magtanong sa host; huwag basta mag-paste.

Sanga B — limitasyon sa PHP memory o execution

Ito ang pinakakaraniwang sanga at ang may pinakamalinaw na palatandaan: paputol-putol ito. Naka-upload ang parehong file sa pangatlong subok, o nabibigo ang 2MB na larawan habang dumadaan naman nang maayos ang 6MB na PDF. Ang matigas na limitasyon sa configuration ay nabibigo nang magkapareho sa tuwina. Hindi ganoon ang mga pagkabigo dahil sa memory, dahil nakadepende sa iba pang ginagawa ng server kung gaano karami ang available.

Bakit sa mga larawan partikular: hindi lang basta iniimbak ng WordPress ang file, dini-decompress nito ito papuntang hilaw na pixel para gawin ang bawat panggitnang laki — medium_large, anumang nakarehistro sa pamamagitan ng add_image_size, woocommerce_thumbnail kung may tindahan ka, dagdag pa ang -scaled na kopya kung lumampas ang larawan sa big_image_size_threshold. Ang 12-megapixel na JPEG ay ilang MB lang sa disk pero halos 48MB sa memory, bago pa ang resize buffer. Mabilis maubos ang 128MB na limitasyon.

Taasan ito sa wp-config.php, sa itaas ng linyang “stop editing”:

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

Ang totoong halaga nito: hindi puwedeng lumampas ang WP_MEMORY_LIMIT sa pinapayagan mismo ng PHP. Kung nililimitahan ng host mo ang memory_limit sa 128M, palamuti lang ang constant na ito. Tingnan ang tunay na halaga sa Tools → Site Health → Info → Server, hindi sa kung ano ang isinulat mo. Kung ang sariling limitasyon ng PHP ang kisame, ang host lang ang makakapagtaas nito.

Sanga C — limitasyon sa laki ng file at ng post

Tingnan ang aktuwal na mga numero sa ilalim ng Tools → Site Health → Info → Media Handling. Dalawang setting ang mahalaga at isa lang ang palaging binabago ng mga tao:

• upload_max_filesize — ang limitasyon sa isang file.
• post_max_size — ang limitasyon sa buong request body.

Kung lumampas ang buong POST sa post_max_size, itinatapon ng PHP ang request bago pa magpatakbo ng kahit anong code ang WordPress. Wala nang maibabalik, kaya nakakakuha ang uploader ng response na hindi nito mabasa at sinasabi nitong “HTTP error”. Dapat laging komportableng mas malaki ang post_max_size kaysa sa upload_max_filesize.

May isang bagay na dapat mong malaman: kapag lumampas ang file sa upload_max_filesize lang, kadalasang nahuhuli ito ng uploader sa browser at sinasabi nitong lumampas ang file sa pinakamataas na laki ng upload — mas malinaw na mensahe. Kaya ang tuyot na “HTTP error” ay mas madalas na tumuturo sa post_max_size o sa Sanga B kaysa sa setting na unang tinataasan ng lahat.

Nakadepende sa stack mo kung saan mo ito papalitan. Sa Apache na may mod_php, gumagana ang .htaccess:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Sa PHP-FPM, LiteSpeed, o NGINX — na siyang karamihan ng modernong hosting — walang ginagawa ang mga linyang iyon, at puwede pang magbunga ng 500. Gamitin na lang ang PHP settings panel ng host o isang .user.ini file. May sariling client_max_body_size din ang NGINX, na ang host lang ang makakapagtaas.

Sanga D — ang image editor library (Imagick kumpara sa GD)

Mas gusto ng WordPress ang ImageMagick kapag naroon ang PHP extension, at bumabalik ito sa GD kapag wala. Sa mga shared host, madalas na ang ImageMagick ang problema: nililimitahan ng policy configuration file nito ang memory, disk, at area kada operasyon, at kapag natapakan ng isang resize ang isa sa mga limitasyong iyon, namamatay ang proseso nang walang kapaki-pakinabang na mensahe. Karaniwan mong makikita ito sa malalaking larawan habang gumagana naman ang maliliit — na parang Sanga B pero hindi.

Pilitin ang GD para subukan ang teoryang ito:

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

Ilagay iyan sa functions.php o sa isang maliit na mu-plugin, ulitin ang upload, tapos alisin ito kung walang nagbago.

Ang tapat na palitan: hindi talaga mas mahusay ang GD. Hawak nito ang buong hindi-naka-compress na bitmap sa memory ng PHP, kaya sa napakalalaking file puwede itong tumama sa memory_limit kung saan magtatagumpay sana ang ImageMagick — na gumagana nang bahagyang nasa labas ng alokasyon ng PHP. Puwedeng magpalit ka lang ng isang pagkabigo sa iba. Ituring mo itong diagnostic muna bago solusyon.

Sanga E — permiso ng uploads directory

Bihira sa managed hosting, karaniwan naman pagkatapos ng migration o manwal na paglipat ng server. Kung hindi writable ang wp-content/uploads ng user ng web server, o kung ang bagong likhang year/month na subfolder ay nagmana ng maling owner, nabibigo ang pagsulat.

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

Karaniwang dapat 755 ang mga direktoryo at pag-aari ng user kung saan tumatakbo ang PHP. Huwag mong itakda sa 777 dahil lang sinabi ng isang forum — inaayos niyan ang sintomas sa pamamagitan ng paggawa sa folder na writable ng bawat account sa server, na sa shared hosting ay tunay na panganib.

Sanga F — ang filename

Ito ang pinakamurang pagsusuri sa listahan, kaya gawin mo ito nang maaga kahit ito ang pinakamalabong sanhi. Palitan ang pangalan ng file sa payak na maliliit na titik, numero, at gitling — walang tuldik, kudlit, ampersand, #, o hindi-Latin na karakter — tapos mag-upload muli. Paminsan-minsan, natatapakan ng mga espesyal na karakter ang isang security rule o nasisira ang mga ito sa filesystem na hindi tugma ang encoding. Sampung segundo para maalis ito sa listahan.

Ang hindi dapat gawin

Huwag magsimula sa pag-deactivate ng lahat ng plugin. Nakakaabala ito at Sanga A at Sanga D lang ang nasusubok nito. Mas marami pang sinasabi sa iyo ang network response sa loob ng limang segundo.

Huwag magdagdag ng basta-bastang .htaccess handler line. Ang mga kumakalat na snippet na nagdaragdag ng SetHandler o AddHandler na direktiba ay ipinapalagay ang partikular na PHP setup ng isang host. Sa maling stack, pinapatay nila ang buong site sa isang 500.

Huwag tanggapin ang “gumana naman nang inulit ko” bilang ayos na. Ang paputol-putol na tagumpay ang lagda ng Sanga B, at babalik ito sa sandaling maging abala ang server o may mag-upload ng mas malaki.

Hindi pa rin gumagana?

Kung malinis na 200 na may wastong JSON ang response pero nabibigo pa rin ang upload, nasa hulihan ang sira — pagkatapos makarating ang file. Kadalasan ay isang plugin na nakakabit sa attachment-processing chain na nag-fatal, o isang optimizer plugin na nagpapadala ng sariling request sa isang panlabas na serbisyong nagti-timeout. Buksan ang WP_DEBUG_LOG, ulitin ang problema, at ipasa ang lumabas na fatal sa error log decoder para makita kung aling file at aling hook talaga ang may kasalanan.