Skonfigurowali Państwo motyw, dodali kilkanaście wtyczek, zdefiniowali niestandardowe pola i wtedy WordPress przestaje zapisywać ustawienia menu. Niby klikają Państwo „Zapisz", a część pozycji po prostu znika.

To nie błąd panelu administracyjnego ani wina wtyczek. PHP na serwerze natrafił na limit zmiennych wejściowych max_input_vars i po cichu obcina dane przychodzące z formularza. Domyślna wartość limitu, 1000, jest dla współczesnej instalacji WordPressa z kilkoma rozbudowanymi wtyczkami zdecydowanie niewystarczająca.

Poniżej trzy sposoby na podniesienie limitu: od szybkiej poprawki w.htaccess po ustawienia po stronie hostingu. Wszystkie metody przetestowano na Apache i PHP-FPM, działają od PHP 7.4 do 8.4.

Czym jest max_input_vars i jak objawia się błąd

max_input_vars, to dyrektywa PHP, która ogranicza liczbę zmiennych przyjmowanych z żądań GET, POST i COOKIE. Ograniczenie działa na każdą superglobalną tablicę osobno: zmienne POST są zliczane niezależnie od GET i COOKIE.

Dla małej wizytówki tysiąc zmiennych to aż nadto. Jednak panel administracyjny WordPressa generuje dziesiątki pól dla każdej encji: pozycje menu, widgety, opcje konfiguratora, metaboxy wtyczek. Gdy formularz menu zawiera 80 pozycji, z których każda przesyła 12-15 zmiennych, limit zostaje przekroczony niezauważalnie i część danych jest tracona podczas zapisywania.

Objawy wskazujące właśnie na ten problem:

• Pozycje menu nie zapisują się lub zapisują się częściowo.
• Widgety samoczynnie przenoszą się do nieaktywnych.
• Wtyczka (na przykład SEO lub konstruktor stron) traci część ustawień po zapisaniu.
• W Site Health (Narzędzia → Site Health → Info → Server) wartość PHP max input variables wynosi 1000 lub mniej.

Standardowa rekomendacja społeczności WordPressa to podniesienie limitu do 3000. To wystarcza dla większości instalacji. Dla witryn ze szczególnie rozbudowanym panelem administracyjnym (wielopoziomowe menu na 100+ pozycji, Mega Menu, dziesiątki pól ACF) można śmiało ustawić 5000 lub nawet 10000, nie wpływa to praktycznie na wydajność serwera.

💡 Szybki przegląd:

• Proszę sprawdzić bieżący limit: phpinfo() lub Site Health w panelu WordPress.
• Sposób 1: proszę dodać php_value max_input_vars 3000 do pliku.htaccess, działa przy Apache z mod_php.
• Sposób 2: proszę wpisać max_input_vars = 3000 w php.ini lub.user.ini, odpowiednie dla PHP-FPM.
• Sposób 3: proszę zmienić wartość przez panel hostingu, opcja dla tych, którzy nie mają bezpośredniego dostępu do plików serwera.

Sposób 1: edytujemy.htaccess

Metoda działa, gdy PHP jest uruchomione jako moduł Apache (mod_php). Można to sprawdzić w Narzędzia → Site Health → Info → Server: wiersz Server architecture zawiera Apache, a handler PHP jest wskazany jako moduł, nie FPM/FastCGI.

Przed edycją proszę zrobić kopię.htaccess: pobrać plik przez FTP lub menedżer plików hostingu na komputer. Edycje w tym pliku są wrażliwe na składnię, zbędna spacja lub znak nowej linii mogą spowodować błąd 500 na stronie.

Proszę otworzyć.htaccess (znajduje się w katalogu głównym witryny, obok wp-config.php) i dodać wiersz:

1
php_value max_input_vars 3000

Jeśli na serwerze jest zainstalowane rozszerzenie Suhosin (rzadkość w 2026 roku, ale zdarza się na starych hostingach współdzielonych), jeden wiersz nie wystarczy. Proszę dodać trzy dyrektywy:

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 przechwytuje zmienne przed PHP i obcina je niezależnie od max_input_vars, stąd dodatkowy zestaw wierszy.

Po zapisaniu.htaccess proszę otworzyć panel WordPress → Narzędzia → Site Health → Info → Server i upewnić się, że PHP max input variables pokazuje nową wartość. Jeśli się nie zmieniło, proszę przeczytać sekcję „Co zrobić, jeśli limit nadal się nie zmienia" poniżej.

