Ga naar de inhoud 
Veel fouten in WordPress hebben een stille oorzaak: de instelling php max invoer vars wordpress. Ik laat je zien hoe deze grenswaarde instellingen afsnijdt, formulieren onvolledig opslaat en de prestaties vertraagt - en hoe je de waarde correct instelt.
Centrale punten
Om je op weg te helpen, zal ik de belangrijkste aspecten kort samenvatten, zodat je snel kunt zien waar je moet beginnen.
- GrenswaardeMax Input Vars bepaalt hoeveel variabelen PHP accepteert per aanvraag.
- SymptomenOntbrekende thema-opties, afgekorte formulieren, pluginfouten.
- HostingMasterwaarden en veiligheidsmodules kunnen lokale instellingen overschrijven.
- Optimalisatiephp.ini, .htaccess of .user.ini zorgvuldig.
- Standaardwaarden3000 als minimum, 5000-10000 voor grote opstellingen (bron [1], [4]).
Wat is PHP Max Input Vars - en waarom heeft het invloed op WordPress?
De parameter max_invoer_var beperkt het aantal POST en GET variabelen dat PHP verwerkt in een enkel verzoek en dient dus als bescherming tegen te grote formulieren en configuratie overstromingen. In een typische WordPress installatie kunnen opties van themapanelen, customisers, widgets, menu's, plugin-instellingen en formuliervelden snel oplopen tot vele honderden ingangen, wat leidt tot afgeknotte gegevens als de limiet te klein is. Vooral paginabouwers, e-commerce plugins en formulieren met meerdere niveaus drijven het aantal op, daarom stel ik een beginwaarde van 3000 in en overweeg ik 5000 tot 10000 voor uitgebreide opstellingen (bron [1], [4]). Als je ook andere PHP grenzen Te streng verergert de situatie, omdat meerdere stelschroeven dan tegelijkertijd als rem werken. Een bewuste benadering is belangrijk: een te lage waarde leidt tot stil gegevensverlies, terwijl een verstandig verhoogde waarde zorgt voor Stabiliteit.
Typische foutpatronen in WordPress wanneer de limiet te laag is
Een eerste waarschuwingssignaal is de onvolledige opslag van Thema-optiesIk klik op Opslaan, maar slechts enkele instellingen blijven behouden, terwijl andere lijken “terug te springen”. Even kritisch zijn grote formulieren waarin afzonderlijke velden spoorloos ontbreken omdat PHP overtollige variabelen weggooit en bestellingen, registraties of supportaanvragen dus onvolledig aankomen. In menu's met veel items verdwijnen wijzigingen of sorteringen, die operators vaak ten onrechte toeschrijven aan plugins. Paginabouwers verliezen module- of widgetinstellingen, ook al werkt de editor correct, wat het moeilijk maakt om de oorzaak te analyseren. Wanneer ik dergelijke symptomen gebundeld zie, controleer ik onmiddellijk de waarde van max_invoer_var, voordat ik plugins of thema's nog langer tweak.
Hosting van limieten, masterwaarden en beveiligingsmodules
Zelfs als ik de waarden lokaal verhoog, zal een server-brede Meesterwaarde van de provider kan elke wijziging ongedaan maken, wat vooral veel voorkomt bij gedeelde hosting. Typisch scenario: ik stel 5000 in in mijn php.ini, maar de server accepteert maar 1000 omdat er een globale limiet geldt en lokale aanpassingen worden genegeerd. Extra beveiligingsmodules zoals Suhosin introduceren hun eigen invoerlimieten, die ik dan apart moet verhogen, anders blijven ze overtollige velden blokkeren ondanks de correcte max_input_vars. Daarom begin ik in hardnekkige gevallen met een navraag bij de hoster en laat ik de effectieve masterwaarde bevestigen en mogelijke modules benoemen. Pas als deze keten goed is geconfigureerd, worden lokale wijzigingen echt van kracht. continu.
Diagnose: Hoe vindt u snel het knelpunt?
In geval van verdenking open ik eerst de Status website-pagina in de WordPress admin en controleer de werkelijke actieve waarde van max_input_vars, idealiter aangevuld met phpinfo() in een testbestand. Als mijn wijzigingen verschillen van de weergegeven waarde, is er een masterwaarde geblokkeerd of heb ik de verkeerde instantie gewijzigd (bijv. verkeerde PHP-handler of verkeerde map). Als test sla ik een menu op met veel items of een lang formulier en kijk of er items ontbreken, wat het knelpunt bevestigt. Tegelijkertijd zorg ik ervoor dat ik de object- of paginacache en OPCache leegmaak, anders blijven oude configuraties zichtbaar. Het is ook zinvol om te kijken naar de PHP-geheugenlimiet, zoals grote formulieren en builder interfaces zijn geheugen-intensief en een strakke limiet in de interactie van verdere Effecten kan triggeren.
Configuratie in de praktijk: vier betrouwbare manieren
Ik hanteer een pragmatische aanpak voor aanpassingen: Eerst vraag ik het de hoster en laat ik de verhoging aan de serverkant inschakelen, omdat dit het minst foutgevoelig is en direct rekening houdt met masterwaarden. Met root of beheerde toegang bewerk ik php.ini, stel een duidelijke waarde in (ongeveer 5000) en herstart de PHP-service zodat de wijziging actief wordt. Op Apache systemen kan ik in de .htaccess werken, mits mod_php draait, en als Suhosin actief is, kan ik de limieten verhogen. Zonder toegang tot de centrale php.ini, gebruik ik een .user.ini in de webroot, wat betrouwbaar werkt in veel beheerde omgevingen. Vervolgens controleer ik de wijziging in WordPress en met phpinfo(); pas als beide correct zijn, test ik het opslaan van menu's, formulieren en Opties.
; php.ini
max_invoer_gegevens = 5000
# .htaccess (alleen met mod_php)
php_waarde max_input_vars 5000
# Optioneel voor Suhosin:
php_waarde suhosin.request.max_vars 5000
php_waarde suhosin.post.max_vars 5000
; .user.ini
max_invoer_waarden = 7000
Selecteer waarden: Hoe hoog is verstandig?
Ik begin zelden onder 3000, omdat moderne admin-interfaces veel variabelen sturen, zelfs in de basiswerking (bron [1]). Voor sites met page builders, veel widgets, taalspecifieke menu's of uitgebreide pluginpanelen stel ik 5000 in als richtlijn voor dagelijks gebruik (bron [4]). Voor grote WooCommerce shops met variabele producten, filters en complexe checkout formulieren, plan ik 7.000 tot 10.000 om ruimte te laten voor groei. Het is belangrijk om stap voor stap te testen: na elke verhoging controleer ik de probleemgebieden zodat ik niet te hoog bereik, maar de fouten veilig verdwijnen. Het doel is een waarde die vandaag houdbaar is en reserves overlaat voor morgen zonder andere limieten onnodig te verhogen. stam.
Interacties met plugins en thema's
Ik merk op dat caching- of prestatieplugins hun eigen .htaccess-regels en dus eerder ingestelde waarden overschrijven, daarom controleer ik de actieve directieven opnieuw nadat ik wijzigingen heb aangebracht in dergelijke tools. Paginabouwers met geneste modules vergroten de variantie enorm, vooral wanneer globale en paginagerelateerde opties samenkomen. Menugeneratoren of importeertools verzenden veel velden in één keer, wat onmiddellijk leidt tot afgeknotte gegevens als de limieten krap zijn. Vooral na plugin-updates controleer ik even de effecten omdat nieuwe functies extra instellingen met zich mee kunnen brengen. Iedereen die klaagt over grote navigatiestructuren kan meer informatie hierover vinden op Menuprestaties, omdat menu's echt zijn Variabele bestuurder.
Prestaties en veiligheid: de juiste balans
Een hogere limiet betekent dat PHP meer Variabelen wat meer gegevens per aanvraag kan betekenen, maar niet automatisch leidt tot belastingspieken. Het wordt pas kritisch als formulieren met duizenden velden regelmatig worden verwerkt en daardoor een groter beroep doen op geheugen en CPU. Daarom combineer ik de verhoging van max_input_vars met een blik op de uitvoeringstijd, de invoergrootte en de geheugenlimiet, zodat het totale systeem coherent blijft. Aan de beveiligingskant is de limietwaarde zinvol omdat het foutieve of opzettelijk overbelaste verzoeken kan beperken; een veilig niveau kan hier worden gehandhaafd met providerbescherming, WAF en snelheidslimieten. Ik kies daarom een waarde die de echte vereisten dekt zonder elke limiet blindelings te maximaliseren. breed.
| Scenario | Typische variabelen | max_invoer_var | Tip |
|---|---|---|---|
| Kleine site (blog, portfolio) | 200-800 | 3000 | Voldoende reserve voor thema-updates (bron [1]) |
| Meertalige site met Builder | 800-2500 | 5000 | Veel panelen en menu's (bron [4]) |
| WooCommerce met varianten | 2000-6000 | 7000-10000 | Mogelijkheden voor afrekenen en productopties (bron [1], [4]) |
| Bedrijfsformulieren/CRM | 5000+ | 10000+ | Nauw coördineren met hoster, bewaken gebruik maken van |
Problemen oplossen: Wijzigingen werken niet - wat nu?
Als er ondanks de aanpassing niets verandert, controleer ik eerst de actieve PHP-behandelaar (mod_php, FPM, CGI), omdat de verkeerde context lokale bestanden ineffectief maakt. Ik vergelijk dan phpinfo() met WordPress Site Health om caches uit te sluiten en effectieve waarden te zien. Als de waarde hardnekkig laag blijft, is er bijna altijd een masterwaarde bij de provider, die ik schriftelijk heb bevestigd en heb verhoogd. Bij FPM-instellingen kan het zijn dat ik de juiste pool moet configureren of de service opnieuw moet laden, anders blijft de oude waarde actief. Als Suhosin blijft blokkeren, verhoog ik zijn request.max_vars en post.max_vars totdat de Aantal formulieren veilig doorgaat.
Praktische voorbeelden en richtlijnen die werken
Voor een bloginstallatie met een standaardthema en een paar plugins gebruik ik 3000, Ik test menu's en thema-opties en laat het daar meestal bij. Een bedrijfswebsite met megamenu's, meertalige content en een page builder begin ik direct bij 5000, wat in de praktijk merkbare gemoedsrust oplevert. Een groter shopsysteem met varianten en extra velden begint bij 7000 en loopt indien nodig op tot 10000 zodat productimport, kassa-aanpassingen en admin-panelen goed werken. De verhouding tot werkelijke formuliergroottes en panelen is belangrijker dan de absolute waarde, daarom log ik wijzigingen en monitor ik belastingspieken. Dit creëert een instelling die permanent Betrouwbaar wordt uitgevoerd en later opgeschaald kan worden.
Hoe PHP variabelen echt tellen - en waarom bouwers zo snel hun grenzen bereiken
Belangrijk voor de praktijk: Elk formulierveld correspondeert met minstens één variabele in $_POST of $_GET. WordPress gebruikt vaak voor complexe panelen Syntaxis van matrices met haakjes, zoals optie[groep][subgroep][veld]. PHP bouwt er geneste arrays van - en elk vel in deze structuur telt tegen max_invoer_var. Herhalingsvelden, dynamische lijsten, megamenu's en vertaalvarianten blazen het aantal bijzonder snel op. Hierbij komen nog Verborgen velden (bijv. nonces, ID's) en systemische parameters die operators gemakkelijk over het hoofd zien. Dit verklaart waarom een formulier met „slechts“ 300 zichtbare gegevens intern 1000+ variabelen kan genereren.
Bijzonder getroffen zijn:
- Menu-editors (elk menu-item heeft verschillende velden en metagegevens)
- Pagina bouwer met geneste widgets, globale en pagina-opties
- Optiepanelen van thema's/plugins die volledige configuratiebomen overbrengen
- Meertalige opstellingen, waar velden worden gedupliceerd voor elke taal
Belangrijk: max_input_vars beperkt het aantal variabelen - niet de Totale grootte van het onderzoek. De grenzen voor de grootte zijn post_max_grootte en upload_max_filesize verantwoordelijk. Beide moeten overeenkomen met de geselecteerde increment zodat verzoeken niet elders worden geannuleerd.
Serverarchitecturen in een oogopslag: Apache, NGINX, FPM, Container
Of en waar een wijziging effect heeft, hangt sterk af van de architectuur. Een kort overzicht dat veel probleemoplossing verkort:
- Apache met mod_php:
.htaccesskanphp_valueingesteld. Treedt onmiddellijk in werking, maar alleen in deze context. - Apache + PHP-FPM (proxy_fcgi):
.htaccessgenegeerdphp_value. Wijzigingen worden aangebracht inphp.ini,.user.iniof in de FPM-pool. - NGINX + PHP-FPM: Geen
.htaccess-bestanden. Configuratie viaphp.ini,.user.iniof FPM pool; NGINX zelf kent de waarde niet. - Container/BeheerdVeranderingen vaak via paneeloptie, omgevingsvariabele of mount van het ini-bestand. Controleer na updates/deployments of waarden blijven bestaan.
In FPM-omgevingen bescherm ik mezelf door de waarde direct in de zwembad en laad de service opnieuw:
; /etc/php/8.2/fpm/pool.d/www.conf
php_admin_value[max_input_vars] = 7000
Dan: systemctl reload php8.2-fpm (of herlaad de service op de juiste manier)
Voor .user.ini Het volgende is van toepassing: Wijzigingen zijn niet altijd onmiddellijk actief. Afhankelijk van gebruiker_ini.cache_ttl duurt het minuten voordat de nieuwe waarden zichtbaar zijn. Ik plan daarom een wachttijd of een FPM reload. Foutmelding: WordPress blijft de oude waarde rapporteren, ook al is het bestand correct gelokaliseerd - dan treedt de cache TTL in werking of wordt een masterwaarde geblokkeerd.
Belangrijk: Stel php_value alleen in .htaccess, wanneer mod_php actief is. In FPM-opstellingen leidt dit meestal tot 500 fouten omdat de webserver de richtlijn niet begrijpt.
Meten in plaats van raden: Variabelen live tellen en knelpunten simuleren
Voordat ik de waarde „op vermoedens“ verhoog, meet ik de werkelijke vraag. Een korte diagnostische helper als tijdelijke code in een plugin die u moet gebruiken of functies.php schrijft de telling naar het logboek:
<?php
// Waarschuwing: Alleen tijdelijk gebruiken en daarna verwijderen.
add_action('admin_init', functie () {
if (!empty($_POST)) {
// Recursief tellen van alle bladwaarden
$count = 0;
$it = nieuwe RecursieveIteratorIterator(nieuwe RecursieveArrayIterator($_POST));
foreach ($it als $v) { $count++; }
error_log('POST vars (recursief): ' . $count);
error_log('max_input_vars (ini): ' . ini_get('max_input_vars'));
}
});
Zo kan ik meteen zien of een opslagproces zijn limiet heeft bereikt. Ik test ook met een „stressformulier“ (bijvoorbeeld gegenereerde dummyvelden) om te controleren of er geen velden meer verdwijnen na een verhoging. Belangrijk: Leeg caches zodat de backend niet nog oude toestanden weergeeft.
Speciale gevallen: Multisite, REST API, Ajax en uploads
Op MultisiteNetwerkinstellingen, rolgebaseerde opties en taalspecifieke invoer tellen bijzonder snel op in subnetwerken. Ik plan vanaf het begin met hogere waarden en controleer per subnetwerk omdat de panelen aanzienlijk kunnen verschillen.
Niet elke WordPress-functie wordt in gelijke mate beïnvloed: REST API-aanroepen sturen vaak JSON in de request body, wat niet wordt herkend als een $_POST wordt geparseerd; max_invoer_var is daar doorgaans niet van toepassing. Klassieke admin-ajax.php-requests (POST-formulieren) zijn duidelijk gebonden aan de limiet. Dus als je bouwers gebruikt die opslaan via Ajax, moet je nog steeds de limiet in de gaten houden.
Gedefinieerd voor uploaden van bestanden max_bestand_uploads het maximum aantal gelijktijdige bestanden, terwijl upload_max_filesize en post_max_grootte de limieten voor de grootte instellen. Als uploads deze waarden overschrijden, treden er fouten op, ongeacht max_invoer_var. In beperkende omgevingen kunnen webserver- of WAF-limieten (bijv. limieten voor request body) ook ingrijpen - een typische reden voor verzoeken die „plotseling“ worden geannuleerd ondanks correct ingestelde PHP-waarden.
Foutpreventie op codeniveau: wanneer incrementeren alleen niet genoeg is
Vanuit het oogpunt van een ontwikkelaar is het vaak verstandig om grote configuraties op te splitsen in Ondersecties of om ze stap voor stap op te slaan. De volgende patronen verminderen de stortvloed aan variabelen:
- Paginering/stappenVerdeel lange formulieren in stappen en sla elke stap op aan de serverkant.
- ChunkingSplits grote optie-arrays op in blokken en zet ze achter elkaar over via Ajax.
- Differentiële opslagAlleen gewijzigde velden verzenden in plaats van de hele optiestructuur.
- Seriële opslagGebruik een gestructureerde optie met serialisatie in plaats van veel afzonderlijke velden (beperkt het aantal variabelen bij het verzenden).
Deze patronen minimaliseren de afhankelijkheid van max_invoer_var en maakt beheerprocessen robuuster, vooral in omgevingen met strikte providergrenzen.
Best practices en checklist voor lopende activiteiten
- Meten vóór het opheffenLog het aantal variabelen voor kritieke acties (menu opslaan, bouwpagina opslaan).
- Toename in fasenVerhoog in redelijke stappen (3000 → 5000 → 7000) en test na elke stap.
- Architectuur controlerenControleer de handler (mod_php/FPM/CGI) en gebruik het juiste pad (php.ini, .user.ini, FPM pool).
- Masterwaarde bevestigenVraag de leverancier naar de globale grenswaarde en laat dit documenteren.
- Veiligheidsmodules synchroniserenSuhosin en vergelijkbare limieten parallel verhogen.
- De configuratie versiebeheerNeem ini/pool bestanden op in deployment processen zodat updates geen waarden resetten.
- Lege cachesOngeldig maken van object cache, pagina cache en OPCache na wijzigingen.
- Groottelimieten in een oogopslag: post_max_grootte, upload_max_filesize, max_bestand_uploads, max_uitvoering_tijd en geheugenlimiet stem op de juiste manier af.
- Bewaking instellenControleer de logboeken op terugkerende „afgekapt“ opslagprocessen en beheerfouten.
Praktische testscenario's die verborgen problemen snel aan het licht brengen
Bij audits voer ik drie korte tests uit: 1) Sla een uitgebreid menu met sortering op; 2) Dupliceer een builderpagina met veel widgets/repeaters en sla opnieuw op; 3) Dien een lang formulier in met optionele/verborgen velden. Als een van de stappen inconsistent winkels, is max_invoer_var een goede kandidaat. Pas als alle drie de scenario's betrouwbaar werken, worden mijn aanpassingen als veerkrachtig beschouwd - zelfs bij groei.
Kort samengevat
De instelling max_invoer_var fungeert als een poortwachter voor alle binnenkomende velden en bepaalt vaak of WordPress gegevens netjes opslaat of stiekem opslokt. Met 3000 als ondergrens en 5000-10000 voor gegevensrijke opstellingen (bron [1], [4]), creëer ik de nodige speelruimte en elimineer ik raadselachtige foutpatronen. Ik controleer elke stap met WordPress Site Health en phpinfo() om masterwaarden, caches en beveiligingsmodules duidelijk te herkennen. Alleen als providerlimieten, lokale bestanden en actieve PHP-instanties overeenkomen, zullen aanpassingen betrouwbaar werken. Door aandacht te besteden aan deze keten voorkom je downtime, verlaag je de ondersteuningskosten en houd je de Prestaties van de site is constant hoog.
