Znikające ustawienia w WordPressie? To może być limit max_input_vars

Wprowadzasz zmiany w menu, poprawiasz ustawienia motywu albo konfigurujesz wtyczkę, a po odświeżeniu panelu część z nich po prostu znika? Strona ładuje się normalnie, nie widać ani błędu 403, ani białego ekranu, a mimo to WordPress zachowuje się tak, jakby zapomniał części ustawień. Jednym z możliwych powodów takiego zachowania jest limit max_input_vars.

Taka sytuacja najczęściej dotyczy dużych formularzy w panelu administracyjnym: rozbudowanego menu, buildera stron, motywu z mnóstwem opcji konfiguracyjnych czy wtyczki z rozległym panelem ustawień. Przy zapisie WordPress wysyła do serwera bardzo dużo danych naraz, a jeśli limit po stronie PHP okaże się zbyt niski, część pól może zostać pominięta. Poniżej wyjaśniamy, na czym polega działanie max_input_vars, jak rozpoznać jego objawy i kiedy podniesienie limitu faktycznie pomaga.

Czym jest max_input_vars?

max_input_vars to parametr konfiguracyjny PHP, który definiuje maksymalną liczbę zmiennych wejściowych akceptowanych w pojedynczym żądaniu. W praktyce chodzi o liczbę pól, jakie formularz może jednorazowo przesłać do serwera. W panelu WordPressa mnóstwo funkcji działa właśnie na zasadzie formularza — zapis menu, ustawień motywu, konfiguracji wtyczki czy rozbudowanej strony opcji wiąże się z wysłaniem całego pakietu danych. Każda pozycja menu, każda opcja, każdy checkbox i każde ukryte pole zwiększają liczbę przesyłanych zmiennych.

Kiedy liczba pól przekracza dozwolony limit, serwer nie jest w stanie przyjąć wszystkich danych. Efekt bywa mylący, bo WordPress niekoniecznie pokaże czytelny komunikat błędu — czasem wygląda to tak, jakby zapis zakończył się sukcesem, a dopiero po odświeżeniu strony część zmian znika. To właśnie sprawia, że problem z max_input_vars jest trudniejszy do wychwycenia niż klasyczne błędy 500 czy 403. Panel się ładuje, przycisk „Zapisz” reaguje prawidłowo, a mimo to część informacji nigdzie nie trafia.

Po czym poznać problem z zapisem zmian w WordPressie?

Symptomy zwykle nie rzucają się w oczy. Użytkownik widzi, że coś się nie zapisało, ale nie otrzymuje żadnej wskazówki co do przyczyny.

• po zapisaniu menu znikają ostatnio dodane pozycje
• kolejność elementów menu wraca do wcześniejszego układu
• część ustawień motywu nie zostaje zapamiętana mimo zapisu
• builder zapisuje stronę tylko fragmentarycznie
• konfiguracja wtyczki wraca do poprzednich wartości
• formularz ustawień zapisuje początkowe pola, a resztę pomija
• kłopot pojawia się dopiero po rozbudowaniu menu lub formularza
• drobne zmiany zapisują się bez problemu, większe już nie

Charakterystyczne jest to, że usterka daje o sobie znać dopiero po przekroczeniu określonej skali. Niewielkie menu funkcjonuje bez zarzutu, kilka ustawień wtyczki zapisuje się poprawnie — dopiero większa liczba pozycji, pól czy opcji sprawia, że WordPress zaczyna działać niestabilnie. To istotna wskazówka diagnostyczna: jeśli zapis działa przy prostym formularzu, a zawodzi przy bardzo rozbudowanym, warto zweryfikować limit max_input_vars.

Kiedy podejrzewać max_input_vars?

• zapis wygląda na udany, ale część zmian mimo to znika
• problem dotyczy dużego menu, megamenu lub rozbudowanego formularza
• niewielkie zmiany zapisują się bez zakłóceń
• nie pojawia się błąd 403 ani 500
• usterka wraca po rozbudowie menu lub ustawień
• po zapisie giną głównie ostatnie pola formularza
• problem zaczął się po dodaniu nowych opcji, języków, pozycji menu lub ustawień wtyczki

To jeszcze nie przesądza, że limit jest źródłem kłopotu, ale to jeden z pierwszych parametrów wartych sprawdzenia, gdy WordPress nie zapisuje wszystkich zmian, a sprawa dotyczy dużej liczby pól.