Sposób 2: edytujemy php.ini lub.user.ini

Na nowoczesnych serwerach PHP najczęściej działa przez PHP-FPM i dyrektywy php_value w.htaccess są ignorowane. Działającym narzędziem jest tutaj php.ini lub.user.ini.

.user.ini jest stosowany przez PHP-FPM na bazie katalogu: plik umieszcza się w katalogu głównym witryny i działa rekurencyjnie na wszystkie podfoldery, w przeciwieństwie do .htaccess, który Apache odczytuje przy każdym żądaniu. To standardowy mechanizm PHP, wspierany od wersji 5.3.

Proszę utworzyć (lub edytować istniejący) plik .user.ini w katalogu głównym witryny i dodać:

1
max_input_vars = 3000

Jeśli mają Państwo dostęp do globalnego php.ini (VPS/serwer dedykowany), proszę zmienić wartość właśnie tam. Dokładną ścieżkę do php.ini wskaże phpinfo(): proszę znaleźć wiersz Loaded Configuration File. Po edycji php.ini obowiązkowy jest restart PHP-FPM:

1
sudo systemctl restart php8.2-fpm

Numer wersji w poleceniu proszę zastąpić swoim (8.1, 8.2, 8.3, 8.4). Proszę sprawdzić nową wartość przez Site Health, powinna zaktualizować się natychmiast.

Jeśli pliku .user.ini nie ma, proszę go po prostu utworzyć w edytorze tekstowym. Nazwa zaczyna się od kropki, dlatego w menedżerze plików hostingu może być konieczne włączenie wyświetlania ukrytych plików.

Sposób 3: zmieniamy limit przez panel hostingu

Dla hostingów współdzielonych (cPanel, ISPmanager, DirectAdmin) najprostszą drogą jest zmiana wartości przez interfejs graficzny, bez ręcznego ruszania plików.

cPanel: proszę wejść w Select PHP Version → przełączyć się na zakładkę Options. Znaleźć wiersz max_input_vars, zmienić wartość z 1000 na 3000 i kliknąć Save. Zmiana jest stosowana natychmiast, restart nie jest potrzebny.

ISPmanager: sekcja PHP → ustawienia → parametry dodatkowe → max_input_vars.

DirectAdmin: PHP Settings → znaleźć dyrektywę na liście → zmienić → zapisać.

Jeśli w panelu nie ma pola max_input_vars, hosting używa sztywno zdefiniowanego php.ini bez prawa do edycji. W takim przypadku pomaga tylko kontakt z pomocą techniczną: proszę napisać zgłoszenie z prośbą o podniesienie max_input_vars do 3000 (lub konkretnej wartości, której Państwo potrzebują). Większość dostawców zmienia limit na pierwszą prośbę, to rutynowa operacja.

Co zrobić, jeśli limit nadal się nie zmienia

Sytuacja: wiersze w.htaccess i.user.ini są wpisane, panel hostingu pokazuje nową wartość, a Site Health upiera się przy 1000. Przyczyny i ich rozwiązania:

Niewłaściwy sposób zmiany. max_input_vars należy do trybu PHP_INI_PERDIR: dyrektywę zmienia się tylko w php.ini,.htaccess,.user.ini lub httpd.conf. Funkcja ini_set() w wp-config.php nie działa na nią, kod @ini_set('max_input_vars', 3000) wykonuje operację, ale PHP po cichu ją ignoruje. Proszę nie tracić czasu na tę metodę.

Cache konfiguracji PHP. Niektóre panele (szczególnie cPanel z PHP-FPM) cache'ują pliki ini. Po edycji.user.ini proszę odczekać 5 minut, tyle PHP-FPM domyślnie trzyma cache konfiguracji dla konkretnego katalogu. Przyspieszyć proces można restartem PHP-FPM z panelu hostingu.

Dwa pliki php.ini. Na hostingach współdzielonych często znajduje się globalny php.ini w jednym folderze i lokalny w innym. PHP pobiera pierwszy znaleziony podczas startu. Proszę sprawdzić przez phpinfo() ścieżkę do Loaded Configuration File i edytować właśnie ten plik. Dodatkowy Scan this directory for additional .ini files również może zawierać limit, proszę sprawdzić i ten folder.

