Налаштували тему, додали десяток плагінів, прописали кастомні поля, і тут 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 хвилин.