Videre til indhold 
Mange fejl i WordPress har en tavs årsag: indstillingen php max input vars wordpress. Jeg viser dig, hvordan denne grænseværdi afskærer indstillinger, gemmer formularer ufuldstændigt og sænker ydeevnen - og hvordan du indstiller værdien korrekt.
Centrale punkter
For at hjælpe dig i gang vil jeg kort opsummere de vigtigste aspekter, så du hurtigt kan se, hvor du skal starte.
- GrænseværdiMax Input Vars definerer, hvor mange variabler PHP accepterer pr. anmodning.
- SymptomerManglende temaindstillinger, afkortede formularer, plugin-fejl.
- HostingMasterværdier og sikkerhedsmoduler kan overstyre lokale indstillinger.
- Optimeringphp.ini, .htaccess eller .user.ini omhyggeligt.
- Standardværdier3000 som minimum, 5000-10000 for store opsætninger (kilde [1], [4]).
Hvad er PHP Max Input Vars - og hvorfor påvirker det WordPress?
Parameteren max_input_vars begrænser antallet af POST- og GET-variabler, som PHP behandler i en enkelt anmodning, og fungerer dermed som beskyttelse mod overdimensionerede formularer og konfigurationsoversvømmelser. I en typisk WordPress-installation bliver indstillinger fra temapaneler, customisers, widgets, menuer, plugin-indstillinger og formularfelter hurtigt til mange hundrede poster, hvilket fører til afkortede data, hvis grænsen er for lille. Især sidebyggere, e-handelsplugins og formularer på flere niveauer øger antallet, og derfor sætter jeg en startværdi på 3000 og overvejer 5000 til 10000 for omfattende opsætninger (kilde [1], [4]). Hvis du også vil bruge andre PHP-grænser For streng forværrer situationen, fordi flere justeringsskruer så fungerer som bremser på samme tid. En bevidst tilgang er vigtig: En for lav værdi resulterer i lydløst datatab, mens en fornuftigt øget værdi skaber Stabilitet.
Typiske fejlmønstre i WordPress, når grænsen er for lav
Et første advarselssignal er ufuldstændig opbevaring af Indstillinger for temaetJeg klikker på Gem, men kun nogle af indstillingerne bevares, mens andre ser ud til at “springe tilbage”. Lige så kritiske er store formularer, hvor enkelte felter forsvinder sporløst, fordi PHP kasserer overskydende variabler, så ordrer, registreringer eller supportanmodninger kommer ufuldstændigt frem. I menuer med mange indgange forsvinder ændringer eller sortering, hvilket operatørerne ofte fejlagtigt tilskriver plugins. Page builders mister modul- eller widgetindstillinger, selv om editoren fungerer korrekt, hvilket gør det svært at analysere årsagen. Når jeg ser sådanne symptomer samlet, tjekker jeg straks værdien af max_input_vars, før jeg justerer plugins eller temaer længere.
Hosting-grænser, master-værdier og sikkerhedsmoduler
Selv hvis jeg øger værdierne lokalt, vil en server-dækkende Master-værdi fra udbyderen kan tilsidesætte alle ændringer, hvilket er særligt almindeligt på delt hosting. Typisk scenarie: Jeg indstiller 5000 i min php.ini, men serveren accepterer kun 1000, fordi der gælder en global grænse, som ignorerer lokale justeringer. Yderligere sikkerhedsmoduler som Suhosin indfører deres egne inputgrænser, som jeg så er nødt til at hæve separat, ellers fortsætter de med at blokere overskydende felter på trods af de korrekte max_input_vars. Derfor starter jeg i stædige tilfælde med en forespørgsel til hosteren og får bekræftet den effektive master-værdi og navngivet mulige moduler. Først når denne kæde er korrekt konfigureret, træder lokale ændringer virkelig i kraft kontinuerlig.
Diagnose: Sådan finder du hurtigt flaskehalsen
I tilfælde af mistanke åbner jeg først Status for hjemmesiden-siden i WordPress-admin og tjekke den faktiske aktive værdi af max_input_vars, gerne suppleret med phpinfo() i en testfil. Hvis mine ændringer afviger fra den viste værdi, er det enten en master-værdi, der blokerer, eller også har jeg ændret den forkerte instans (f.eks. forkert PHP-handler eller forkert mappe). Som en test gemmer jeg en menu med mange indgange eller en lang formular og observerer, om der mangler indgange, hvilket bekræfter flaskehalsen. Samtidig sørger jeg for at rydde objekt- eller sidecachen og OPCache, ellers vil gamle konfigurationer forblive synlige. Det giver også mening at kigge på PHP-hukommelsesgrænse, da store formularer og byggegrænseflader er hukommelseskrævende og en snæver grænse i interaktionen med yderligere Effekter kan udløse.
Konfiguration i praksis: fire pålidelige måder
Jeg har en pragmatisk tilgang til tilpasning: Først spørger jeg hosten og får aktiveret forøgelsen på serversiden, fordi det er det mindst fejlbehæftede og tager direkte hensyn til master-værdier. Med root- eller managed-adgang redigerer jeg php.ini, sætter en klar værdi (ca. 5000) og genstarter PHP-tjenesten, så ændringen bliver aktiv. På Apache-systemer kan jeg arbejde i .htaccess, forudsat at mod_php kører, og hvis Suhosin er aktiv, kan jeg hæve dens grænser. Uden adgang til den centrale php.ini bruger jeg en .user.ini i webroot, som fungerer pålideligt i mange administrerede miljøer. Derefter bekræfter jeg ændringen i WordPress og med phpinfo(); først når begge dele er korrekte, tester jeg at gemme menuer, formularer og Valgmuligheder.
; php.ini
max_input_vars = 5000
# .htaccess (kun med mod_php)
.
php_value max_input_vars 5000
# Valgfrit for Suhosin:
php_value suhosin.request.max_vars 5000
php_value suhosin.post.max_vars 5000
.
; .user.ini
max_input_vars = 7000
Vælg værdier: Hvor høj er fornuftig?
Jeg starter sjældent under 3000, fordi moderne administrationsgrænseflader sender mange variabler, selv i grundlæggende drift (kilde [1]). For sider med sidebygere, mange widgets, sprogspecifikke menuer eller omfattende plugin-paneler sætter jeg 5000 som en retningslinje, der er egnet til daglig brug (kilde [4]). For store WooCommerce-butikker med variable produkter, filtre og komplekse checkout-formularer planlægger jeg 7.000 til 10.000 for at give plads til vækst. Det er vigtigt at teste trin for trin: Efter hver stigning tjekker jeg problemområderne, så jeg ikke når for højt op, men fejlene forsvinder sikkert. Målet er en værdi, der er bæredygtig i dag og efterlader reserver til i morgen uden at øge andre grænser unødigt. belastning.
Interaktioner med plugins og temaer
Jeg bemærker, at caching- eller performance-plugins har deres egne .htaccess-regler og dermed tilsidesætte tidligere indstillede værdier, hvilket er grunden til, at jeg tjekker de aktive direktiver igen, når jeg har foretaget ændringer i sådanne værktøjer. Sidebygere med indlejrede moduler øger variansen meget, især når globale og siderelaterede indstillinger kommer sammen. Menugeneratorer eller importværktøjer sender mange felter på én gang, hvilket straks fører til afkortede data, hvis grænserne er snævre. Især efter plugin-opdateringer tjekker jeg kort effekterne, fordi nye funktioner kan bringe yderligere indstillinger med sig. Alle, der klager over store navigationsstrukturer, kan finde yderligere oplysninger om dette på Menuens ydeevne, fordi menuer er ægte Variabel driver.
Performance og sikkerhed: den rette balance
En højere grænse betyder, at PHP har mere Variabler hvilket kan betyde flere data pr. anmodning, men ikke automatisk fører til belastningstoppe. Det bliver først kritisk, når formularer med tusindvis af felter behandles regelmæssigt og derfor stiller større krav til hukommelse og CPU. Jeg kombinerer derfor forøgelsen af max_input_vars med et kig på eksekveringstid, inputstørrelse og hukommelsesgrænse, så det samlede system forbliver sammenhængende. På sikkerhedssiden giver grænseværdien mening, fordi den kan begrænse fejlagtige eller bevidst overbelastede anmodninger; et sikkert niveau kan opretholdes her med udbyderbeskyttelse, WAF og hastighedsgrænser. Jeg vælger derfor en værdi, der dækker de reelle krav uden blindt at maksimere alle grænser. bred.
| Scenarie | Typiske variabler | max_input_vars | Hint |
|---|---|---|---|
| Lille hjemmeside (blog, portfolio) | 200-800 | 3000 | Tilstrækkelig reserve til temaopdateringer (kilde [1]) |
| Flersproget hjemmeside med Builder | 800-2500 | 5000 | Mange paneler og menuer (kilde [4]) |
| WooCommerce med varianter | 2000-6000 | 7000-10000 | Mulighed for checkout og produktvalg (kilde [1], [4]) |
| Virksomhedsformularer/CRM | 5000+ | 10000+ | Koordiner tæt med hoster, overvåg udnytte |
Fejlfinding: Ændringer virker ikke - hvad nu?
Hvis intet ændrer sig på trods af justeringen, tjekker jeg først den aktive PHP-håndtering (mod_php, FPM, CGI), fordi den forkerte kontekst gør lokale filer ineffektive. Derefter sammenligner jeg phpinfo() med WordPress Site Health for at udelukke cacher og se effektive værdier. Hvis værdien forbliver stædigt lav, er der næsten altid en master-værdi hos udbyderen, som jeg har bekræftet skriftligt og rejst. Med FPM-opsætninger kan jeg være nødt til at konfigurere den korrekte pool eller genindlæse tjenesten, ellers forbliver den gamle værdi aktiv. Hvis Suhosin fortsætter med at blokere, øger jeg request.max_vars og post.max_vars, indtil Antal formularer går sikkert igennem.
Praktiske eksempler og retningslinjer, der virker
Til en bloginstallation med et standardtema og et par plugins bruger jeg 3000, Jeg tester menuer og temaindstillinger og lader det som regel blive ved det. Jeg starter en virksomheds hjemmeside med megamenuer, flersproget indhold og en sidebygger direkte ved 5000, hvilket i praksis giver mærkbar ro i sindet. Et større shopsystem med varianter og ekstra felter starter ved 7000 og stiger til 10000, hvis det er nødvendigt, så produktimport, kassetilpasninger og administrationspaneler fungerer korrekt. Forholdet til de faktiske formularstørrelser og paneler er vigtigere end den absolutte værdi, og det er derfor, jeg logger ændringer og overvåger belastningstoppe. Dette skaber en indstilling, der er permanent Pålidelig kører og giver mulighed for senere skalering.
Hvordan PHP-variabler virkelig tæller - og hvorfor bygherrer når deres grænser så hurtigt
Vigtigt for praksis: Hvert formularfelt svarer til mindst én variabel på $_POST eller $_GET. WordPress bruger ofte til komplekse paneler Array-syntaks med parenteser, for eksempel option[group][subgroup][field]. PHP bygger indlejrede arrays ud fra det - og hvert ark i denne struktur tæller imod max_input_vars. Repeater-felter, dynamiske lister, mega-menuer og oversættelsesvarianter får antallet til at stige særligt hurtigt. Hertil kommer Skjulte felter (f.eks. nonces, ID'er) og systemiske parametre, som operatørerne let overser. Det forklarer, hvorfor en formular med „kun“ 300 synlige poster kan generere 1000+ variabler internt.
Særligt berørte er:
- Menu-redaktører (hvert menupunkt har flere felter og metadata)
- Sidebygger med indlejrede widgets, globale og sideindstillinger
- Paneler med ekstraudstyr af temaer/plugins, der overfører hele konfigurationstræer
- Flersprogede opsætninger, hvor felter duplikeres for hvert sprog
Vigtigt: max_input_vars begrænser antallet af variabler - ikke antallet af Samlet størrelse af forespørgslen. Grænserne for størrelse er post_max_size og upload_max_filesize ansvarlig. Begge skal matche den valgte stigning, så anmodninger ikke annulleres andre steder.
Et overblik over serverarkitekturer: Apache, NGINX, FPM, Container
Om og hvor en ændring træder i kraft, afhænger i høj grad af arkitekturen. En kort oversigt, der forkorter en masse fejlfinding:
- Apache med mod_php:
.htaccesskanphp_valueindstillet. Træder i kraft med det samme, men kun i denne sammenhæng. - Apache + PHP-FPM (proxy_fcgi):
.htaccessignoreretphp_value. Ændringer foretages iphp.ini,.user.inieller i FPM-pulje. - NGINX + PHP-FPM: Ingen
.htaccess-filer. Konfiguration viaphp.ini,.user.inieller FPM-pool; NGINX selv kender ikke værdien. - Container/administreretÆndres ofte via panelindstilling, miljøvariabel eller montering af ini-filen. Efter opdateringer/udrulninger skal du kontrollere, om værdierne fortsætter.
I FPM-miljøer beskytter jeg mig selv ved at indtaste værdien direkte i Pool og genindlæs tjenesten:
; /etc/php/8.2/fpm/pool.d/www.conf
php_admin_value[max_input_vars] = 7000
; Derefter: systemctl reload php8.2-fpm (eller genindlæs tjenesten på passende vis)
For .user.ini Følgende gælder: Ændringer er ikke altid aktive med det samme. Afhængigt af user_ini.cache_ttl Det tager minutter, før de nye værdier er synlige. Jeg planlægger derfor en ventetid eller en FPM-genindlæsning. Fejlsignal: WordPress fortsætter med at rapportere den gamle værdi, selvom filen er korrekt placeret - så træder cache TTL i kraft, eller en masterværdi er blokeret.
Vigtigt: Indstil php_value kun i .htaccess, når mod_php er aktiv. I FPM-opsætninger udløser dette normalt 500-fejl, fordi webserveren ikke forstår direktivet.
Måling i stedet for gætværk: Tæl variabler live og simulér flaskehalse
Før jeg øger værdien „på mistanke“, måler jeg den reelle efterspørgsel. En kort diagnostisk hjælper som midlertidig kode i et must-use plug-in eller funktioner.php skriver antallet til loggen:
<?php
// Advarsel: Brug kun midlertidigt og fjern bagefter.
add_action('admin_init', funktion () {
if (!empty($_POST)) {
// Rekursiv optælling af alle arkværdier
$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'));
}
});
På den måde kan jeg med det samme se, om en lagringsproces har nået sin grænse. Jeg tester også med en „stressformular“ (f.eks. genererede dummyfelter) for at kontrollere, at der ikke forsvinder flere felter efter en forøgelse. Vigtigt: Tøm cacher, så backend ikke stadig viser gamle tilstande.
Særlige tilfælde: Multisite, REST API, Ajax og uploads
På MultisiteNetværksindstillinger, rollebaserede indstillinger og sprogspecifikke indtastninger løber især hurtigt op i undernetværk. Jeg planlægger med højere værdier fra starten og tjekker for hvert undernetværk, fordi panelerne kan være meget forskellige.
Ikke alle WordPress-funktioner er lige påvirkede: REST API-opkald sender ofte JSON i request body'en, hvilket ikke genkendes som $_POST er analyseret; max_input_vars gælder typisk ikke der. I modsætning hertil er klassisk admin-ajax.php-forespørgsler (POST-formularer) er klart bundet til grænsen. Så hvis du bruger bygherrer, der gemmer via Ajax, skal du stadig holde øje med grænsen.
Defineret til filuploads max_fil_uploads det maksimale antal samtidige filer, mens upload_max_filesize og post_max_size indstiller størrelsesgrænserne. Hvis uploads overskrider disse værdier, opstår der fejl uanset max_input_vars. I restriktive miljøer kan webserver- eller WAF-grænser (f.eks. request body limits) også gribe ind - en typisk årsag til, at anmodninger „pludselig“ annulleres på trods af korrekt indstillede PHP-værdier.
Fejlforebyggelse på kodeniveau: når inkrementering alene ikke er nok
Fra en udviklers synspunkt er det ofte fornuftigt at opdele store konfigurationer i Underafsnit eller at gemme dem trin for trin. De følgende mønstre reducerer mængden af variabler:
- Paginering/trin: Opdel lange formularer i trin, og gem hvert trin på serversiden.
- ChunkingOpdel store option-arrays i blokke, og overfør dem en efter en via Ajax.
- Differentiel opbevaringSend kun ændrede felter i stedet for hele indstillingstræet.
- Seriel opbevaringBrug en struktureret mulighed med serialisering i stedet for mange individuelle felter (begrænser antallet af variabler, når du sender).
Disse mønstre minimerer afhængigheden af max_input_vars og gøre administrative processer mere robuste, især i miljøer med strenge udbydergrænser.
Bedste praksis og tjekliste til løbende drift
- Mål, før du hæverLog antallet af variabler for kritiske handlinger (gem menu, gem bygherreside).
- Forøgelse af stadierØg i fornuftige trin (3000 → 5000 → 7000), og test efter hvert trin.
- Tjek arkitekturenBekræft håndteringen (mod_php/FPM/CGI) og brug den rette sti (php.ini, .user.ini, FPM-pool).
- Bekræft master-værdi: Spørg udbyderen om den globale grænseværdi, og få den dokumenteret.
- Synkroniser sikkerhedsmoduler: Hæv Suhosin og sammenlignelige grænser parallelt.
- Versionering af konfigurationenInkluder ini/pool-filer i udrulningsprocesser, så opdateringer ikke nulstiller værdier.
- Tomme cacherInvalider objektcache, sidecache og OPCache efter ændringer.
- Et overblik over størrelsesgrænser: post_max_size, upload_max_filesize, max_fil_uploads, max_udførelsestid og memory_limit Indstil passende.
- Etablering af overvågningTjek logfiler for tilbagevendende „afkortede“ gemmeprocesser og administratorfejl.
Praktiske testscenarier, der hurtigt afslører skjulte problemer
I audits kører jeg tre korte tests: 1) Gem en omfattende menu med sortering; 2) Dupliker en builder-side med mange widgets/repeaters og gem igen; 3) Indsend en lang formular med valgfrie/skjulte felter. Hvis et af trinnene inkonsekvent butikker, er max_input_vars en varm kandidat. Først når alle tre scenarier fungerer pålideligt, betragtes mine tilpasninger som modstandsdygtige - selv med vækst.
Kort opsummeret
Indstillingen max_input_vars fungerer som en gatekeeper for alle indgående felter og afgør ofte, om WordPress gemmer rent eller i al hemmelighed sluger data. Med 3000 som en nedre grænse og 5000-10000 for datarige opsætninger (kilde [1], [4]) skaber jeg det nødvendige spillerum og eliminerer forvirrende fejlmønstre. Jeg kontrollerer hvert trin med WordPress Site Health og phpinfo() for tydeligt at kunne genkende master-værdier, cacher og sikkerhedsmoduler. Kun når udbydergrænser, lokale filer og aktive PHP-instanser stemmer overens, fungerer justeringerne pålideligt. At være opmærksom på denne kæde forhindrer nedetid, reducerer supportomkostninger og holder Ydelse af webstedet er konstant høj.