Sztywny limit hostingu. Niektórzy dostawcy blokują zmianę max_input_vars na poziomie kontenera (CloudLinux z limitami PHP Selector). W phpinfo() dyrektywa jest oznaczona jako no value lub nie wyświetla się wcale. Oznacza to, że hosting ustawił pułap powyżej możliwości edycji przez użytkownika, pomoże tylko zgłoszenie do pomocy technicznej lub zmiana taryfy.

⁉️🤔 Często zadawane pytania

Ile dokładnie ustawić, 3000 czy więcej?

Dla zdecydowanej większości stron na WordPressie wystarcza 3000. Ta wartość obsługuje menu do 120 pozycji, panel administracyjny z kilkunastoma aktywnymi wtyczkami i stronę konfiguratora z kilkunastoma sekcjami. Proszę ustawić 5000, jeśli używają Państwo Mega Menu na 150+ pozycji, konstruktora typu Elementor z setką pól na stronę lub ACF z elastycznymi układami. Powyżej 10000 tylko wtedy, gdy twórca wtyczki wyraźnie zaleca to w dokumentacji.

Dlaczego po aktualizacji PHP limit zresetował się na 1000?

Aktualizacja wersji PHP przez panel hostingu często pobiera domyślny php.ini. Proszę sprawdzić.user.ini i panel, najprawdopodobniej plik pozostał na miejscu, ale hosting przełączył pulę na nowy config bez Państwa poprawek.

Czy można ustawić limit przez wp-config.php?

Nie. Dyrektywa max_input_vars ma tryb PHP_INI_PERDIR i nie zmienia się przez ini_set(), PHP po cichu zignoruje takie wywołanie. Działają tylko.htaccess (na Apache z mod_php),.user.ini / php.ini i panel hostingu.

Jak zrozumieć, że problem dotyczy właśnie max_input_vars, a nie czegoś innego?

Najdokładniejszym wskaźnikiem są logi PHP. Proszę włączyć WP_DEBUG w wp-config.php: define('WP_DEBUG', true);. Po nieudanym zapisaniu formularza proszę sprawdzić /wp-content/debug.log: jeśli znajduje się tam wpis Warning: Input variables exceeded 1000, diagnoza jest potwierdzona.

Co zrobić, jeśli hosting nie pozwala zmienić limitu?

Proszę napisać do pomocy technicznej z konkretną liczbą (na przykład „proszę podnieść max_input_vars do 3000"). To standardowe żądanie, pomoc techniczna realizuje je bezpłatnie u większości dostawców. Odmawiają w dwóch przypadkach: skrajnie tania taryfa ze sztywno ustalonymi limitami (wtedy tylko upgrade) lub strona na hostingu współdzielonym z setkami sąsiadów, gdzie indywidualne limity nie są przewidziane przez architekturę.

Podsumowanie: który sposób wybrać w Państwa sytuacji

Kolejność działań, od najprostszego do najtrudniejszego.

Jeśli są Państwo na hostingu współdzielonym z cPanel, proszę zacząć od sposobu 3 (panel). To trzy kliknięcia i w większości przypadków problem jest rozwiązany. Jeśli wartość nie zmieniła się w Site Health, proszę spróbować sposobu 2 przez.user.ini: plik umieszcza się w katalogu głównym witryny i jest automatycznie pobierany przez PHP-FPM.

Mają Państwo VPS lub serwer dedykowany z Apache i mod_php, sposób 1 (.htaccess) daje natychmiastowy rezultat i nie wymaga restartu usług. Konfiguracja Apache + PHP-FPM, sposób 2 (php.ini lub.user.ini).

Panel nie pozwala edytować, pomoc techniczna nie odpowiada, limit zamarł na 1000, być może wyrośli Państwo z obecnej taryfy. Instalacje WordPressa z roku na rok stają się cięższe: więcej pól, więcej danych, wyższe wymagania wobec środowiska serwerowego. Zmiana hostingu na bardziej elastyczną taryfę rozwiązuje problem radykalnie i przy okazji podnosi ogólną wydajność strony.

Proszę zacząć od sprawdzenia Site Health już teraz: Narzędzia → Site Health → Info → Server → PHP max input variables. Jeśli jest tam 1000 lub mniej, którekolwiek z trzech powyższych rozwiązań przywróci Państwu kontrolę nad panelem administracyjnym w 5 minut.