...
logotyp för webbhotell

WordPress och PHP Max Input Vars - Tyst orsak till fel och prestanda

Många fel i WordPress har en dold orsak: inställningen php max inmatning vars wordpress. Jag ska visa dig hur detta gränsvärde skär av inställningar, sparar formulär ofullständigt och saktar ner prestanda - och hur du ställer in värdet korrekt.

Centrala punkter

För att hjälpa dig att komma igång ska jag kort sammanfatta de viktigaste aspekterna så att du snabbt kan se var du ska börja.

  • GränsvärdeMax Input Vars definierar hur många variabler PHP accepterar per begäran.
  • SymptomSaknade temaalternativ, avkortade formulär, plugin-fel.
  • HostingMastervärden och säkerhetsmoduler kan åsidosätta lokala inställningar.
  • Optimeringphp.ini, .htaccess eller .user.ini noggrant.
  • Standardvärden3000 som ett minimum, 5000-10000 för stora uppsättningar (källa [1], [4]).

Vad är PHP Max Input Vars - och varför påverkar det WordPress?

Parametern max_input_vars begränsar antalet POST- och GET-variabler som PHP bearbetar i en enda begäran och fungerar därmed som ett skydd mot överdimensionerade formulär och konfigurationsflöden. I en typisk WordPress-installation kan alternativ från temapaneler, anpassare, widgetar, menyer, plugin-inställningar och formulärfält snabbt uppgå till många hundra poster, vilket leder till avkortade data om gränsen är för liten. Särskilt sidbyggare, e-handelsplugins och formulär på flera nivåer driver upp antalet, vilket är anledningen till att jag sätter ett startvärde på 3000 och överväger 5000 till 10000 för omfattande konfigurationer (källa [1], [4]). Om du även vill använda andra PHP-gränser för strikt förvärrar situationen, eftersom flera justerskruvar då fungerar som bromsar samtidigt. Det är viktigt med ett medvetet förhållningssätt: ett för lågt värde leder till tyst dataförlust, medan ett förnuftigt ökat värde skapar Stabilitet.

Typiska felmönster i WordPress när gränsen är för låg

En första varningssignal är ofullständig lagring av Alternativ för tematJag klickar på Spara, men bara en del av inställningarna behålls, medan andra verkar “hoppa tillbaka”. Lika kritiska är stora formulär där enskilda fält försvinner spårlöst eftersom PHP kastar bort överflödiga variabler och sålunda beställningar, registreringar eller supportförfrågningar anländer ofullständigt. I menyer med många poster försvinner ändringar eller sortering, vilket operatörer ofta felaktigt tillskriver plugins. Sidbyggare tappar modul- eller widgetinställningar trots att editorn fungerar som den ska, vilket gör det svårt att analysera orsaken. När jag ser sådana symptom samlade kontrollerar jag genast värdet på max_input_vars, innan jag ändrar plugins eller teman längre.

Värdgränser, huvudvärden och säkerhetsmoduler

Även om jag ökar värdena lokalt kommer en serveromfattande Master-värde från leverantören kan åsidosätta varje ändring, vilket är särskilt vanligt på delad hosting. Typiskt scenario: Jag ställer in 5000 i min php.ini, men servern accepterar bara 1000 eftersom en global gräns gäller och ignorerar lokala justeringar. Ytterligare säkerhetsmoduler som Suhosin inför sina egna gränser för inmatning, som jag sedan måste höja separat, annars fortsätter de att blockera överflödiga fält trots korrekta max_input_vars. I envisa fall börjar jag därför med en förfrågan till hostern och får det effektiva mastervärdet bekräftat och möjliga moduler namngivna. Det är först när denna kedja är korrekt konfigurerad som lokala ändringar verkligen får effekt kontinuerlig.

Diagnos: Så här hittar du flaskhalsen snabbt

