С этой ошибкой обычно сталкиваются в самый неподходящий момент: файл уже готов, картинка выбрана, плагин установлен, а WordPress вдруг отказывает в загрузке. Сообщение звучит сухо, но за ним всегда стоит вполне конкретное ограничение на стороне сервера. Хорошая новость в том, что проблему можно решить, если понять, где именно задан лимит и кто его контролирует.
В WordPress этот барьер почти никогда не связан с самой системой. Чаще всего он приходит из настроек PHP, а иногда еще и из конфигурации хостинга. Поэтому искать кнопку внутри админки обычно бесполезно. Нужно смотреть выше: в параметры сервера, файл конфигурации или панель управления хостингом.
Откуда берется ограничение на размер файла
Сообщение о том, что размер загружаемого файла превышает upload_max_filesize, появляется, когда PHP не разрешает принять файл больше заданного порога. Это ограничение действует еще до того, как WordPress успеет обработать загрузку. Поэтому сама CMS в таких случаях лишь показывает результат, а не источник проблемы.
На практике важны сразу несколько параметров. Главный из них upload_max_filesize, но рядом с ним обычно стоят post_max_size и memory_limit. Если поднять только один показатель, а остальные оставить без изменений, загрузка все равно может не пройти. Сервер сравнивает их между собой, и самое жесткое значение часто становится решающим.
В WordPress это особенно заметно при загрузке больших изображений, архивов с темами, плагинов или бэкапов. У сайтов на общем хостинге лимиты часто выставляют довольно низко, чтобы нагрузка распределялась равномерно. На VPS и выделенных серверах контроль обычно шире, но и там настройки редко бывают идеальными с первого раза.
«В большинстве случаев проблема не в WordPress, а в том, как на сервере настроен PHP. Админка тут только показывает последствия». — практикующий серверный администратор
«Если upload_max_filesize поднят, а post_max_size нет, загрузка больших файлов все равно может ломаться. Эти параметры нужно смотреть вместе». — веб-разработчик, работающий с WordPress-проектами
С чего начать проверку
Первый шаг простой: посмотрите, какие лимиты сейчас видит WordPress. В админке это можно найти в разделе «Медиафайлы» или на странице информации о системе, если установлен соответствующий плагин. Там часто показывается максимально допустимый размер файла и часть серверных параметров. Это помогает понять, насколько далеко вы от нужного значения.
Если доступ к панели хостинга есть, стоит заглянуть туда раньше, чем лезть в файлы сайта. Многие провайдеры дают возможность менять параметры PHP через встроенные настройки. Это удобнее и безопаснее, чем редактировать конфигурацию вручную. К тому же изменения из панели обычно применяются быстрее.
В своей работе я несколько раз сталкивался с ситуацией, когда владелец сайта пытался решить вопрос через WordPress-плагины. Это почти никогда не помогает, если ограничение стоит на стороне сервера. Плагин может показать текущие значения, но не всегда способен их изменить. В итоге время уходит, а ошибка остается на месте.
Какие параметры важны в первую очередь
Есть три значения, которые стоит проверить в первую очередь: upload_max_filesize, post_max_size и memory_limit. Первый задает максимальный размер одного файла. Второй ограничивает общий размер отправляемых данных. Третий определяет, сколько памяти может использовать PHP в процессе обработки запроса.
Если загружается архив на 64 МБ, upload_max_filesize должен быть выше этого значения. Но post_max_size желательно ставить еще больше, иначе форма загрузки может не принять весь запрос целиком. memory_limit тоже лучше не оставлять на минимуме, особенно если сайт работает с изображениями, миниатюрами и плагинами оптимизации.
| Параметр | Что ограничивает | На что влияет |
|---|---|---|
| upload_max_filesize | Размер одного файла | Загрузка изображений, архивов, бэкапов |
| post_max_size | Общий размер POST-запроса | Формы, загрузка нескольких файлов сразу |
| memory_limit | Память для PHP | Обработка файлов, работа плагинов и тем |
Как увеличить лимит через панель хостинга
Это самый удобный путь, если хостинг-провайдер дает доступ к настройкам PHP. Обычно в панели есть раздел вроде «PHP версии», «Настройки PHP» или «Параметры интерпретатора». Там можно задать нужные значения вручную или выбрать готовый профиль. После сохранения изменения начинают действовать почти сразу, хотя иногда требуется несколько минут.
Часто в панели доступны поля для upload_max_filesize и post_max_size. В них можно указать значения вроде 64M, 128M или 256M. Важно, чтобы размеры были согласованы между собой. Если лимит на файл выше, чем общий лимит запроса, толку от изменения не будет.
У некоторых хостеров настройки разделены по версиям PHP. Это значит, что сайт работает на одной версии, а менять параметры нужно именно для нее. Такой момент легко пропустить. Поэтому сначала стоит убедиться, какая версия PHP используется на конкретном сайте, а уже потом менять лимиты.
Правка файла php.ini или пользовательских конфигураций
Если хостинг позволяет редактировать конфигурацию вручную, можно изменить значения в php.ini. Это классический способ, который подходит для VPS, выделенных серверов и части виртуального хостинга. В файл обычно добавляют строки с нужными параметрами, после чего перезапускают PHP или ждут применения настроек.
Пример выглядит так:
upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 256M
Иногда на хостинге отдельный php.ini недоступен, но разрешены файлы .user.ini. Тогда параметры прописывают там. Такой вариант часто встречается в современных средах, где root-доступа нет. И это нормально: логика та же, меняется только место, куда нужно внести значения.
Есть еще один практический нюанс. Если после редактирования лимит не изменился, причина может быть в кэше PHP или в том, что сервер использует другой конфигурационный файл. В таких случаях помогает проверка через phpinfo() или панель хостинга. Это быстрее, чем гадать по симптомам.
Пример безопасной настройки
Если сайт регулярно принимает крупные изображения или архивы тем, удобно оставить небольшой запас. Например, для файлов до 100 МБ можно поставить upload_max_filesize на 128M, post_max_size на 128M или 160M, а memory_limit на 256M. Такой запас полезен, когда к загрузке добавляется обработка изображений или работа плагинов безопасности.
Но слишком высокие значения тоже не всегда оправданы. На общем хостинге огромные лимиты могут создать лишнюю нагрузку, особенно если сайт часто принимает файлы от посетителей. Здесь лучше исходить из реальной задачи. Для блога, корпоративного сайта и интернет-магазина потребности обычно разные.
Если сервер работает на Apache или Nginx
Когда доступ к серверу полный, лимиты можно настраивать и на уровне веб-сервера. Для Apache это часто делают через .htaccess или через конфигурацию VirtualHost. Для Nginx обычно правят параметры PHP-FPM и правила обработки запросов. Здесь важно понимать, что Nginx сам по себе не задает upload_max_filesize, но может ограничивать размер тела запроса.
На Nginx стоит проверить параметр client_max_body_size. Если он меньше нужного размера, загрузка не пройдет, даже если PHP настроен правильно. Это типичный источник путаницы. Файл маленький по меркам PHP, но слишком большой для Nginx. Внешне ошибка выглядит одинаково, а причина совсем другая.
Если сайт работает на связке Nginx + PHP-FPM, лучше проверять настройки обеих сторон. Сначала лимит запроса в Nginx, потом параметры PHP. Такой порядок экономит время. Иначе можно долго менять upload_max_filesize, хотя блокировка живет совсем в другом месте.
Что делать, если лимит не меняется
Иногда настройки вроде бы исправлены, а WordPress продолжает показывать старую ошибку. В таких случаях стоит проверить кэш, саму версию PHP и наличие нескольких конфигураций на одном аккаунте. На некоторых хостингах одна часть сайта работает под одной средой, а другая под другой. Это нечасто, но встречается.
Еще один момент связан с правами на файлы. Если .user.ini, php.ini или .htaccess имеют неправильные права доступа, сервер может игнорировать изменения. То же самое бывает после переноса сайта. Файл на месте, строки правильные, а система их просто не читает. Тогда помогает проверка логов или обращение в поддержку хостинга.
Если загрузка нужна срочно, а лимит пока не получается поднять, можно временно использовать альтернативные способы. Например, загрузить файл через FTP в папку uploads, а потом зарегистрировать его в медиатеке через плагин. Этот путь не заменяет нормальную настройку, но выручает, когда сроки поджимают.
Полезный порядок действий
Сначала проверьте текущие лимиты в WordPress и панели хостинга. Затем сравните upload_max_filesize, post_max_size и memory_limit. После этого внесите изменения в правильный файл или через интерфейс провайдера. В конце протестируйте загрузку небольшим файлом, а потом тем, ради которого все и затевалось.
Если после всех шагов ошибка остается, не стоит делать хаотичные правки в нескольких местах сразу. Лучше вернуть изменения в исходное состояние и проверить логи сервера. Там обычно видно, какой именно параметр стал препятствием. Это проще, чем менять настройки наугад и надеяться на удачу.
Как не столкнуться с этой проблемой снова
Когда лимит уже поднят, полезно сразу зафиксировать, где именно вы вносили изменения. Это поможет при обновлении PHP, смене хостинга или переносе сайта. Хорошо, если рядом с сайтом хранится короткая заметка с актуальными значениями и файлом, в котором они заданы. Такая мелочь потом экономит часы.
Еще стоит помнить о реальных задачах сайта. Если контент часто загружается через медиатеку, лимит нужно держать с запасом. Если загрузка файлов редкая, нет смысла завышать параметры без необходимости. Баланс здесь важнее, чем максимальные цифры. Рабочий сайт обычно ценит не рекорды, а предсказуемость.
Ошибка с upload_max_filesize неприятна, но почти всегда решается довольно приземленно: через панель хостинга, конфигурацию PHP или настройки веб-сервера. Когда понимаешь, где именно сидит ограничение, ситуация перестает быть загадкой. А WordPress в таких случаях уже не мешает, а просто честно показывает, что серверу нужен другой лимит.
