Du har konfigurerat ditt tema, lagt till ett dussin plugins, ställt in anpassade fält, och sedan slutar WordPress att spara menyinställningar. Du klickar på "Spara", men vissa menyalternativ försvinner helt enkelt.

Det här är inte en bugg i adminpanelen eller ett pluginproblem. PHP på servern har nått gränsen för indatavariabler max_input_vars och trunkerar tyst data som kommer från formuläret. Som standard är gränsen 1000, vilket är klart otillräckligt för en modern WordPress-installation med ett par tunga plugins.

Här är tre sätt att höja gränsen: från en snabb.htaccess-redigering till inställningar i webbhotellets kontrollpanel. Alla metoder har testats på Apache och PHP-FPM och fungerar från PHP 7.4 till 8.4.

Vad är max_input_vars och hur visar sig felet

max_input_vars är ett PHP-direktiv som begränsar antalet variabler som accepteras från GET-, POST- och COOKIE-förfrågningar. Begränsningen gäller varje superglobal array separat: POST-variabler räknas oberoende av GET och COOKIE.

För en liten visitkortssajt är tusen variabler mer än nog. Men WordPress adminpanel genererar dussintals fält för varje entitet: menyalternativ, widgetar, anpassningsalternativ, plugin-metaboxar. När ett menyformulär innehåller 80 poster, som var och en skickar 12-15 variabler, överskrids gränsen osynligt och en del av datan försvinner vid sparandet.

Symtom som tyder på just detta problem:

• Menyalternativ sparas inte eller sparas bara delvis.
• Widgetar återställs spontant till inaktiva.
• Ett plugin (som ett SEO-plugin eller en sidbyggare) tappar vissa inställningar efter sparande.
• I Webbhälsa (Verktyg → Webbhälsa → Info → Server) är värdet PHP max input variables 1000 eller lägre.

Standardrekommendationen från WordPress-communityn är att höja gränsen till 3000. Detta räcker för de flesta installationer. Sajter med särskilt tunga adminpaneler (flernivåmenyer med 100+ poster, Mega Menu, dussintals ACF-fält) kan utan problem sätta 5000 eller till och med 10000, eftersom detta praktiskt taget inte påverkar serverns prestanda.

💡 Snabb översikt:

• Kontrollera aktuell gräns: phpinfo() eller Webbhälsa i WordPress admin.
• Metod 1: lägg till php_value max_input_vars 3000 i din.htaccess-fil, fungerar med Apache som använder mod_php.
• Metod 2: lägg till max_input_vars = 3000 i php.ini eller.user.ini, lämpligt för PHP-FPM.
• Metod 3: ändra värdet via webbhotellets kontrollpanel, ett alternativ för de utan direkt åtkomst till serverfiler.

Metod 1: redigera.htaccess

Denna metod fungerar när PHP körs som en Apache-modul (mod_php). Du kan avgöra detta i Verktyg → Webbhälsa → Info → Server: raden Server architecture innehåller Apache, och PHP-hanteraren är listad som en modul, inte FPM/FastCGI.

Innan du redigerar, gör en säkerhetskopia av.htaccess: ladda ner filen via FTP eller ditt webbhotells filhanterare till din dator. Redigeringar i denna fil är syntaxkänsliga; ett extra mellanslag eller radbrytning kan få sajten att gå ner med ett 500-fel.

Öppna.htaccess (finns i sajtroten, bredvid wp-config.php) och lägg till raden:

1
php_value max_input_vars 3000

Om servern har Suhosin-tillägget installerat (sällsynt 2026 men finns fortfarande på äldre delade webbhotell), räcker inte en rad. Lägg till tre direktiv:

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 fångar upp variabler före PHP och trunkerar dem oberoende av max_input_vars, därav den extra uppsättningen rader.