Vid misstanke om brott öppnar jag först Webbplatsens status-sidan i WordPress-admin och kontrollera det faktiska aktiva värdet för max_input_vars, helst kompletterat med phpinfo() i en testfil. Om mina ändringar skiljer sig från det visade värdet blockeras antingen ett mastervärde eller så har jag ändrat fel instans (t.ex. fel PHP-hanterare eller fel katalog). Som ett test sparar jag en meny med många poster eller ett långt formulär och observerar om poster saknas, vilket bekräftar flaskhalsen. Samtidigt ser jag till att rensa objekt- eller sidcachen och OPCache, annars kommer gamla konfigurationer att förbli synliga. Det är också vettigt att ta en titt på PHP-minnesgräns, som stora formulär och byggargränssnitt är minnesintensiva och en snäv gräns i interaktionen mellan ytterligare Effekter kan utlösa.

Konfiguration i praktiken: fyra tillförlitliga sätt

Jag tar ett pragmatiskt tillvägagångssätt för anpassning: Först frågar jag hostern och får ökningen aktiverad på serversidan, eftersom detta är det minst felbenägna och tar hänsyn till mastervärden direkt. Med root- eller managed-åtkomst redigerar jag php.ini, sätter ett tydligt värde (ca 5000) och startar om PHP-tjänsten så att ändringen blir aktiv. På Apache-system kan jag arbeta i .htaccess, förutsatt att mod_php körs, och om Suhosin är aktivt kan jag höja dess gränser. Utan tillgång till den centrala php.ini använder jag en .user.ini i webroot, vilket fungerar tillförlitligt i många hanterade miljöer. Jag verifierar sedan ändringen i WordPress och med phpinfo(); först när båda är korrekta testar jag att spara menyer, formulär och Alternativ.

; php.ini
max_input_vars = 5000

# .htaccess (endast med mod_php)

  php_värde max_input_vars 5000
  # Valfritt för Suhosin:
  php_value suhosin.request.max_vars 5000
  php_värde suhosin.post.max_vars 5000

; .användare.ini
max_input_vars = 7000

Välj värden: Hur högt är förnuftigt?

Jag börjar sällan under 3000, eftersom moderna administratörsgränssnitt skickar många variabler även i grundläggande drift (källa [1]). För webbplatser med sidbyggare, många widgetar, språkspecifika menyer eller omfattande pluginpaneler sätter jag 5000 som en riktlinje som är lämplig för daglig användning (källa [4]). För stora WooCommerce-butiker med variabla produkter, filter och komplexa kassaformulär planerar jag för 7 000 till 10 000 för att lämna utrymme för tillväxt. Det är viktigt att testa steg för steg: efter varje ökning kontrollerar jag problemområdena så att jag inte går för högt, men felen försvinner säkert. Målet är ett värde som är hållbart idag och som lämnar reserver för morgondagen utan att i onödan höja andra gränser. stam.

Interaktioner med plugins och teman

Jag noterar att caching- eller prestandaplugins har sina egna .htaccess-regler och därmed åsidosätta tidigare inställda värden, vilket är anledningen till att jag kontrollerar de aktiva direktiven igen efter att ha gjort ändringar i sådana verktyg. Sidbyggare med kapslade moduler ökar variansen kraftigt, särskilt när globala och sidorelaterade alternativ kombineras. Menygeneratorer eller importverktyg skickar många fält på en gång, vilket omedelbart leder till trunkerade data om gränserna är snäva. Särskilt efter plugin-uppdateringar kontrollerar jag kortfattat effekterna eftersom nya funktioner kan medföra ytterligare inställningar med dem. Den som klagar över stora navigationsstrukturer kan hitta mer information om detta på Menyprestanda, eftersom menyer är verkliga Variabel förare.

Prestanda och säkerhet: rätt balans

