Viele Fehler in WordPress haben eine stille Ursache: die Einstellung php max input vars wordpress. Ich zeige, wie dieser Grenzwert Einstellungen kappt, Formulare unvollständig speichert und die Leistung ausbremst – und wie ich den Wert korrekt setze.
Zentrale Punkte
Zum Einstieg fasse ich die wichtigsten Aspekte kurz zusammen, damit du schnell erkennst, wo du ansetzen solltest.
- Grenzwert: Max Input Vars legt fest, wie viele Variablen PHP pro Anfrage akzeptiert.
- Symptome: Fehlende Theme-Optionen, abgeschnittene Formulare, Plugin-Fehler.
- Hosting: Master-Werte und Sicherheitsmodule können lokale Einstellungen übersteuern.
- Optimierung: php.ini, .htaccess oder .user.ini sorgfältig anpassen.
- Richtwerte: 3000 als Minimum, 5000–10000 für große Setups (Quelle [1], [4]).
Was ist PHP Max Input Vars – und warum betrifft es WordPress?
Der Parameter max_input_vars begrenzt die Anzahl an POST- und GET-Variablen, die PHP in einer einzelnen Anfrage verarbeitet, und dient damit als Schutz vor übergroßen Formularen und Konfigurationsfluten. In einer typischen WordPress-Installation addieren sich Optionen aus Theme-Panels, Customizer, Widgets, Menüs, Plugin-Einstellungen und Formularfeldern schnell zu vielen Hundert Einträgen, was bei zu kleinem Limit zu abgeschnittenen Daten führt. Gerade Page Builder, E‑Commerce-Plugins und mehrstufige Formulare treiben die Zahl hoch, weshalb ich einen Startwert von 3000 setze und für üppige Setups 5000 bis 10000 in Betracht ziehe (Quelle [1], [4]). Wer zusätzlich andere PHP-Limits zu streng setzt, verschärft die Lage, weil dann mehrere Stellschrauben gleichzeitig bremsen. Wichtig ist ein bewusster Umgang: Ein zu niedriger Wert sorgt für stille Datenverluste, ein sinnvoll erhöhter Wert schafft dagegen Stabilität.
Typische Fehlerbilder in WordPress bei zu niedrigem Limit
Ein erstes Warnsignal ist das unvollständige Speichern von Theme-Optionen: Ich klicke auf Speichern, doch nur ein Teil der Einstellungen bleibt erhalten, während andere scheinbar “zurückspringen”. Ebenso kritisch sind große Formulare, bei denen einzelne Felder spurlos fehlen, weil PHP überzählige Variablen verwirft und so Bestellungen, Registrierungen oder Support-Anfragen unvollständig ankommen. In Menüs mit vielen Einträgen verschwinden Änderungen oder Sortierungen, was Betreiber oft irrtümlich Plugins zuschreiben. Page Builder verlieren Modul- oder Widget-Einstellungen, obwohl der Editor korrekt arbeitet, was die Ursachenanalyse erschwert. Wenn ich solche Symptome gebündelt sehe, prüfe ich sofort den Wert von max_input_vars, bevor ich länger an Plugins oder Themes drehe.
Hosting-Limits, Master-Werte und Sicherheitsmodule
Selbst wenn ich die Werte lokal erhöhe, kann ein serverweiter Master-Wert vom Provider jede Änderung übersteuern, was besonders auf Shared-Hosting vorkommt. Typisches Szenario: Ich setze 5000 in meiner php.ini, doch der Server akzeptiert nur 1000, weil ein globaler Grenzwert greift und lokale Anpassungen ignoriert. Zusätzliche Sicherheitsmodule wie Suhosin führen eigene Input-Grenzen ein, die ich dann separat anheben muss, sonst blockieren sie trotz korrekter max_input_vars nach wie vor überzählige Felder. Deshalb starte ich bei hartnäckigen Fällen mit einer Anfrage an den Hoster und lasse mir den effektiven Master-Wert bestätigen sowie mögliche Module benennen. Erst wenn diese Kette sauber konfiguriert ist, wirken lokale Änderungen wirklich durchgängig.
Diagnose: So finde ich den Engpass schnell
Bei Verdacht öffne ich zuerst die Website-Status-Seite im WordPress-Admin und prüfe den tatsächlich aktiven Wert von max_input_vars, idealerweise ergänzt durch phpinfo() in einer Testdatei. Weichen meine Änderungen vom angezeigten Wert ab, blockiert entweder ein Master-Wert oder ich habe an der falschen Instanz gedreht (etwa falscher PHP-Handler oder falsches Verzeichnis). Testweise speichere ich ein Menü mit vielen Einträgen oder ein langes Formular und beobachte, ob Einträge fehlen, was den Engpass bestätigt. Parallel achte ich darauf, Objekt- oder Seiten-Cache sowie OPCache zu leeren, weil sonst alte Konfigurationen sichtbar bleiben. Sinnvoll ist zudem ein Blick auf das PHP Memory Limit, da große Formulare und Builder-Oberflächen speicherintensiv sind und ein knappes Limit im Zusammenspiel weitere Effekte auslösen kann.
Konfiguration in der Praxis: Vier zuverlässige Wege
Ich gehe bei der Anpassung pragmatisch vor: Erst frage ich den Hoster und lasse mir die Erhöhung serverseitig freischalten, weil das am wenigsten fehleranfällig ist und Master-Werte direkt berücksichtigt. Mit Root- oder Managed-Zugriff editiere ich die php.ini, setze einen klaren Wert (etwa 5000) und starte den PHP-Dienst neu, damit die Änderung aktiv wird. Auf Apache-Systemen kann ich in der .htaccess arbeiten, sofern mod_php läuft, und bei aktivem Suhosin dessen Grenzwerte dazu anheben. Ohne Zugriff auf die zentrale php.ini nutze ich eine .user.ini im Webroot, was bei vielen Managed-Umgebungen zuverlässig greift. Danach verifiziere ich die Änderung in WordPress und mit phpinfo(); erst wenn beides passt, teste ich Speichern von Menüs, Formularen und Optionen.
; php.ini
max_input_vars = 5000
# .htaccess (nur mit mod_php)
<IfModule mod_php.c>
php_value max_input_vars 5000
# Optional bei Suhosin:
php_value suhosin.request.max_vars 5000
php_value suhosin.post.max_vars 5000
</IfModule>
; .user.ini
max_input_vars = 7000
Werte wählen: Wie hoch ist sinnvoll?
Ich starte selten unter 3000, weil moderne Admin-Oberflächen schon im Grundbetrieb viele Variablen senden (Quelle [1]). Für Seiten mit Page Builder, vielen Widgets, sprachspezifischen Menüs oder umfangreichen Plugin-Panels setze ich 5000 als alltagstauglichen Richtwert (Quelle [4]). Bei großen WooCommerce-Shops mit variablen Produkten, Filtern und komplexen Checkout-Formularen plane ich 7000 bis 10000 ein, um Wachstumsspielraum zu lassen. Wichtig ist, schrittweise zu testen: Nach jeder Erhöhung prüfe ich die Problemstellen, damit ich nicht zu hoch greife, aber die Fehler sicher verschwinden. Das Ziel ist ein Wert, der heute trägt und Reserven für morgen lässt, ohne andere Limits unnötig zu strapazieren.
Wechselwirkungen mit Plugins und Themes
Ich beachte, dass Caching- oder Performance-Plugins eigene .htaccess-Regeln schreiben und damit zuvor gesetzte Werte überdecken können, weshalb ich nach Änderungen an solchen Tools die aktiven Direktiven erneut prüfe. Page Builder mit verschachtelten Modulen erhöhen die Varianz stark, besonders wenn globale und seitenbezogene Optionen zusammenkommen. Menü-Generatoren oder Import-Tools schicken in einem Rutsch viele Felder, was bei knappen Limits sofort zu abgeschnittenen Daten führt. Vor allem nach Plugin-Updates prüfe ich die Auswirkungen kurz, weil neue Funktionen zusätzliche Einstellungen mitbringen können. Wer über große Navigationsstrukturen klagt, findet hierzu weiterführende Hinweise unter Menü-Performance, denn Menüs sind echte Variablen-Treiber.
Performance und Sicherheit: Die richtige Balance
Ein höheres Limit bedeutet, dass PHP mehr Variablen akzeptiert, was in Summe mehr Daten pro Anfrage heißen kann, aber nicht automatisch zu Lastspitzen führt. Kritisch wird es erst, wenn Formulare mit tausenden Feldern regelmäßig verarbeitet werden und damit Speicher sowie CPU stärker beanspruchen. Deshalb kombiniere ich die Erhöhung von max_input_vars mit einem Blick auf Ausführungszeit, Input-Größe und Memory-Limit, damit das Gesamtsystem stimmig bleibt. Sicherheitsseitig ist der Grenzwert sinnvoll, weil er fehlerhafte oder absichtlich überladene Requests begrenzen kann; mit Provider-Schutz, WAF und Rate Limits lässt sich hier ein sicheres Niveau halten. Ich wähle daher einen Wert, der reale Anforderungen abdeckt, ohne blind jedes Limit maximal zu weiten.
| Szenario | Typische Variablen | max_input_vars | Hinweis |
|---|---|---|---|
| Kleine Site (Blog, Portfolio) | 200–800 | 3000 | Genügend Reserve für Theme-Updates (Quelle [1]) |
| Mehrsprachige Site mit Builder | 800–2500 | 5000 | Viele Panels und Menüs (Quelle [4]) |
| WooCommerce mit Varianten | 2000–6000 | 7000–10000 | Spielraum für Checkout und Produkt-Optionen (Quelle [1], [4]) |
| Enterprise-Formulare/CRM | 5000+ | 10000+ | Eng mit Hoster abstimmen, Monitoring nutzen |
Troubleshooting: Änderungen greifen nicht – was jetzt?
Wenn sich trotz Anpassung nichts ändert, prüfe ich zuerst den aktiven PHP-Handler (mod_php, FPM, CGI), denn falscher Kontext macht lokale Dateien wirkungslos. Danach vergleiche ich phpinfo() mit WordPress-Site-Health, um Caches auszuschließen und effektive Werte zu sehen. Bleibt der Wert hartnäckig niedrig, existiert fast immer ein Master-Wert beim Provider, den ich mir schriftlich bestätigen und anheben lasse. Bei FPM-Setups muss ich ggf. den richtigen Pool konfigurieren oder den Dienst neu laden, sonst bleibt der alte Wert aktiv. Sperrt Suhosin weiterhin, erhöhe ich dessen request.max_vars und post.max_vars, bis die Formularanzahl sicher durchgeht.
Praxisbeispiele und Richtwerte, die tragen
Für eine Blog-Installation mit Standard-Theme und wenigen Plugins setze ich 3000, teste Menüs und Theme-Optionen und lasse es dabei meist bewenden. Eine Unternehmensseite mit Mega-Menüs, mehrsprachigen Inhalten und Page Builder fahre ich direkt mit 5000 an, was in der Praxis spürbar Ruhe bringt. Ein größeres Shop-System mit Varianten und Zusatzfeldern startet bei 7000 und steigert bei Bedarf bis 10000, damit Produkt-Importe, Checkout-Anpassungen und Admin-Panels sauber greifen. Entscheidend ist weniger der absolute Wert als das Verhältnis zu tatsächlichen Formulargrößen und Panels, weshalb ich Änderungen protokolliere und Lastspitzen beobachte. So entsteht ein Setting, das dauerhaft verlässlich läuft und spätere Skalierung zulässt.
So zählt PHP Variablen wirklich – und warum Builder so schnell an Grenzen stoßen
Wichtig für die Praxis: Jedes Formularfeld entspricht mindestens einer Variablen in $_POST oder $_GET. WordPress nutzt für komplexe Panels häufig Array-Syntax mit Klammern, etwa option[group][subgroup][field]. PHP baut daraus verschachtelte Arrays auf – und jedes Blatt in dieser Struktur zählt gegen max_input_vars. Repeater-Felder, dynamische Listen, Mega-Menüs und Übersetzungsvarianten blähen die Zahl besonders schnell auf. Hinzu kommen Hidden-Felder (z. B. Nonces, IDs) und systemische Parameter, die Betreiber leicht übersehen. Das erklärt, warum ein Formular mit „nur“ 300 sichtbaren Eingaben intern 1000+ Variablen erzeugen kann.
Besonders betroffen sind:
- Menü-Editoren (jeder Menüpunkt bringt mehrere Felder und Metadaten mit)
- Page Builder mit verschachtelten Widgets, Global- und Seiten-Optionen
- Option-Panels von Themes/Plugins, die ganze Konfigurationsbäume übertragen
- Mehrsprachige Setups, bei denen je Sprache Felder dupliziert werden
Wichtig: max_input_vars begrenzt die Anzahl der Variablen – nicht die Gesamtgröße der Anfrage. Für Größenlimits sind post_max_size und upload_max_filesize zuständig. Beides sollte zur gewählten Erhöhung passen, damit Requests nicht an anderer Stelle abbrechen.
Server-Architekturen im Blick: Apache, NGINX, FPM, Container
Ob und wo eine Änderung greift, hängt stark von der Architektur ab. Ein kurzer Überblick, der viele Fehlersuchen abkürzt:
- Apache mit mod_php:
.htaccesskannphp_valuesetzen. Greift sofort, aber nur in diesem Kontext. - Apache + PHP-FPM (proxy_fcgi):
.htaccessignoriertphp_value. Änderungen erfolgen inphp.ini,.user.inioder im FPM-Pool. - NGINX + PHP-FPM: Keine
.htaccess-Dateien. Konfiguration viaphp.ini,.user.inioder FPM-Pool; NGINX selbst kennt den Wert nicht. - Container/Managed: Änderungen oft per Panel-Option, Umgebungsvariable oder Mount der ini-Datei. Nach Updates/Deployments prüfen, ob Werte persistieren.
In FPM-Umgebungen sichere ich mich ab, indem ich den Wert direkt im Pool setze und den Dienst neu lade:
; /etc/php/8.2/fpm/pool.d/www.conf
php_admin_value[max_input_vars] = 7000
; Danach: systemctl reload php8.2-fpm (oder Dienst passend neu laden)
Für .user.ini gilt: Änderungen werden nicht immer sofort aktiv. Je nach user_ini.cache_ttl dauert es Minuten, bis neue Werte sichtbar sind. Ich plane daher Wartezeit oder einen FPM-Reload ein. Fehlersignal: WordPress meldet weiter den alten Wert, obwohl die Datei korrekt liegt – dann greift die Cache-TTL oder ein Master-Wert blockiert.
Wichtig: Setze php_value nur in .htaccess, wenn mod_php aktiv ist. In FPM-Setups löst das meist 500-Fehler aus, weil der Webserver die Direktive nicht versteht.
Messen statt Raten: Variablen live zählen und Engpässe simulieren
Bevor ich den Wert „auf Verdacht“ erhöhe, messe ich den realen Bedarf. Ein kurzer Diagnose-Helfer als temporärer Code in einem Must-Use-Plugin oder functions.php schreibt die Zählung in das Log:
<?php
// Warnung: Nur temporär einsetzen und danach entfernen.
add_action('admin_init', function () {
if (!empty($_POST)) {
// Rekursive Zählung aller Blattwerte
$count = 0;
$it = new RecursiveIteratorIterator(new RecursiveArrayIterator($_POST));
foreach ($it as $v) { $count++; }
error_log('POST vars (recursive): ' . $count);
error_log('max_input_vars (ini): ' . ini_get('max_input_vars'));
}
});
So sehe ich sofort, ob ein Speichervorgang an die Grenze stößt. Zusätzlich teste ich mit einem „Stressformular“ (z. B. generierten Dummy-Feldern), um zu verifizieren, dass nach einer Erhöhung keine Felder mehr verschwinden. Wichtig: Caches leeren, damit das Backend nicht noch alte Zustände anzeigt.
Spezialfälle: Multisite, REST-API, Ajax und Uploads
In Multisite-Netzwerken summieren sich Netzwerkeinstellungen, rollenbasierte Optionen und sprachspezifische Einträge besonders schnell. Ich plane hier von vornherein mit höheren Werten und prüfe pro Teilnetzwerk, weil sich die Panels erheblich unterscheiden können.
Nicht jede WordPress-Funktion ist gleichermaßen betroffen: REST-API-Aufrufe schicken häufig JSON im Request-Body, der nicht als $_POST geparst wird; max_input_vars greift dort typischerweise nicht. Dagegen sind klassische admin-ajax.php-Anfragen (POST-Formulare) klar an das Limit gebunden. Wer also Builder nutzt, die per Ajax speichern, muss trotzdem die Grenze im Blick behalten.
Bei Dateiuploads definiert max_file_uploads die maximale Anzahl gleichzeitiger Dateien, während upload_max_filesize und post_max_size die Größenlimits setzen. Überschreiten Uploads diese Werte, entstehen Fehler unabhängig von max_input_vars. In restriktiven Umgebungen können außerdem Webserver- oder WAF-Grenzen (z. B. Request-Body-Limits) eingreifen – ein typischer Grund für „plötzlich“ abbrechende Requests trotz korrekt gesetzter PHP-Werte.
Fehlervermeidung auf Code-Ebene: Wenn Erhöhen allein nicht reicht
Aus Entwicklersicht ist es oft sinnvoll, große Konfigurationen in Teilabschnitte aufzuteilen oder schrittweise zu speichern. Folgende Muster reduzieren die Variable-Flut:
- Pagination/Steps: Lange Formulare in Schritte gliedern und serverseitig je Schritt speichern.
- Chunking: Große Options-Arrays in Blöcke teilen und nacheinander per Ajax übertragen.
- Differenzielles Speichern: Nur geänderte Felder absenden statt den gesamten Optionsbaum.
- Serielle Speicherung: Statt vieler Einzelfelder eine strukturierte Option mit Serialisierung verwenden (begrenzt die Variablenzahl beim Senden).
Diese Muster mindern Abhängigkeiten von max_input_vars und machen Admin-Vorgänge robuster, gerade in Umgebungen mit strengen Provider-Grenzen.
Best Practices und Checkliste für den laufenden Betrieb
- Vor der Erhöhung messen: Variablenzahl bei kritischen Aktionen (Menü speichern, Builder-Seite sichern) protokollieren.
- Stufenweise erhöhen: In sinnvollen Schritten (3000 → 5000 → 7000) anheben und nach jedem Schritt testen.
- Architektur prüfen: Handler (mod_php/FPM/CGI) verifizieren und den passenden Weg (php.ini, .user.ini, FPM-Pool) nutzen.
- Master-Wert bestätigen: Beim Provider den globalen Grenzwert erfragen und dokumentieren lassen.
- Sicherheitsmodule synchronisieren: Suhosin- und vergleichbare Limits parallel anheben.
- Konfiguration versionieren: ini-/Pool-Dateien in Deployment-Prozesse einbinden, damit Updates Werte nicht zurücksetzen.
- Caches leeren: Objekt-Cache, Seiten-Cache und OPCache nach Änderungen invalidieren.
- Größenlimits im Blick: post_max_size, upload_max_filesize, max_file_uploads, max_execution_time und memory_limit passend abstimmen.
- Monitoring etablieren: Logs auf wiederkehrende „abgeschnittene“ Speichervorgänge und Admin-Fehler prüfen.
Praxisnahe Testszenarien, die verdeckte Probleme schnell zeigen
In Audits fahre ich drei kurze Tests: 1) Ein umfangreiches Menü mit Sortierung speichern; 2) Eine Builder-Seite mit vielen Widgets/Repeatern duplizieren und erneut sichern; 3) Ein langes Formular mit optionalen/ausgeblendeten Feldern absenden. Wenn einer der Schritte inkonsistent speichert, ist max_input_vars ein heißer Kandidat. Erst wenn alle drei Szenarien zuverlässig funktionieren, gelten meine Anpassungen als belastbar – auch bei Wachstum.
Kurz zusammengefasst
Die Einstellung max_input_vars wirkt wie ein Torwächter für alle eingehenden Felder und entscheidet oft darüber, ob WordPress sauber speichert oder heimlich Daten verschluckt. Mit 3000 als Untergrenze und 5000–10000 für datenreiche Setups (Quelle [1], [4]) schaffe ich den nötigen Spielraum und eliminiere rätselhafte Fehlerbilder. Ich verifiziere jeden Schritt mit WordPress-Site-Health und phpinfo(), um Master-Werte, Caches sowie Sicherheitsmodule eindeutig zu erkennen. Erst wenn Provider-Limits, lokale Dateien und aktive PHP-Instanz zusammenpassen, wirken Anpassungen zuverlässig. Wer diese Kette beachtet, verhindert Ausfälle, reduziert Support-Aufwand und hält die Performance der Site konstant hoch.
