Настроили тему, добавили десяток плагинов, прописали кастомные поля, и тут WordPress перестаёт сохранять настройки меню. Вроде нажимаете «Сохранить», а часть пунктов просто исчезает.

Это не глюк админки и не вина плагинов. PHP на сервере упёрся в лимит входных переменных max_input_vars и молча обрезает данные, которые прилетают от формы. По умолчанию лимит равен 1000, чего современной сборке WordPress с парой тяжёлых плагинов откровенно не хватает.

Ниже, три способа поднять лимит: от быстрой правки.htaccess до настроек на стороне хостинга. Все методы проверены на Apache и PHP-FPM, работают от PHP 7.4 до 8.4.

Что такое max_input_vars и как проявляется ошибка

max_input_vars, это директива PHP, которая ограничивает количество переменных, принимаемых из GET, POST и COOKIE-запросов. Ограничение действует на каждый суперглобальный массив отдельно: POST-переменные считаются независимо от GET и COOKIE.

Для маленького сайта-визитки тысячи переменных более чем достаточно. Но WordPress-админка генерирует десятки полей на каждую сущность: пункты меню, виджеты, опции кастомайзера, метабоксы плагинов. Когда форма меню содержит 80 пунктов, каждый из которых передаёт 12-15 переменных, лимит превышается незаметно для глаза и часть данных теряется при сохранении.

Симптомы, которые указывают именно на эту проблему:

• Пункты меню не сохраняются или сохраняются частично.
• Виджеты самопроизвольно сбрасываются в неактивные.
• Плагин (например, SEO-плагин или конструктор страниц) теряет часть настроек после сохранения.
• В Site Health (Tools → Site Health → Info → Server) значение PHP max input variables равно 1000 или меньше.

Стандартная рекомендация WordPress-сообщества, поднять лимит до 3000. Этого хватает для большинства сборок. Сайтам с особо тяжёлыми админками (многоуровневые меню на 100+ пунктов, Mega Menu, десятки ACF-полей) можно смело ставить 5000 или даже 10000, на производительность сервера это практически не влияет.

💡 Быстрый обзор:

• Узнайте текущий лимит: phpinfo() или Site Health в админке WordPress.
• Способ 1: добавьте php_value max_input_vars 3000 в файл.htaccess, работает при Apache с mod_php.
• Способ 2: пропишите max_input_vars = 3000 в php.ini или.user.ini, подходит для PHP-FPM.
• Способ 3: измените значение через панель хостинга, вариант для тех, у кого нет доступа к серверным файлам напрямую.

Способ 1: правим.htaccess

Метод работает, когда PHP запущен как модуль Apache (mod_php). Определить это можно в Tools → Site Health → Info → Server: строка Server architecture содержит Apache, а PHP-обработчик указан как модуль, не FPM/FastCGI.

Перед правкой сделайте копию.htaccess: скачайте файл через FTP или файловый менеджер хостинга на компьютер. Правки в этот файл чувствительны к синтаксису, лишний пробел или перенос строки могут положить сайт ошибкой 500.

Откройте.htaccess (лежит в корне сайта, рядом с wp-config.php) и добавьте строку:

1
php_value max_input_vars 3000

Если на сервере установлено расширение Suhosin (редкость в 2026 году, но встречается на старых shared-хостингах), одной строки недостаточно. Добавьте три директивы:

1
php_value suhosin.request.max_vars 3000
2
php_value suhosin.post.max_vars 3000
3
php_value suhosin.get.max_vars 3000

Suhosin перехватывает переменные до PHP и обрезает их независимо от max_input_vars, отсюда и дополнительный набор строк.

После сохранения.htaccess откройте админку WordPress → Tools → Site Health → Info → Server и убедитесь, что PHP max input variables показывает новое значение. Не поменялось, читайте раздел «Что делать, если лимит всё равно не меняется» ниже.

Способ 2: правим php.ini или.user.ini

На современных серверах PHP чаще всего работает через PHP-FPM, и директивы php_value в.htaccess игнорируются. Рабочий инструмент здесь, php.ini или.user.ini.

.user.ini применяется PHP-FPM на посуточной основе: файл кладётся в корень сайта и действует рекурсивно на все вложенные папки, в отличие от .htaccess, который Apache читает на каждом запросе. Это штатный механизм PHP, поддерживается с версии 5.3.

Создайте (или отредактируйте существующий) файл .user.ini в корне сайта и добавьте:

1
max_input_vars = 3000

Если у вас есть доступ к глобальному php.ini (VPS/выделенный сервер), меняйте значение там же. Точный путь к php.ini подскажет phpinfo(): найдите строку Loaded Configuration File. После правки php.ini обязателен перезапуск PHP-FPM:

1
sudo systemctl restart php8.2-fpm

Номер версии в команде замените на свою (8.1, 8.2, 8.3, 8.4). Проверьте новое значение через Site Health, оно должно обновиться немедленно.

Если файла .user.ini нет, просто создайте его в текстовом редакторе. Имя начинается с точки, поэтому в файловом менеджере хостинга может потребоваться включить отображение скрытых файлов.

Способ 3: меняем лимит через панель хостинга

Для shared-хостингов (cPanel, ISPmanager, DirectAdmin) самый простой путь, поменять значение через графический интерфейс, не трогая файлы руками.