En högre gräns innebär att PHP har mer Variabler vilket kan innebära mer data per förfrågan, men inte automatiskt leder till belastningstoppar. Det blir kritiskt först när formulär med tusentals fält bearbetas regelbundet och därför ställer större krav på minne och CPU. Jag kombinerar därför ökningen av max_input_vars med en titt på exekveringstid, inmatningsstorlek och minnesgräns så att det övergripande systemet förblir sammanhängande. På säkerhetssidan är gränsvärdet meningsfullt eftersom det kan begränsa felaktiga eller avsiktligt överbelastade förfrågningar; en säker nivå kan upprätthållas här med leverantörsskydd, WAF och hastighetsgränser. Jag väljer därför ett värde som täcker verkliga krav utan att blint maximera varje gräns. bred.

Scenario Typiska variabler max_input_vars Ledtråd
Liten webbplats (blogg, portfolio) 200-800 3000 Tillräcklig reserv för uppdateringar av teman (källa [1])
Flerspråkig webbplats med Builder 800-2500 5000 Många paneler och menyer (källa [4])
WooCommerce med varianter 2000-6000 7000-10000 Utrymme för utcheckning och produktalternativ (källa [1], [4])
Företagsformulär/CRM 5000+ 10000+ Samordna nära med värdföretaget, övervaka utnyttja

Felsökning: Ändringarna fungerar inte - vad gör vi nu?

Om inget förändras trots justeringen kontrollerar jag först den aktiva PHP-hanterare (mod_php, FPM, CGI), eftersom fel sammanhang gör lokala filer ineffektiva. Jag jämför sedan phpinfo() med WordPress Site Health för att utesluta cacher och se effektiva värden. Om värdet förblir envist lågt finns det nästan alltid ett mastervärde hos leverantören, vilket jag har bekräftat skriftligen och tagit upp. Med FPM-installationer kan jag behöva konfigurera rätt pool eller ladda om tjänsten, annars förblir det gamla värdet aktivt. Om Suhosin fortsätter att blockera ökar jag dess request.max_vars och post.max_vars tills Antal formulär går igenom säkert.

Praktiska exempel och riktlinjer som fungerar

För en blogginstallation med ett standardtema och ett fåtal plugins använder jag 3000, Jag testar menyer och temaalternativ och lämnar det vanligtvis vid det. En företagswebbplats med megamenyer, flerspråkigt innehåll och en sidbyggare startar jag direkt på 5000, vilket i praktiken ger en märkbar sinnesro. Ett större butikssystem med varianter och ytterligare fält börjar på 7000 och ökar till 10000 om det behövs för att produktimport, kassaanpassningar och adminpaneler ska fungera korrekt. Förhållandet till faktiska formulärstorlekar och paneler är viktigare än det absoluta värdet, och det är därför jag loggar ändringar och övervakar belastningstoppar. Detta skapar en inställning som är permanent Pålitlig körs och tillåter senare skalning.

Hur PHP-variabler verkligen räknas - och varför byggare når sina gränser så snabbt

Viktigt för praktiken: Varje formulärfält motsvarar minst en variabel på $_POST eller . $_GET. WordPress används ofta för komplexa paneler Array-syntax med parenteser, till exempel alternativ[grupp][undergrupp][fält]. PHP bygger nästlade matriser från den - och varje ark i denna struktur räknas mot max_input_vars. Repeaterfält, dynamiska listor, megamenyer och översättningsvarianter gör att antalet ökar särskilt snabbt. Till detta kommer Dolda fält (t.ex. nonces, ID) och systemiska parametrar som operatörer lätt förbiser. Detta förklarar varför ett formulär med „bara“ 300 synliga poster kan generera 1000+ variabler internt.

Särskilt drabbade är:

  • Redaktörer för menyer (varje menyalternativ har flera fält och metadata)
  • Sidbyggare med nästlade widgets, globala alternativ och sidalternativ
  • Tillvalspaneler av teman/plugins som överför hela konfigurationsträd
  • Flerspråkiga konfigurationer, där fälten är duplicerade för varje språk