Efter att ha sparat.htaccess, öppna WordPress admin → Verktyg → Webbhälsa → Info → Server och kontrollera att PHP max input variables visar det nya värdet. Om det inte har ändrats, läs avsnittet "Vad du ska göra om gränsen fortfarande inte ändras" nedan.

Metod 2: redigera php.ini eller.user.ini

På moderna servrar körs PHP oftast via PHP-FPM, och php_value-direktiv i.htaccess ignoreras. Det fungerande verktyget här är php.ini eller.user.ini.

.user.ini bearbetas av PHP-FPM per katalog: filen placeras i sajtroten och gäller rekursivt för alla underkataloger. Till skillnad från .htaccess, som Apache läser vid varje förfrågan, är detta PHP:s standardmekanism, som stöds sedan version 5.3.

Skapa (eller redigera en befintlig) .user.ini-fil i sajtroten och lägg till:

1
max_input_vars = 3000

Om du har tillgång till den globala php.ini (VPS/dedikerad server), ändra värdet där också. Den exakta sökvägen till php.ini kan hittas via phpinfo(): leta efter raden Loaded Configuration File. Efter redigering av php.ini krävs en omstart av PHP-FPM:

1
sudo systemctl restart php8.2-fpm

Ersätt versionsnumret i kommandot med ditt eget (8.1, 8.2, 8.3, 8.4). Kontrollera det nya värdet via Webbhälsa; det bör uppdateras omedelbart.

Om filen .user.ini inte finns, skapa den helt enkelt i en textredigerare. Namnet börjar med en punkt, så du kan behöva aktivera visning av dolda filer i ditt webbhotells filhanterare.

Metod 3: ändra gränsen via webbhotellets kontrollpanel

För delade webbhotell (cPanel, ISPmanager, DirectAdmin) är den enklaste metoden att ändra värdet via det grafiska gränssnittet utan att röra filer manuellt.

cPanel: gå till Select PHP Version → växla till fliken Options. Hitta raden max_input_vars, ändra värdet från 1000 till 3000 och klicka på Save. Ändringen tillämpas omedelbart; ingen omstart krävs.

ISPmanager: PHP-sektionen → inställningar → ytterligare parametrar → max_input_vars.

DirectAdmin: PHP Settings → hitta direktivet i listan → ändra → spara.

Om panelen inte har ett fält för max_input_vars använder webbhotellet en hårdkodad php.ini utan redigeringsrättigheter. I detta fall hjälper bara att kontakta supporten: skicka in en ticket och begär att höja max_input_vars till 3000 (eller det specifika värde du behöver). De flesta webbhotell ändrar gränsen vid första förfrågan; detta är en rutinoperation.

Vad du ska göra om gränsen fortfarande inte ändras

Situation: rader i.htaccess och.user.ini finns på plats, webbhotellets panel visar det nya värdet, men Webbhälsa visar envist 1000. Orsaker och deras lösningar:

Fel metod för ändringen. max_input_vars tillhör läget PHP_INI_PERDIR: direktivet kan bara ändras i php.ini,.htaccess,.user.ini eller httpd.conf. Funktionen ini_set() i wp-config.php har ingen effekt på det; koden @ini_set('max_input_vars', 3000) utför operationen, men PHP ignorerar den tyst. Slösa inte tid på denna metod.

PHP-konfigurationscache. Vissa paneler (särskilt cPanel med PHP-FPM) cachar ini-filer. Efter redigering av.user.ini, vänta 5 minuter; så länge behåller PHP-FPM som standard konfigurationscachen för en specifik katalog. Du kan påskynda processen genom att starta om PHP-FPM från webbhotellets panel.

Två php.ini-filer. På delade webbhotell finns det ofta en global php.ini i en mapp och en lokal i en annan. PHP plockar upp den första som hittas vid start. Kontrollera sökvägen till Loaded Configuration File via phpinfo() och redigera just den filen. Den ytterligare Scan this directory for additional .ini files kan också innehålla gränsen; kontrollera denna mapp också.