Najczęściej problem z max_input_vars ujawnia się w menu WordPressa. Z pozoru menu wygląda prosto — lista pozycji, linki, etykiety, kolejność. W rzeczywistości każda pozycja składa się z wielu pól: nazwy, adresu, typu elementu, identyfikatora, rodzica, kolejności, a niekiedy także dodatkowych ustawień dorzuconych przez motyw lub wtyczkę. Im większe menu, tym więcej danych trafia do jednego formularza.

Ryzyko przekroczenia limitu rośnie zwłaszcza wtedy, gdy:

• menu zawiera bardzo dużo pozycji
• struktura menu ma wiele poziomów zagnieżdżenia
• motyw dokłada dodatkowe pola do każdej pozycji menu
• wtyczka rozszerza menu o ikony, klasy CSS, etykiety, obrazki lub ustawienia widoczności
• strona posiada osobne menu dla różnych wersji językowych
• menu jest zbudowane jako rozbudowane megamenu

W takich warunkach limit można przekroczyć szybciej, niż mogłoby się wydawać. Użytkownik dodaje kolejną pozycję, klika „Zapisz menu”, panel wraca bez żadnego komunikatu o błędzie, ale ostatnie zmiany po prostu nie zostają zapisane. Wtedy warto nie tylko podnieść limit, ale też przyjrzeć się samej strukturze menu. Zbyt rozbudowane menu bywa problemem nie tylko dla panelu administracyjnego, ale też dla odwiedzających, którym trudniej trafić na najważniejsze podstrony. Gdy menu staje się zbyt duże, robi się cięższe w utrzymaniu, wolniejsze i mniej czytelne — wtedy warto rozważyć uproszczenie struktury, podział treści na logiczne sekcje albo ograniczenie dodatkowych pól generowanych przez motyw czy wtyczki.

Motywy, buildery i rozbudowane formularze ustawień

max_input_vars nie ogranicza się wyłącznie do menu. Podobny scenariusz może wystąpić wszędzie tam, gdzie WordPress przetwarza dużą liczbę pól naraz — a więc w przypadku:

• motywów z rozbudowanym panelem opcji
• builderów stron
• wtyczek SEO z rozległymi ustawieniami
• wtyczek formularzy
• wtyczek wielojęzycznych
• konfiguratorów wyglądu
• megamenu
• paneli z dużą liczbą checkboxów
• ustawień sklepu, dostawy, podatków lub integracji
• niestandardowych pól dodawanych przez wtyczki

Czasem trudności zaczynają się po aktualizacji motywu lub wtyczki, bo nowsze wersje wprowadzają kolejne pola konfiguracyjne. Innym razem to po prostu rozrost samej strony — nowe podstrony, kategorie, języki, elementy menu i sekcje ustawień sprawiają, że dotychczasowy limit, wcześniej wystarczający, zaczyna blokować część zapisów.

Warto jednak zachować ostrożność przy prostym stwierdzeniu, że „to na pewno max_input_vars”. Jeśli builder nie zapisuje strony, przyczyną może być równie dobrze konflikt wtyczek, błąd JavaScript, cache, blokada WAF, limit pamięci, timeout albo problem z REST API. Limit formularza to jeden z możliwych tropów, ale nie jedyny.

Kiedy to nie jest max_input_vars, tylko inny błąd WordPressa?

Problem z max_input_vars łatwo pomylić z innymi usterkami, ponieważ objawy bywają zbliżone: zmiany nie zapisują się prawidłowo albo znikają po odświeżeniu. Różnica leży w zachowaniu panelu i w tym, czy WordPress wyświetla dodatkowy komunikat błędu.

• brak komunikatu 403
• brak błędu 500
• panel administracyjny działa bez zakłóceń
• zapis pozornie przebiega poprawnie
• problem dotyczy głównie dużych formularzy
• mniejsze zmiany zapisują się normalnie
• znika część danych, najczęściej końcowe pola formularza
• problem nasila się wraz z rozbudową menu lub ustawień

Jeśli widzisz konkretny błąd, warto rozszerzyć diagnozę.

Błąd 500 przy zapisie zmian może wskazywać na kłopot po stronie serwera, PHP, wtyczki, motywu, limitu pamięci lub błędnej konfiguracji. Może wystąpić np. po kliknięciu „Zapisz”, w trakcie pracy buildera albo przy zapytaniu do admin-ajax.php. W takiej sytuacji lepiej zacząć od przejrzenia logów błędów i podstawowego debugowania WordPressa, zamiast od razu zakładać winę max_input_vars.