Viktigt: max_input_vars begränsar antalet variabler - inte antalet Total storlek av förfrågan. För storleksgränser gäller post_max_storlek och upload_max_filesize ansvarig. Båda bör matcha det valda tillägget så att förfrågningar inte annulleras någon annanstans.

Serverarkitekturer i en överblick: Apache, NGINX, FPM, Container

Om och var en ändring träder i kraft beror i hög grad på arkitekturen. En kort översikt som förkortar en hel del felsökning:

  • Apache med mod_php: .htaccess kan php_value inställd. Träder i kraft omedelbart, men endast i detta sammanhang.
  • Apache + PHP-FPM (proxy_fcgi): .htaccess ignorerad php_value. Ändringar görs i php.ini, .användare.ini eller i FPM pool.
  • NGINX + PHP-FPM: Ingen .htaccess-filer. Konfiguration via php.ini, .användare.ini eller FPM-pool; NGINX själv känner inte till värdet.
  • Container/HanteradÄndras ofta via panelalternativ, miljövariabel eller montering av ini-filen. Efter uppdateringar/avinstallationer, kontrollera om värdena kvarstår.

I FPM-miljöer skyddar jag mig själv genom att ange värdet direkt i pool och ladda om tjänsten:

; /etc/php/8.2/fpm/pool.d/www.conf
php_admin_value[max_input_vars] = 7000
; Sedan: systemctl reload php8.2-fpm (eller ladda om tjänsten på lämpligt sätt)

För .användare.ini Följande gäller: Ändringar är inte alltid aktiva omedelbart. Beroende på användare_ini.cache_ttl det tar minuter innan nya värden syns. Jag planerar därför en väntetid eller en FPM-omladdning. Felsignal: WordPress fortsätter att rapportera det gamla värdet trots att filen är korrekt placerad - då träder cache TTL i kraft eller ett mastervärde blockeras.

Viktigt: Ställ in php_value endast i .htaccess, när mod_php är aktivt. I FPM-konfigurationer utlöser detta vanligtvis 500-fel eftersom webbservern inte förstår direktivet.

Mätning i stället för gissning: Räkna variabler live och simulera flaskhalsar

Innan jag ökar värdet „på misstanke“ mäter jag den verkliga efterfrågan. En kort diagnostisk hjälpare som tillfällig kod i ett plug-in som måste användas eller funktioner.php skriver räkningen till loggen:

<?php
// Varning: Använd endast tillfälligt och ta bort efteråt.
add_action('admin_init', funktion () {
  if (!empty($_POST)) {
    // Rekursiv räkning av alla arkvärden
    $count = 0;
    $it = new RecursiveIteratorIterator(new RecursiveArrayIterator($_POST));
    foreach ($it as $v) { $count++; }
    error_log('POST vars (rekursiv): ' . $count);
    error_log('max_input_vars (ini): ' . ini_get('max_input_vars'));
  }
});

Detta gör att jag omedelbart kan se om en lagringsprocess har nått sin gräns. Jag testar också med ett „stressformulär“ (t.ex. genererade dummyfält) för att verifiera att inga fler fält försvinner efter en ökning. Viktigt: Töm cacher så att backend inte fortfarande visar gamla tillstånd.

Särskilda fall: Multisite, REST API, Ajax och uppladdningar

På Flera webbplatserNätverksinställningar, rollbaserade alternativ och språkspecifika poster blir särskilt snabbt många i undernätverk. Jag planerar med högre värden redan från början och kontrollerar per undernätverk eftersom panelerna kan skilja sig avsevärt.

Alla WordPress-funktioner påverkas inte i lika hög grad: REST API-anrop skickar ofta JSON i förfrågningskroppen, vilket inte erkänns som en $_POST är analyserad; max_input_vars gäller normalt inte där. I motsats till detta är klassiska admin-ajax.php-requests (POST-formulär) är tydligt bundna till gränsen. Så om du använder byggare som sparar via Ajax behöver du fortfarande hålla ett öga på gränsen.