Hård webbhotellsgräns. Vissa leverantörer blockerar ändringar av max_input_vars på containernivå (CloudLinux med PHP Selector-begränsningar). I phpinfo() är direktivet markerat som no value eller visas inte alls. Detta innebär att webbhotellet har satt ett tak ovanför användarredigeringar; endast en supportticket eller uppgradering av abonnemang hjälper.

⁉️🤔 Vanliga frågor

Exakt hur mycket ska jag sätta: 3000 eller mer?

För de allra flesta WordPress-sajter räcker 3000. Detta värde täcker menyer upp till 120 poster, adminpaneler med ett dussin aktiva plugins och anpassningssidor med tio sektioner. Sätt 5000 om du använder Mega Menu med 150+ poster, en sidbyggare som Elementor med hundratals fält per sida, eller ACF med flexibla layouter. Över 10000, endast om pluginutvecklaren uttryckligen anger det i dokumentationen.

Varför återställdes gränsen till 1000 efter en PHP-uppdatering?

Uppdatering av PHP-versionen via webbhotellets panel drar ofta in standard-php.ini. Kontrollera.user.ini och panelen; troligtvis finns filen fortfarande där, men webbhotellet växlade poolen till en ny konfiguration utan dina redigeringar.

Kan jag sätta gränsen via wp-config.php?

Nej. Direktivet max_input_vars har läget PHP_INI_PERDIR och kan inte ändras via ini_set(); PHP kommer tyst att ignorera ett sådant anrop. Endast.htaccess (på Apache med mod_php),.user.ini / php.ini och webbhotellets panel fungerar.

Hur kan jag avgöra om problemet specifikt är max_input_vars och inte något annat?

Den mest exakta indikatorn är PHP-loggar. Aktivera WP_DEBUG i wp-config.php: define('WP_DEBUG', true);. Efter en misslyckad formulärsparning, kontrollera /wp-content/debug.log: om det finns en post Warning: Input variables exceeded 1000 är diagnosen bekräftad.

Vad ska jag göra om mitt webbhotell inte låter mig ändra gränsen?

Kontakta supporten med ett specifikt nummer (till exempel "höj max_input_vars till 3000"). Detta är en standardförfrågan; supporten utför den kostnadsfritt hos de flesta leverantörer. De nekar i två fall: ett extremt billigt abonnemang med strikt fasta gränser (då hjälper bara en uppgradering) eller en sajt på ett delat webbhotell med hundratals grannar där individuella gränser inte stöds arkitektoniskt.

Sammanfattning: vilken metod du ska välja för din situation

Åtgärdsordning, från enklast till mest komplex.

Om du har ett delat webbhotell med cPanel, börja med metod 3 (panelen). Det tar tre klick, och i de flesta fall är problemet löst. Om värdet inte ändras i Webbhälsa, prova metod 2 via.user.ini: filen placeras i sajtroten och plockas upp av PHP-FPM automatiskt.

Om du har en VPS eller dedikerad server med Apache och mod_php ger metod 1 (.htaccess) omedelbara resultat och kräver inte omstart av tjänster. För en Apache + PHP-FPM-installation, använd metod 2 (php.ini eller.user.ini).

Om panelen inte tillåter redigering, supporten inte svarar och gränsen är fastlåst på 1000, kan du ha vuxit ur ditt nuvarande abonnemang. WordPress-installationer blir tyngre för varje år: fler fält, mer data, högre krav på servermiljön. Att byta webbhotell till ett mer flexibelt abonnemang löser problemet radikalt och förbättrar också sajtens övergripande prestanda.

Börja med att kontrollera Webbhälsa just nu: Verktyg → Webbhälsa → Info → Server → PHP max input variables. Om den visar 1000 eller lägre, kommer någon av de tre lösningarna ovan att återställa din kontroll över adminpanelen på 5 minuter.