Bỏ qua tới nội dung
Cấu hình

Tăng dung lượng upload tối đa trong WordPress

Có ba thiết lập kiểm soát giới hạn upload của WordPress, và cả ba phải khớp với nhau. Giới hạn thực tế là giá trị nhỏ nhất trong upload_max_filesize, post_max_size,

Đã đăng

Bỏ qua phần đọc — dùng công cụ Công cụ sửa giới hạn dung lượng tải lên Nâng giới hạn tải lên — và làm cho cả ba giá trị khớp nhau

Có ba thiết lập kiểm soát giới hạn upload của WordPress, và cả ba đều phải khớp với nhau. Giới hạn thực tế là giá trị nhỏ nhất trong upload_max_filesize, post_max_size, và mức giới hạn request của web server. Nếu bạn chỉ nâng một cái mà để hai cái còn lại ở mức thấp thì chẳng có gì thay đổi — và đó chính là lý do phần lớn mọi người kết luận rằng cách sửa của họ “không ăn thua”. Hãy kiểm tra các con số hiện tại trước bằng công cụ kiểm tra dung lượng upload tối đa của WordPress; nó đọc đúng những giá trị mà WordPress báo cáo và cho bạn biết cái nào đang kìm hãm bạn.

Vì sao có giới hạn này và nó nằm ở đâu

WordPress không đặt ra giới hạn upload. Nó chỉ báo cáo lại thôi. Khi bạn thấy dòng “The uploaded file exceeds the upload_max_filesize directive in php.ini”, thông báo đó đến thẳng từ PHP.

Có ba giá trị riêng biệt chặn một lượt upload, và trần thật sự là cái nào thấp nhất:

  • upload_max_filesize (PHP) — file đơn lớn nhất mà PHP chấp nhận.
  • post_max_size (PHP) — tổng dung lượng body POST lớn nhất. File của bạn được gửi bên trong request POST cùng với các trường form khác, nên giá trị này phải lớn hơn upload_max_filesize.
  • Giới hạn body của web server — client_max_body_size trên Nginx, hoặc LimitRequestBody trên Apache. Cái này nằm hoàn toàn bên ngoài PHP, và đó là lý do vì sao những cách sửa chỉ đụng tới PHP lại âm thầm thất bại khi chạy sau Nginx.

Một giá trị thứ tư, max_execution_time, không giới hạn dung lượng nhưng sẽ ngắt giữa chừng một lượt upload file lớn chậm khi đường truyền kém. Đó là một triệu chứng riêng, không phải một phần của trần dung lượng.

Cái bẫy: bạn đặt upload_max_filesize = 256M, reload lại, vẫn không up được file 100 MB — vì post_max_size vẫn là 8M. PHP từ chối request ngay ở tổng body trước khi kịp kiểm tra tới file. Không phải giới hạn kia phớt lờ bạn. Mà là một giới hạn khác đã chặn nó trước.

Cách khắc phục, theo thứ tự

Làm từ cách có khả năng ăn nhất tới phương án cuối cùng.

1. Sửa php.ini (đúng chỗ cần sửa). Tìm đúng file mà site của bạn thực sự nạp — chạy một trang có <?php phpinfo(); và đọc dòng “Loaded Configuration File”, hoặc hỏi nhà cung cấp hosting. Đặt cả hai giá trị PHP, và giữ post_max_size lớn hơn upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Khởi động lại PHP-FPM (sudo systemctl restart php8.2-fpm) hoặc Apache. Thay đổi sẽ chẳng có tác dụng gì cho tới khi tiến trình PHP được khởi động lại.

2. Không truy cập được php.ini? Dùng .htaccess (chỉ với Apache + mod_php). Thêm vào file .htaccess trong thư mục gốc WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Cách này chỉ chạy khi PHP chạy dưới dạng một module của Apache. Với PHP-FPM, CGI hoặc FastCGI, php_value sẽ gây lỗi 500 — lỗi đó nghĩa là bạn đang đi sai hướng, chứ không phải con số bị sai. Chuyển sang .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Nâng giới hạn của web server — bước ai cũng quên. Trên Nginx, PHP thậm chí không hề thấy một request quá cỡ; Nginx trả về 413 Request Entity Too Large trước. Trong server block của bạn:

client_max_body_size 256M;

Reload lại bằng sudo nginx -t && sudo systemctl reload nginx. Nếu bạn đang chạy Nginx và những chỉnh sửa PHP “chẳng ăn thua gì”, thì gần như chắc chắn là do cái này.

Sau mỗi lần thay đổi, hãy kiểm tra lại các giá trị được báo cáo. Công cụ kiểm tra dung lượng upload tối đa sẽ cho bạn biết trần hiệu lực mới và tạo ra đoạn cấu hình chính xác cho hệ thống của bạn, để bạn khỏi phải đoán xem cái nào trong ba giá trị vẫn còn thấp.

Những điều không nên làm

Đừng sửa wp-config.php rồi mong nó nâng được giới hạn. Dòng code được sao chép khắp nơi này không làm được điều mà các bài blog tuyên bố:

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

upload_max_filesize là PHP_INI_PERDIR. Nó không thể bị thay đổi từ PHP lúc runtime bằng ini_set(). Nó chỉ nhận giá trị mới từ php.ini, .htaccess, hoặc .user.ini — không bao giờ từ code ứng dụng. Dòng đó chạy mà không báo lỗi và cũng chẳng làm gì cả, khiến nó trở thành một trong những lời khuyên sai nhưng được lặp lại đầy tự tin nhất trong giới WordPress.

Cũng đừng dán @ini_set('post_max_size', ...) — cùng một hạn chế, cùng một kiểu âm thầm vô tác dụng.

Đừng đặt WP_MEMORY_LIMIT rồi tưởng đó là giới hạn upload. Nó kiểm soát trần bộ nhớ của PHP dành cho việc chạy code. Nó không liên quan gì tới việc server chấp nhận file lớn cỡ nào.

Đừng dừng lại ở một file. Lỗi phổ biến nhất là chỉ đổi mỗi upload_max_filesize rồi tuyên bố cách sửa bị hỏng. Hãy đổi cả ba, và giữ post_max_size cao hơn upload_max_filesize.

Đừng đặt giới hạn cao ngất “cho chắc”. Giới hạn 2 GB chỉ chuốc thêm các vấn đề cạn kiệt tài nguyên mà chẳng giúp ích gì — nếu bạn thật sự cần các file cỡ nhiều gigabyte, hãy up chúng bên ngoài trình duyệt (SFTP, hoặc một plugin upload theo từng khối) thay vì ép chúng qua một request POST duy nhất của PHP.

Vẫn bí?

Nếu cả ba giá trị đã được nâng mà bạn vẫn đụng tường, thì request đang bị chặn ở đâu đó phía trên server của bạn: một CDN hoặc proxy (dashboard của Cloudflare tự giới hạn dung lượng body của upload), một giới hạn nền tảng của managed host phớt lờ php.ini của bạn, hoặc một .user.ini chưa được làm mới — nó tuân theo user_ini.cache_ttl của PHP, nên có thể trễ vài phút sau khi bạn lưu. Hãy xác nhận xem server thực sự báo cáo cái gì, chứ không phải cái bạn đã viết trong file, rồi sửa đúng lớp vẫn còn thấp. Khi con số được báo cáo cuối cùng khớp với mục tiêu của bạn, lượt upload sẽ chạy.