Lompat ke konten
Konfigurasi

Cara Menambah Kapasitas Upload Maksimum di WordPress

Ada tiga pengaturan yang mengontrol batas upload WordPress Anda, dan ketiganya harus sinkron. Batas efektifnya adalah yang paling kecil di antara upload_max_filesize, post_max_size,

Dipublikasikan

Ada tiga pengaturan yang mengontrol batas upload WordPress Anda, dan ketiganya harus sinkron. Batas efektifnya adalah yang paling kecil di antara upload_max_filesize, post_max_size, dan batas request dari web server Anda. Naikkan salah satu, biarkan dua lainnya tetap rendah, dan tidak ada yang berubah — dan inilah persis kenapa kebanyakan orang menyimpulkan perbaikan mereka “tidak berhasil”. Cek dulu angka Anda saat ini dengan tool max upload size WordPress; tool ini membaca nilai yang sama yang dilaporkan WordPress dan menunjukkan mana yang menahan Anda.

Kenapa batas ini ada dan di mana letaknya

WordPress tidak menetapkan batas upload. WordPress hanya melaporkannya. Ketika Anda melihat “The uploaded file exceeds the upload_max_filesize directive in php.ini,” pesan itu datang langsung dari PHP.

Ada tiga nilai terpisah yang mengatur sebuah upload, dan plafon sebenarnya adalah yang mana pun paling rendah:

  • upload_max_filesize (PHP) — file tunggal terbesar yang akan diterima PHP.
  • post_max_size (PHP) — total body POST terbesar. File Anda ikut di dalam request POST bersama field form lainnya, jadi nilai ini harus lebih besar dari upload_max_filesize.
  • Batas body web serverclient_max_body_size di Nginx, atau LimitRequestBody di Apache. Yang satu ini berada di luar PHP sepenuhnya, itulah kenapa perbaikan yang hanya menyentuh PHP diam-diam gagal di belakang Nginx.

Nilai keempat, max_execution_time, tidak membatasi ukuran tapi akan menghentikan upload besar yang lambat di tengah transfer pada koneksi yang buruk. Ini gejala terpisah, bukan bagian dari plafon ukuran.

Jebakannya: Anda set upload_max_filesize = 256M, reload, tetap tidak bisa upload file 100 MB — karena post_max_size masih 8M. PHP menolak request pada total body sebelum sempat memeriksa filenya. Batas itu bukan mengabaikan Anda. Batas yang berbeda yang menangkapnya lebih dulu.

Cara memperbaikinya, secara berurutan

Kerjakan dari yang paling mungkin berhasil ke pilihan terakhir.

1. Edit php.ini (tempat yang benar). Cari file yang benar-benar dimuat situs Anda — jalankan sebuah halaman dengan <?php phpinfo(); lalu baca “Loaded Configuration File,” atau tanyakan ke hosting Anda. Set kedua nilai PHP, dan jaga agar post_max_size tetap lebih besar dari upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Restart PHP-FPM (sudo systemctl restart php8.2-fpm) atau Apache. Perubahan tidak berpengaruh sampai proses PHP di-restart.

2. Tidak punya akses php.ini? Gunakan .htaccess (khusus Apache + mod_php). Tambahkan ke .htaccess di root WordPress Anda:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Ini hanya berhasil ketika PHP berjalan sebagai modul Apache. Di bawah PHP-FPM, CGI, atau FastCGI, php_value melempar error 500 — kegagalan itu berarti Anda salah jalan, bukan berarti angkanya salah. Beralih ke .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Naikkan batas web server — langkah yang semua orang lupa. Di Nginx, PHP bahkan tidak pernah melihat request yang kebesaran; Nginx mengembalikan 413 Request Entity Too Large lebih dulu. Di server block Anda:

client_max_body_size 256M;

Reload dengan sudo nginx -t && sudo systemctl reload nginx. Kalau Anda pakai Nginx dan editan PHP Anda “tidak berpengaruh”, ini hampir selalu penyebabnya.

Setelah perubahan apa pun, cek ulang nilai yang dilaporkan. Tool max upload size akan memberi tahu plafon efektif yang baru dan menghasilkan snippet yang tepat untuk setup Anda, jadi Anda tidak menebak-nebak mana dari ketiganya yang masih rendah.

Yang tidak boleh dilakukan

Jangan edit wp-config.php dan berharap itu menaikkan batasnya. Baris yang banyak disalin ini tidak melakukan apa yang diklaim postingan blog:

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

upload_max_filesize bersifat PHP_INI_PERDIR. Nilainya tidak bisa diubah dari PHP saat runtime dengan ini_set(). Ia hanya menerima nilai baru dari php.ini, .htaccess, atau .user.ini — tidak pernah dari kode aplikasi. Baris itu berjalan tanpa error dan tidak melakukan apa-apa, yang menjadikannya salah satu nasihat keliru yang paling percaya diri diulang-ulang di WordPress.

Jangan tempel @ini_set('post_max_size', ...) juga — batasan sama, no-op diam yang sama.

Jangan set WP_MEMORY_LIMIT dan mengira itu batas upload. Itu mengontrol plafon memori PHP untuk menjalankan kode. Tidak ada hubungannya dengan seberapa besar file yang diterima server.

Jangan berhenti di satu file. Kegagalan paling umum adalah mengubah upload_max_filesize saja lalu menyatakan perbaikannya rusak. Ubah ketiganya, dan jaga agar post_max_size di atas upload_max_filesize.

Jangan set batas sangat tinggi “biar aman”. Batas 2 GB mengundang masalah kehabisan resource dan tidak membantu — kalau Anda benar-benar butuh file berukuran multi-gigabyte, upload di luar browser (SFTP, atau plugin chunked-upload) alih-alih memaksanya lewat satu POST PHP.

Masih buntu?

Kalau ketiga nilai sudah dinaikkan dan Anda tetap mentok, request-nya dibatasi di suatu tempat di hulu server Anda: sebuah CDN atau proxy (dashboard Cloudflare membatasi ukuran body upload sendiri), batas platform dari managed host yang mengabaikan php.ini Anda, atau sebuah .user.ini yang belum ter-refresh — ia menghormati user_ini.cache_ttl PHP, jadi bisa terlambat beberapa menit setelah Anda menyimpan. Pastikan apa yang benar-benar dilaporkan server, bukan apa yang Anda tulis di sebuah file, dan perbaiki lapisan yang masih rendah. Ketika angka yang dilaporkan akhirnya cocok dengan target Anda, upload-nya berhasil.