Как увеличить максимальный размер загружаемого файла в 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, поэтому может отставать на несколько минут после сохранения. Убедитесь, что именно сообщает сервер, а не что вы написали в файле, и правьте тот слой, который всё ещё занижен. Когда показываемое число наконец совпадёт с вашей целью, загрузка заработает.