Błąd 403 przy zapisie zazwyczaj oznacza zablokowany dostęp. Zapis może zostać przerwany przez WAF, ModSecurity, wtyczkę bezpieczeństwa, blokadę IP albo regułę w .htaccess. Użytkownik widzi wtedy zwykle komunikat „Forbidden”, „Access denied” lub przerwaną akcję zapisu.

Błąd w edytorze blokowym lub builderze może wynikać z konfliktu JavaScript, niekompatybilnej wtyczki, usterki motywu, problemu z REST API albo cache. Objawy różnią się od tych typowych dla max_input_vars — przyciski nie reagują, edytor się nie ładuje, zapis zatrzymuje się w połowie procesu albo w konsoli przeglądarki pojawiają się komunikaty błędów.

Inaczej wygląda z kolei problem z cache. Zmiany mogą zostać poprawnie zapisane w panelu, ale nie widać ich od razu na froncie strony. Wówczas warto sprawdzić podgląd po zalogowaniu i wyczyścić cache strony, przeglądarki, CDN lub wtyczki optymalizacyjnej.

Warto też odróżnić max_input_vars od innych limitów PHP. Ten parametr nie ma wpływu na wielkość przesyłanego pliku ani na maksymalny rozmiar uploadu. Jeśli kłopot dotyczy wgrywania zdjęć, plików czy importu dużych danych, przyczyną mogą być inne ustawienia, takie jak upload_max_filesize, post_max_size czy memory_limit. W przypadku max_input_vars problem dotyczy przede wszystkim liczby pól w formularzu, a nie rozmiaru pojedynczego pliku.

Najprostszy sposób sprawdzenia jest praktyczny: warto zweryfikować, czy drobna zmiana zapisuje się poprawnie, a kłopot pojawia się dopiero przy dużym menu lub rozbudowanym formularzu. Jeśli tak, max_input_vars to dobry trop do dalszej diagnozy. Jeśli zamiast tego występuje błąd 500, 403, problem z AJAX-em albo niedziałający edytor, przyczyn trzeba szukać szerzej.

Czy zwiększenie limitu zawsze rozwiązuje problem?

Podniesienie max_input_vars może pomóc, ale nie zawsze stanowi kompletne rozwiązanie. Jeśli faktycznym powodem jest to, że formularz przesyła więcej pól, niż PHP jest w stanie przyjąć, zwiększenie limitu powinno poprawić zapis — dotyczy to zwłaszcza dużych menu, rozbudowanych ustawień motywu i paneli z mnóstwem pól.

Nie warto jednak traktować tego parametru jako jedynego winowajcy. Jeśli strona ma bardzo obciążony panel, wiele wtyczek, rozległy builder i ogromne formularze ustawień, samo podniesienie limitu może jedynie odsunąć problem w czasie.

• Czy menu naprawdę wymaga aż tylu pozycji?
• Czy wszystkie dodatki do menu są rzeczywiście potrzebne?
• Czy motyw nie przechowuje zbyt wielu ustawień w jednym formularzu?
• Czy wtyczki nie dublują tych samych funkcji?
• Czy konfiguracja strony nie jest nadmiernie rozbudowana?
• Czy problem nie pojawił się po instalacji konkretnej wtyczki?

Jeśli po każdej kolejnej rozbudowie menu trzeba podnosić limit, przyczyną może być nie tylko konfiguracja PHP, ale też sama struktura strony. Warto wtedy uprościć menu, ograniczyć dodatki do pozycji menu albo zweryfikować, czy motyw lub wtyczka nie generują zbyt wielu pól. Zbyt wysoki limit nie powinien usprawiedliwiać braku porządku w WordPressie — jeśli panel robi się coraz cięższy, zapis trwa długo, a formularze liczą setki czy tysiące pól, lepiej uporządkować konfigurację, niż wyłącznie zwiększać kolejne parametry.

Co sprawdzić przed zmianą parametrów PHP?

Zanim zmodyfikujesz max_input_vars, warto ustalić, czy problem faktycznie pasuje do tego scenariusza. Dzięki temu unikniesz przypadkowych zmian w konfiguracji PHP.