cPanel: зайдите в Select PHP Version → переключитесь на вкладку Options. Найдите строку max_input_vars, измените значение с 1000 на 3000 и нажмите Save. Изменение применяется мгновенно, перезапуск не требуется.

ISPmanager: раздел PHP → настройки → дополнительные параметры → max_input_vars.

DirectAdmin: PHP Settings → найти директиву в списке → изменить → сохранить.

Если в панели нет поля max_input_vars, хостинг использует жёстко заданный php.ini без права редактирования. В этом случае помогает только обращение в поддержку: напишите тикет с просьбой поднять max_input_vars до 3000 (или конкретного значения, которое вам нужно). Большинство хостеров меняют лимит по первому запросу, это рядовая операция.

Что делать, если лимит всё равно не меняется

Ситуация: строки в.htaccess и.user.ini прописаны, панель хостинга показывает новое значение, а Site Health упирается в 1000. Причины, и их решения:

Упёрлись в способ изменения. max_input_vars относится к режиму PHP_INI_PERDIR: директива меняется только в php.ini,.htaccess,.user.ini или httpd.conf. Функция ini_set() в wp-config.php на неё не действует, код @ini_set('max_input_vars', 3000) выполняет операцию, но PHP молча игнорирует её. Не тратьте время на этот метод.

Кеш PHP-конфигурации. Некоторые панели (особенно cPanel с PHP-FPM) кешируют ini-файлы. После правки.user.ini подождите 5 минут, именно столько PHP-FPM по умолчанию держит кеш конфигурации для конкретной директории. Ускорить процесс можно перезапуском PHP-FPM из панели хостинга.

Два php.ini. На shared-хостингах часто лежит глобальный php.ini в одной папке и локальный, в другой. PHP подхватывает первый найденный при старте. Проверьте через phpinfo() путь к Loaded Configuration File и прави́те именно его. Дополнительный Scan this directory for additional .ini files тоже может содержать лимит, проверьте и эту папку.

Жёсткий лимит хостинга. Некоторые провайдеры блокируют изменение max_input_vars на уровне контейнера (CloudLinux с лимитами PHP Selector). В phpinfo() директива отмечена как no value или не отображается вовсе. Это означает, что хостинг установил потолок выше правки пользователя, поможет только тикет в поддержку или смена тарифа.

⁉️🤔 Частые вопросы

Сколько именно ставить, 3000 или больше?

Для подавляющего большинства сайтов на WordPress хватает 3000. Это значение закрывает меню до 120 пунктов, админку с десятком активных плагинов и страницу кастомайзера с десятком секций. Ставьте 5000, если используете Mega Menu на 150+ пунктов, конструктор вроде Elementor с сотней полей на страницу или ACF с гибкими макетами. Выше 10000, только если разработчик плагина явно прописал это в документации.

Почему после обновления PHP лимит сбросился на 1000?

Обновление версии PHP через панель хостинга часто подтягивает дефолтный php.ini. Проверьте.user.ini и панель, скорее всего, файл остался на месте, но хостинг переключил пул на новый конфиг без ваших правок.

Можно ли задать лимит через wp-config.php?

Нет. Директива max_input_vars имеет режим PHP_INI_PERDIR и не меняется через ini_set(), PHP молча проигнорирует такой вызов. Работают только.htaccess (на Apache с mod_php),.user.ini / php.ini и панель хостинга.

Как понять, что проблема именно в max_input_vars, а не в чём-то другом?

Самый точный индикатор, логи PHP. Включите WP_DEBUG в wp-config.php: define('WP_DEBUG', true);. После неудачного сохранения формы проверьте /wp-content/debug.log: если там есть запись Warning: Input variables exceeded 1000, диагноз подтверждён.

Что делать, если хостинг не даёт менять лимит?

Напишите в поддержку с конкретной цифрой (например, «поднимите max_input_vars до 3000»). Это стандартный запрос, поддержка выполняет его бесплатно у большинства провайдеров. Отказывают в двух случаях: предельно дешёвый тариф с жёстко фиксированными лимитами (тогда только апгрейд) или сайт на общем хостинге с сотнями соседей, где индивидуальные лимиты не предусмотрены архитектурой.

Итоги: какой способ выбрать под вашу ситуацию

Порядок действий, от самого простого к самому сложному.

Если вы на shared-хостинге с cPanel, начните со способа 3 (панель). Это три клика, и в большинстве случаев проблема решена. Значение не поменялось в Site Health, попробуйте способ 2 через.user.ini: файл кладётся в корень сайта и подхватывается PHP-FPM автоматически.

У вас VPS или выделенный сервер с Apache и mod_php, способ 1 (.htaccess) даёт мгновенный результат и не требует перезапуска сервисов. Связка Apache + PHP-FPM, способ 2 (php.ini или.user.ini).

Панель не даёт править, поддержка не отвечает, лимит застыл на 1000, возможно, вы переросли текущий тариф. WordPress-сборки с каждым годом тяжелеют: больше полей, больше данных, выше требования к серверному окружению. Смена хостинга на более гибкий тариф решает проблему радикально и заодно поднимает общую производительность сайта.

Начните с проверки Site Health прямо сейчас: Tools → Site Health → Info → Server → PHP max input variables. Если там 1000 или меньше, любое из трёх решений выше вернёт вам контроль над админкой за 5 минут.