Definierad för filuppladdningar max_fil_uppladdningar det maximala antalet samtidiga filer, medan upload_max_filesize och post_max_storlek anger storleksgränserna. Om uppladdningarna överskrider dessa värden uppstår fel oavsett max_input_vars. I restriktiva miljöer kan webbserver- eller WAF-gränser (t.ex. gränser för förfrågningarnas innehåll) också ingripa - en typisk orsak till att förfrågningar „plötsligt“ avbryts trots korrekt inställda PHP-värden.

Felförebyggande på kodnivå: när det inte räcker med enbart inkrementering

Ur utvecklarens synvinkel är det ofta förnuftigt att dela upp stora konfigurationer i Underavdelningar eller för att spara dem steg för steg. Följande mönster minskar antalet variabler:

  • Paginering/steg: Dela upp långa formulär i steg och spara varje steg på serversidan.
  • ChunkingDela upp stora optionsmatriser i block och överför dem en efter en via Ajax.
  • Differentiell lagringSkicka bara ändrade fält istället för hela alternativträdet.
  • Seriell lagringAnvänd ett strukturerat alternativ med serialisering i stället för många enskilda fält (begränsar antalet variabler vid sändning).

Dessa mönster minimerar beroendet av max_input_vars och göra administrationsprocesserna mer robusta, särskilt i miljöer med strikta leverantörsgränser.

Bästa praxis och checklista för löpande verksamhet

  • Mät innan du höjerLogga antalet variabler för kritiska åtgärder (spara meny, spara byggsida).
  • Ökning i antal stegHöj i rimliga steg (3000 → 5000 → 7000) och testa efter varje steg.
  • Kontrollera arkitekturenVerifiera hanteraren (mod_php/FPM/CGI) och använd lämplig sökväg (php.ini, .user.ini, FPM-pool).
  • Bekräfta mastervärde: Be vårdgivaren om det globala gränsvärdet och se till att det dokumenteras.
  • Synkronisera säkerhetsmoduler: Höj Suhosin och jämförbara gränser parallellt.
  • Versionering av konfigurationenInkludera ini-/poolfiler i distributionsprocesser så att uppdateringar inte återställer värden.
  • Tomma cacheminnenInvalidera objektcache, sidcache och OPCache efter ändringar.
  • En överblick över storleksgränserna: post_max_storlek, upload_max_filesize, max_fil_uppladdningar, max_exekveringstid och memory_limit ställa in på lämpligt sätt.
  • Etablera övervakningKontrollera loggar för återkommande „trunkerade“ sparprocesser och adminfel.

Praktiska testscenarier som snabbt avslöjar dolda problem

I revisioner kör jag tre korta tester: 1) Spara en omfattande meny med sortering; 2) Duplicera en byggarsida med många widgets/repeaters och spara igen; 3) Skicka in ett långt formulär med valfria/dolda fält. Om något av stegen inkonsekvent butiker, är max_input_vars en het kandidat. Det är först när alla tre scenarierna fungerar tillförlitligt som mina anpassningar anses vara motståndskraftiga - även när de växer.

Kortfattat sammanfattat

Inställningen max_input_vars fungerar som en grindvakt för alla inkommande fält och avgör ofta om WordPress sparar rent eller i hemlighet sväljer data. Med 3000 som en nedre gräns och 5000-10000 för datarika inställningar (källa [1], [4]) skapar jag det nödvändiga spelrummet och eliminerar förbryllande felmönster. Jag kontrollerar varje steg med WordPress Site Health och phpinfo() för att tydligt identifiera mastervärden, cacheminnen och säkerhetsmoduler. Endast när leverantörsgränser, lokala filer och aktiva PHP-instanser matchar kommer justeringar att fungera tillförlitligt. Genom att uppmärksamma denna kedja förhindrar du driftstopp, minskar supportkostnaderna och håller Prestanda av webbplatsen är ständigt hög.

Aktuella artiklar