• czy kłopot dotyczy tylko dużego menu lub rozbudowanego formularza
• czy mniejsze zmiany zapisują się poprawnie
• czy po zapisie znika jedynie część danych
• czy w panelu pojawia się jakikolwiek komunikat błędu
• czy problem wystąpił po instalacji konkretnej wtyczki
• czy ostatnio zmieniano motyw, builder lub wtyczkę do menu
• czy problem dotyczy jednego konta użytkownika, czy wszystkich
• czy na stronie działa cache, WAF, CDN lub wtyczka bezpieczeństwa
• czy w logach widnieje informacja o przekroczeniu limitu zmiennych wejściowych

Osoby z dostępem do konfiguracji PHP mogą sprawdzić aktualną wartość max_input_vars. W panelu cyber_Folks parametry PHP zmienia się zgodnie z instrukcją opisaną w materiale pomocy „Jak zmienić parametry PHP?”. W niektórych przypadkach parametr można też ustawić poprzez wpis w pliku .htaccess, co omawia osobny materiał poświęcony budowie i najpopularniejszym wpisom tego pliku.

Przy edycji .htaccess trzeba jednak zachować ostrożność, bo nie każdy serwer obsługuje zmianę parametrów PHP przez wpisy typu php_value. Jeśli po takiej modyfikacji pojawi się błąd 500, należy cofnąć dodany wpis i skorzystać z ustawień PHP dostępnych w panelu hostingu albo zgłosić sprawę do supportu.

Przed wprowadzeniem zmian warto wykonać kopię zapasową albo przynajmniej upewnić się, że wiadomo, jak wrócić do poprzednich ustawień. Jeśli sprawa dotyczy strony produkcyjnej, większe modyfikacje najlepiej testować w spokojniejszym momencie lub na kopii testowej.

Dobre ustawienia pomagają, ale porządek w panelu też ma znaczenie

max_input_vars to jeden z tych parametrów, o których większość użytkowników WordPressa nie myśli na co dzień. Problem daje o sobie znać dopiero, gdy strona zaczyna się rozrastać — menu ma coraz więcej pozycji, motyw coraz więcej ustawień, a wtyczki coraz więcej pól konfiguracyjnych. Jeśli WordPress nie zapisuje wszystkich zmian, a kłopot dotyczy dużego menu, buildera lub rozbudowanego formularza ustawień, warto sprawdzić ten limit. Jego podniesienie może rozwiązać problem, ale nie powinno zastępować porządku w strukturze strony.

Dobrze utrzymany WordPress to nie tylko regularne aktualizacje i kopie zapasowe, lecz również rozsądna liczba wtyczek, przejrzyste menu, uporządkowane ustawienia i hosting, który pozwala dopasować parametry PHP do potrzeb strony.

Osobom, które chcą wygodniej zarządzać stroną i jej konfiguracją, cyberFolks poleca sprawdzenie własnej oferty hostingu WordPress. Dobrze dobrane środowisko ułatwia dostosowanie parametrów PHP, przyspiesza diagnozowanie problemów i pozwala bezpieczniej rozwijać witrynę.

max_input_vars to parametr PHP określający, ile zmiennych wejściowych może zostać przyjętych w jednym żądaniu. W praktyce decyduje o tym, ile pól formularza zostanie przetworzonych podczas jednego zapisu.

Tak, duże menu może zawierać bardzo wiele pól, zwłaszcza gdy motyw lub wtyczki dodają dodatkowe opcje do każdej pozycji. Po przekroczeniu limitu część danych może nie zostać zapisana.

W niektórych przypadkach formularz zostaje wysłany, ale nie wszystkie dane są przetwarzane. Użytkownik widzi wówczas zwykły powrót do panelu, a dopiero po odświeżeniu zauważa, że część zmian zniknęła.

Podniesienie limitu bywa potrzebne przy rozbudowanych stronach, ale powinno być przeprowadzone świadomie. Najpierw warto się upewnić, że problem rzeczywiście dotyczy dużej liczby pól, a nie cache, konfliktu wtyczek, błędu JavaScript czy blokady bezpieczeństwa.

Nie istnieje jedna uniwersalna wartość odpowiednia dla każdej strony. Prosty WordPress może działać poprawnie przy niższym limicie, a rozbudowana witryna z megamenu, builderem i licznymi ustawieniami może wymagać wyższej wartości. Limit warto dopasować do konkretnego przypadku, zamiast zwiększać go bez końca.