Dagdagan ang Maximum Upload File Size sa WordPress

May tatlong settings na kumokontrol sa upload limit ng iyong WordPress, at kailangan silang lahat magkasundo. Ang epektibong limit ay ang pinakamaliit sa upload_max_filesize, post_max_size, at ang request cap ng iyong web server. Kung isa lang ang itataas mo at mananatiling mababa ang dalawa pa, walang mababago — kaya nga karamihan ng tao ay napagpapasyahang “hindi gumana” ang kanilang ayos. Tingnan muna ang iyong kasalukuyang mga numero gamit ang WordPress max upload size tool; binabasa nito ang mga parehong value na iniuulat ng WordPress at ipinapakita kung alin ang humahadlang sa iyo.

Bakit umiiral ang limit at saan ito nakatira

Hindi ang WordPress ang nagtatakda ng upload limit. Iniuulat lang nito ito. Kapag nakita mo ang “The uploaded file exceeds the upload_max_filesize directive in php.ini,” direktang galing sa PHP ang mensaheng iyon.

May tatlong magkahiwalay na value ang humahadlang sa isang upload, at ang totoong ceiling ay kung alin ang pinakamababa:

• upload_max_filesize (PHP) — ang pinakamalaking iisang file na tatanggapin ng PHP.
• post_max_size (PHP) — ang pinakamalaking kabuuang POST body. Ang iyong file ay sumasakay sa loob ng POST request kasama ang iba pang form fields, kaya kailangang mas malaki ito kaysa sa upload_max_filesize.
• Ang body limit ng web server — client_max_body_size sa Nginx, o LimitRequestBody sa Apache. Ito ay nasa labas ng PHP nang buo, kaya nga tahimik na nabibigo ang mga PHP-lang na ayos kapag nasa likod ng Nginx.

Ang ikaapat na value, ang max_execution_time, ay hindi naglilimita sa laki ngunit puputulin nito ang isang mabagal na malaking upload sa gitna ng transfer sa mahinang koneksyon. Ito ay hiwalay na sintomas, hindi bahagi ng size ceiling.

Ang bitag: itinakda mo ang upload_max_filesize = 256M, nag-reload, hindi pa rin ma-upload ang 100 MB na file — dahil 8M pa rin ang post_max_size. Tinatanggihan ng PHP ang request sa kabuuang body bago pa man nito suriin ang file. Hindi ka binalewala ng limit. May ibang limit na nakahuli muna nito.

Paano ayusin, ayon sa ayos

Magsimula sa pinaka-malamang gumana pababa sa huling paraan.

1. I-edit ang php.ini (ang tamang lugar). Hanapin ang file na talagang niloload ng iyong site — magpatakbo ng page na may <?php phpinfo(); at basahin ang “Loaded Configuration File,” o tanungin ang iyong host. Itakda ang parehong PHP values, at panatilihin ang post_max_size na mas malaki kaysa sa upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

I-restart ang PHP-FPM (sudo systemctl restart php8.2-fpm) o Apache. Walang mangyayari sa mga pagbabago hanggang hindi nag-re-restart ang PHP process.

2. Walang access sa php.ini? Gamitin ang .htaccess (Apache + mod_php lamang). Idagdag sa .htaccess sa root ng iyong WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Gumagana lang ito kapag ang PHP ay tumatakbo bilang Apache module. Sa ilalim ng PHP-FPM, CGI, o FastCGI, ang php_value ay magbibigay ng 500 error — ang pagkabigong iyon ay nangangahulugang mali ang iyong dinadaanan, hindi na mali ang numero. Lumipat sa .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Itaas ang limit ng web server — ang hakbang na nakakalimutan ng lahat. Sa Nginx, hindi man lang nakikita ng PHP ang sobrang laking request; ibinabalik muna ng Nginx ang 413 Request Entity Too Large. Sa iyong server block:

client_max_body_size 256M;

I-reload gamit ang sudo nginx -t && sudo systemctl reload nginx. Kung nasa Nginx ka at ang iyong mga PHP edit ay “walang ginawa,” ito halos palaging ang dahilan.

Pagkatapos ng anumang pagbabago, muling tingnan ang mga iniulat na value. Sasabihin sa iyo ng max upload size tool ang bagong epektibong ceiling at bubuo ng eksaktong snippet para sa iyong setup, para hindi ka manghula kung alin sa tatlo ang mababa pa.

Ano ang hindi dapat gawin

Huwag i-edit ang wp-config.php at asahang itataas nito ang limit. Ang malawakang kinokopyang linya ay hindi ginagawa ang inaangkin ng mga blog post:

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

Ang upload_max_filesize ay PHP_INI_PERDIR. Hindi ito mababago mula sa PHP sa runtime gamit ang ini_set(). Tumatanggap lang ito ng bagong value mula sa php.ini, .htaccess, o .user.ini — hindi kailanman mula sa application code. Tumatakbo ang linya nang walang error at walang ginagawa, kaya ito ang isa sa pinaka-magigiliw na inuulit na maling payo sa WordPress.

Huwag ding i-paste ang @ini_set('post_max_size', ...) — parehong restriksyon, parehong tahimik na walang-epekto.

Huwag itakda ang WP_MEMORY_LIMIT at isipin na ito ang upload limit. Kinokontrol niyan ang memory ceiling ng PHP para sa pagpapatakbo ng code. Wala itong kinalaman sa kung gaano kalaking file ang tinatanggap ng server.

Huwag huminto sa isang file. Ang pinakakaraniwang pagkabigo ay ang pagbabago lamang ng upload_max_filesize at pagdedeklarang sira ang ayos. Baguhin ang lahat ng tatlo, at panatilihin ang post_max_size na mas mataas kaysa sa upload_max_filesize.

Huwag itakda ang mga limit nang labis-labis na “para sigurado.” Ang 2 GB na limit ay nag-aanyaya ng resource-exhaustion na problema at hindi nakakatulong — kung talagang kailangan mo ng multi-gigabyte na file, i-upload ang mga ito sa labas ng browser (SFTP, o isang chunked-upload plugin) sa halip na pilitin ang mga ito sa iisang PHP POST.

Sagad pa rin?

Kung naitaas na ang lahat ng tatlong value at napipigilan ka pa rin, ang request ay nililimitahan sa isang lugar na nasa itaas ng iyong server: isang CDN o proxy (ang dashboard ng Cloudflare ay naglilimita ng upload body size sa sarili nito), isang platform limit ng managed host na binabalewala ang iyong php.ini, o isang .user.ini na hindi pa nagre-refresh — sinusunod nito ang user_ini.cache_ttl ng PHP, kaya maaari itong maantala ng ilang minuto matapos mong i-save. Kumpirmahin kung ano talaga ang iniuulat ng server, hindi kung ano ang isinulat mo sa isang file, at ayusin ang layer na mababa pa. Kapag ang iniulat na numero ay tumugma na sa iyong target, gagana na ang upload.