Як збільшити максимальний розмір файлу для завантаження у WordPress

Ліміт завантаження у WordPress визначають три параметри, і всі вони мають узгоджуватися. Фактичний ліміт — це найменше зі значень upload_max_filesize, post_max_size та обмеження на розмір запиту вашого вебсервера. Підніміть одне значення, а два інших залиште низькими — і нічого не зміниться. Саме тому більшість людей роблять висновок, що їхнє виправлення «не спрацювало». Спершу перевірте свої поточні числа за допомогою інструмента для перевірки максимального розміру завантаження WordPress: він зчитує ті самі значення, які повідомляє WordPress, і показує, яке саме з них вас стримує.

Навіщо існує цей ліміт і де він живе

WordPress не встановлює ліміт завантаження. Він лише повідомляє про нього. Коли ви бачите повідомлення «The uploaded file exceeds the upload_max_filesize directive in php.ini», воно надходить безпосередньо від PHP.

Завантаження обмежують три окремі значення, і справжня стеля — те з них, що є найнижчим:

• upload_max_filesize (PHP) — найбільший окремий файл, який прийме PHP.
• post_max_size (PHP) — найбільший загальний обсяг тіла POST-запиту. Ваш файл передається всередині POST-запиту разом з іншими полями форми, тож це значення має бути більшим за upload_max_filesize.
• Обмеження тіла запиту вебсервера — client_max_body_size в Nginx або LimitRequestBody в Apache. Це значення живе повністю поза PHP, тому виправлення, що стосуються лише PHP, мовчки не спрацьовують за Nginx.

Четверте значення, max_execution_time, не обмежує розмір, але перерве повільне завантаження великого файлу посеред передавання за поганого з’єднання. Це окремий симптом, а не частина стелі розміру.

Пастка: ви встановлюєте upload_max_filesize = 256M, перезавантажуєте, але все одно не можете завантажити файл на 100 МБ — тому що post_max_size досі 8M. PHP відхиляє запит на рівні загального тіла ще до того, як почне перевіряти сам файл. Ліміт вас не проігнорував. Просто інший ліміт спрацював першим.

Як це виправити, крок за кроком

Дійте від найімовірнішого до останнього засобу.

1. Відредагуйте php.ini (правильне місце). Знайдіть файл, який насправді завантажує ваш сайт — запустіть сторінку з <?php phpinfo(); і подивіться на рядок «Loaded Configuration File», або запитайте свій хостинг. Встановіть обидва значення PHP і тримайте post_max_size більшим за upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Перезапустіть PHP-FPM (sudo systemctl restart php8.2-fpm) або Apache. Зміни не діють, доки процес PHP не перезапуститься.

2. Немає доступу до php.ini? Скористайтеся .htaccess (лише Apache + mod_php). Додайте до .htaccess у кореневій теці WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Це працює лише тоді, коли PHP запущено як модуль Apache. Під PHP-FPM, CGI чи FastCGI php_value викине помилку 500 — і ця невдача означає, що ви пішли хибним шляхом, а не що число неправильне. Перейдіть на .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Підніміть ліміт вебсервера — крок, про який усі забувають. У Nginx PHP навіть не бачить завеликий запит; Nginx першим повертає 413 Request Entity Too Large. У блоці server:

client_max_body_size 256M;

Перезавантажте командою sudo nginx -t && sudo systemctl reload nginx. Якщо ви на Nginx і ваші правки PHP «нічого не дали», майже завжди причина саме в цьому.

Після будь-якої зміни знову перевірте повідомлені значення. Інструмент для перевірки максимального розміру завантаження підкаже вам нову фактичну стелю і згенерує точний фрагмент коду для вашого налаштування, тож вам не доведеться вгадувати, яке з трьох значень досі занизьке.

Чого робити не варто

Не редагуйте wp-config.php в надії, що це підніме ліміт. Широко скопійований рядок не робить того, що стверджують у блогах:

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

upload_max_filesize має рівень PHP_INI_PERDIR. Його неможливо змінити з PHP під час виконання за допомогою ini_set(). Він приймає нові значення лише з php.ini, .htaccess чи .user.ini — ніколи з коду застосунку. Рядок виконується без помилок і не робить нічого, що робить його однією з найвпевненіше повторюваних порад-помилок у WordPress.

Не вставляйте також @ini_set('post_max_size', ...) — те саме обмеження, та сама мовчазна безрезультатність.

Не встановлюйте WP_MEMORY_LIMIT, думаючи, що це ліміт завантаження. Він керує стелею пам’яті PHP для виконання коду. Це не пов’язано з тим, наскільки великий файл приймає сервер.

Не зупиняйтеся на одному файлі. Найпоширеніша помилка — змінити лише upload_max_filesize і оголосити виправлення непрацездатним. Змініть усі три значення і тримайте post_max_size вище за upload_max_filesize.

Не встановлюйте абсурдно високі ліміти «про всяк випадок». Ліміт у 2 ГБ провокує проблеми з вичерпанням ресурсів і не допомагає — якщо вам справді потрібні файли на кілька гігабайтів, завантажуйте їх поза браузером (через SFTP або плагін частинного завантаження), а не проштовхуйте їх через єдиний POST-запит PHP.

Досі не виходить?

Якщо всі три значення підняті, а ви все одно натрапляєте на стіну, значить запит обмежується десь вище за ваш сервер: CDN або проксі (панель Cloudflare сама обмежує розмір тіла завантаження), платформенний ліміт керованого хостингу, що ігнорує ваш php.ini, або .user.ini, який ще не оновився — він враховує user_ini.cache_ttl в PHP, тож може відставати на кілька хвилин після збереження. Перевіряйте, що насправді повідомляє сервер, а не те, що ви записали у файл, і виправляйте той рівень, який досі занизький. Коли повідомлене число нарешті збіжиться з вашою цільовою величиною, завантаження запрацює.