WordPress « max_input_vars » : pourquoi les menus et formulaires se cassent et comment le réparer

Ce que max_input_vars limite réellement (et pourquoi WordPress l’atteint)

max_input_vars est une directive de configuration PHP qui plafonne le nombre de variables d’entrée acceptées par requête. Les variables d’entrée proviennent typiquement de :

• Champs du corps POST (soumissions de formulaires)
• Paramètres de la requête GET
• Cookies (oui, eux aussi)

Dans l’administration WordPress, les principaux coupables sont les menus de navigation gigantesques, les constructeurs de pages complexes, les menus multilingues, les éditeurs d’attributs produits et les groupes de champs personnalisés qui rendent de nombreuses répétitions. Chaque élément de tableau imbriqué compte comme une variable.

Ainsi, quand WordPress construit un POST pour l’éditeur de menu qui inclut des centaines de champs menu-item-*, PHP analyse tout jusqu’à atteindre le plafond — puis il s’arrête. WordPress reçoit un jeu de données tronqué et « enregistre » fidèlement cette réalité tronquée. C’est pourquoi l’interface peut sembler avoir réussi alors que les données sont manquantes.

Faits intéressants et contexte historique (parce que ce problème a une histoire)

1. PHP n’a pas toujours eu max_input_vars ; il est devenu courant comme mesure d’atténuation contre les collisions de tables de hachage et les abus de type injection de variables qui pouvaient consommer CPU et mémoire lors de l’analyse de très grosses requêtes.
2. La valeur par défaut est souvent 1000 sur de nombreuses distributions, mais les panneaux d’hébergement et les builds « durcis » la réduisent fréquemment sans vous en informer.
3. Avant que max_input_vars soit bien connu, on accusait WordPress de « perdre au hasard » des éléments de menu — car l’échec est silencieux à moins de regarder les logs.
4. PHP compte les entrées imbriquées individuellement : acf[field_1][sub][0][name] n’est pas « une chose » ; c’est plusieurs variables une fois aplati dans la table de symboles interne.
5. Les navigateurs n’imposent pas cette limite. Le client envoie tout ; le serveur écarte le reste. Cette asymétrie explique pourquoi on a l’impression d’un bug fantôme.
6. Certains environnements plus anciens utilisaient Suhosin (un patch/extension de durcissement) qui introduisait ses propres limites comme suhosin.post.max_vars ; des hébergeurs legacy conservent parfois ces contraintes.
7. Les menus WordPress peuvent exploser le comptage d’entrées parce que chaque élément de menu n’est pas un seul champ ; c’est un paquet (titre, URL, classes, target, XFN, position, parent, etc.).
8. Des cookies volumineux (marketing, A/B testing, outils de consentement) peuvent aussi consommer le budget d’input-vars, car les cookies sont aussi analysés en variables.
9. HTTP/2 et les stacks modernes ont rendu les grosses requêtes d’administration plus fiables au niveau transport, ce qui augmente ironiquement la fréquence à laquelle vous heurez des limites d’analyse côté serveur plutôt que des timeouts réseau.

Vérité opérationnelle sobre : des limites comme max_input_vars ne sont pas des « bugs ». Ce sont des coupe-circuits. Mais si le coupe-circuit est trop petit pour votre charge, vous subissez des dégradations.

Une citation paraphrasée : « L’espoir n’est pas une stratégie ». Dans ce cas : ne comptez pas sur le fait que le menu s’enregistre. Mesurez la taille de la requête et configurez en conséquence.

À quoi cela ressemble dans l’interface : cassures réelles, pas de la théorie

Voici les schémas que j’observe dans des flottes WordPress en production, où « le site semble correct » jusqu’à ce qu’un éditeur essaie de modifier quelque chose.

Menus

• Symptôme : Vous ajoutez des éléments de menu, cliquez sur « Enregistrer le menu », et certains éléments disparaissent ou reviennent en arrière.
• Pourquoi : WordPress poste une énorme liste de champs menu-item. PHP n’analyse que les N premières variables, et la queue n’atteint jamais WordPress.
• Indice : C’est pire quand vous réordonnez, ajoutez beaucoup d’éléments d’un coup, ou avez des méga-menus avec de nombreux niveaux imbriqués.

Constructeurs de pages et champs personnalisés

• Symptôme : Les pages Elementor/ACF/WPBakery s’enregistrent, mais certains blocs se réinitialisent, les répétiteurs perdent des lignes, ou des sous-champs « aléatoires » sont vides.
• Pourquoi : Les répétiteurs et structures imbriquées explosent en milliers de variables.
• Indice : Les petites modifications s’enregistrent correctement ; les grosses modifications corrompent seulement une partie des données.

Formulaires

• Symptôme : Des formulaires complexes sont soumis mais arrivent avec des champs manquants, ou des validations échouent sur des champs que l’utilisateur a bien remplis.
• Pourquoi : PHP écarte les variables au-delà de la limite ; le plugin voit des clés manquantes et les traite comme vides.
• Indice : Cela se corrèle avec des formulaires ayant des sections répétables, des assistants multi-étapes, ou beaucoup de champs cachés.

Édition de produits WooCommerce

• Symptôme : Les attributs produits, variations ou métadonnées « ne tiennent pas ».
• Pourquoi : Les variations peuvent générer un nombre de variables d’entrée par enregistrement véritablement absurde.
• Indice : Les produits simples vont bien ; les produits variables sont hantés.

Petite blague #1 : Le formulaire n’a pas oublié vos données. PHP a juste décidé qu’il en avait assez pour aujourd’hui.

Playbook de diagnostic rapide

Ceci est l’ordre qui trouve le goulot rapidement sans errer dans l’administration WordPress comme un touriste perdu.

Premier point : confirmer que le symptôme est une troncation de la requête, pas un problème d’autorisations ou de cache

• Reproduisez l’enregistrement dans un seul navigateur, connecté en tant qu’administrateur.
• Vérifiez les logs serveur pour un avertissement PHP à propos de max_input_vars.
• Vérifiez si seule la « queue » d’un grand jeu de données est manquante (pattern classique de troncation).

Deuxième point : identifier quelle SAPI PHP gère wp-admin

• Nginx avec PHP-FPM ? Apache avec php-fpm ? Apache avec mod_php ? Conteneur avec un ini personnalisé ?
• Ne devinez pas. Confirmez en utilisant une requête en ligne de commande ou un phpinfo contrôlé limité aux admins seulement.

Troisième point : vérifier la configuration active et qui l’écrase

• Inspectez php -i et les paramètres du pool FPM concernés.
• Cherchez des overrides par répertoire (.user.ini, .htaccess), des overrides du panneau, ou des fragments conf.d.
• Puis effectuez un seul changement à un seul endroit et rechargez le service correct.

Quatrième point : évaluer les limites adjacentes

• post_max_size et upload_max_filesize (limites de taille)
• max_input_time (temps d’analyse)
• Terminaison de requête FPM (request_terminate_timeout)
• Limites de taille côté Nginx/Apache (client_max_body_size, LimitRequestBody)

Si vous suivez cet ordre, vous trouverez généralement la cause racine en 10–20 minutes. Sinon, vous « corrigerez » en mettant tout à 11 puis vous vous demanderez pourquoi l’usage mémoire ressemble à celui d’un mineur de crypto qui a emménagé.

Comment PHP compte les « input vars » (la partie que tout le monde interprète mal)

Les gens lisent max_input_vars=1000 et pensent « mon formulaire a 200 champs, je suis en sécurité ». Puis ils déploient un champ répétiteur et tout casse.

Le parsing d’entrée de PHP transforme les paramètres entrants en paires clé/valeur dans des superglobales comme $_POST. Lorsque vous envoyez des structures imbriquées (fréquent dans WordPress), PHP les développe. Exemple :

• menu-item[123][title]=Home
• menu-item[123][url]=/
• menu-item[123][classes]=top

Ce sont trois variables, pas « un élément de menu ». Maintenant multipliez par des centaines d’éléments et des dizaines de propriétés. Vous atteignez 1000 plus vite que prévu.

Autre point : les cookies comptent. Beaucoup d’outils de personnalisation et d’analytics peuvent ajouter de gros cookies. Même si votre POST d’administration est proche de la limite, quelques cookies peuvent faire basculer le total. Ce n’est pas la cause la plus courante, mais quand cela arrive, c’est particulièrement injuste.

Enfin : la troncation n’est pas toujours « supprimer les derniers éléments que vous avez ajoutés ». C’est « supprimer les variables qui viennent après le seuil dans l’ordre d’analyse ». L’ordre d’analyse est approximativement l’ordre des champs dans le corps encodé de la requête. Si votre plugin change l’ordre des champs, les « pièces manquantes » peuvent sembler aléatoires.

Petite blague #2 : max_input_vars, c’est comme une limite de réunion de bureau : après 1000 entrées, personne n’écoute plus de toute façon.

Où le définir : Apache, Nginx+PHP-FPM, cPanel, conteneurs

Règle d’or : changez le réglage là où le runtime le lit

Il y a plusieurs façons de « définir » des valeurs PHP. Seules certaines s’appliquent à votre chemin de requête réel. Si vous exécutez Nginx + PHP-FPM, éditer le php.ini d’Apache ne fera rien sinon vous donner une fausse confiance.

Nginx + PHP-FPM (le plus courant sur VPS modernes)

Emplacements typiques :

• /etc/php/8.x/fpm/php.ini
• /etc/php/8.x/fpm/conf.d/*.ini
• Fichier de pool FPM : /etc/php/8.x/fpm/pool.d/www.conf (peut override via php_admin_value)

Après modification : rechargez php8.x-fpm. Recharger seulement Nginx n’appliquera pas les changements ini PHP.

Apache avec PHP-FPM

Les mêmes règles PHP-FPM s’appliquent. Apache n’est qu’un reverse proxy vers FPM. Vous devez toujours recharger FPM. Le reload d’Apache est optionnel sauf si vous avez changé la config du proxy.

Apache avec mod_php (moins courant aujourd’hui)

Les paramètres proviennent généralement du php.ini chargé par Apache et des fichiers conf.d additionnels. Les changements exigent un reload/restart d’Apache.

Hébergement partagé / cPanel / Plesk

Utilise souvent des réglages ini par utilisateur via le panneau ou .user.ini. Mais attention : l’interface du panneau peut écrire dans un ini tandis que le PHP en cours lit un autre (différentes versions PHP, different handler). Confirmez avec une requête d’exécution.

Conteneurs (Docker, Kubernetes)

Soit intégrez l’ini dans l’image, soit montez un fichier de config. Le piège le plus fréquent : éditer un fichier dans un conteneur en cours d’exécution et le perdre au prochain déploiement. S’il n’est pas dans Git ou le manifeste de déploiement, il n’existe pas.

Quelle valeur faut-il définir ?

Valeurs de travail courantes :

• 3000 pour un « WordPress plus grand que la moyenne » (menus plus larges, quelques répétiteurs ACF)
• 5000–10000 pour l’édition intensive de variations WooCommerce, menus multilingues, ou constructeurs de pages utilisés comme tableurs

Je ne suis pas hostile aux valeurs élevées, mais je suis hostile à les fixer haut sans garde-fous. Si vous augmentez les input vars, considérez aussi les limites de taille de requête et les règles WAF, et surveillez la mémoire et le temps des PHP-FPM. Rendez-le sûr, pas seulement permissif.

Tâches pratiques (commandes, sorties et décisions)

Ce sont les tâches « faites ceci, voyez cela, décidez ceci » que j’utilise quand je suis d’astreinte et que le menu de quelqu’un est en train de se manger lui-même.

Tâche 1 : Vérifier le réglage PHP CLI (repère rapide)

cr0x@server:~$ php -i | grep -i max_input_vars
max_input_vars => 1000 => 1000

Ce que cela signifie : Le PHP CLI est actuellement réglé sur 1000. Cela peut correspondre — ou pas — au runtime web (FPM vs CLI peuvent différer).

Décision : Si le CLI est bas, c’est un indice que les défauts de votre distro sont bas. Confirmez quand même la SAPI web ensuite.

Tâche 2 : Identifier le service PHP-FPM en cours d’exécution et la version

cr0x@server:~$ systemctl list-units --type=service | grep -E 'php.*fpm'
php8.2-fpm.service                 loaded active running   The PHP 8.2 FastCGI Process Manager

Ce que cela signifie : PHP-FPM 8.2 est en cours d’exécution.

Décision : Tout changement de configuration doit être appliqué aux chemins de config FPM pour PHP 8.2, et vous devez recharger ce service.

Tâche 3 : Demander à PHP-FPM quel fichier ini il utilise (via php-fpm -i)

cr0x@server:~$ php-fpm8.2 -i | grep -E 'Loaded Configuration|Scan this dir'
Loaded Configuration File => /etc/php/8.2/fpm/php.ini
Scan this dir for additional .ini files => /etc/php/8.2/fpm/conf.d

Ce que cela signifie : C’est l’emplacement faisant autorité pour l’ini de FPM. Les fragments conf.d peuvent override des valeurs.

Décision : Éditez /etc/php/8.2/fpm/php.ini ou ajoutez un fichier dédié dans conf.d (préférable pour la maintenabilité).

Tâche 4 : Vérifier le max_input_vars courant pour le contexte FPM

cr0x@server:~$ php-fpm8.2 -i | grep -i max_input_vars
max_input_vars => 1000 => 1000

Ce que cela signifie : Le runtime web est aussi réglé à 1000 (du moins du point de vue de FPM).

Décision : Augmenter est justifié si votre requête d’administration WordPress nécessite plus de 1000 variables.

Tâche 5 : Chercher des overrides dans les configs de pool FPM

cr0x@server:~$ grep -R --line-number -E 'max_input_vars|php_(admin_)?value' /etc/php/8.2/fpm/pool.d
/etc/php/8.2/fpm/pool.d/www.conf:315:;php_admin_value[max_input_vars] = 1000

Ce que cela signifie : Il y a un override commenté. S’il était activé, il forcerait la valeur pour ce pool.

Décision : Choisissez un plan de contrôle : soit le définir globalement via php.ini/conf.d, soit l’imposer dans le pool avec php_admin_value. Ne divisez pas les sources de vérité.

Tâche 6 : Ajouter un fichier conf.d dédié pour la clarté

cr0x@server:~$ sudo tee /etc/php/8.2/fpm/conf.d/99-wordpress-input-vars.ini >/dev/null <<'EOF'
; WordPress admin can exceed default input var count (menus, ACF, Woo variations).
max_input_vars = 5000
EOF

Ce que cela signifie : Vous avez ajouté un fragment de config à haute priorité (99-*) pour définir la valeur pour FPM.

Décision : 5000 est un point de départ raisonnable pour les gros menus. Si vous éditez régulièrement des milliers de variations, envisagez plus — après mesure.

Tâche 7 : Recharger PHP-FPM et vérifier que le changement a bien été pris

cr0x@server:~$ sudo systemctl reload php8.2-fpm
cr0x@server:~$ php-fpm8.2 -i | grep -i max_input_vars
max_input_vars => 5000 => 5000

Ce que cela signifie : FPM a la nouvelle valeur.

Décision : Reproduisez maintenant l’enregistrement WordPress. Si cela échoue encore, vous êtes probablement confronté à une autre limite (taille du corps, timeouts, ou logique applicative).

Tâche 8 : Vérifier les logs d’erreur PHP pour le message révélateur

cr0x@server:~$ sudo tail -n 50 /var/log/php8.2-fpm.log
[27-Dec-2025 11:09:31] WARNING: [pool www] child 18422 said into stderr: "PHP Warning:  Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini in Unknown on line 0"

Ce que cela signifie : Avertissement classique : PHP a atteint la limite et a tronqué l’analyse des entrées.

Décision : Si vous voyez ceci au moment de l’enregistrement admin, arrêtez de débattre. Augmentez la limite (et confirmez qu’il n’y a pas d’autres contraintes).

Tâche 9 : Vérifier les limites de taille du corps de requête Nginx (problème compagnon fréquent)

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -R --line-number 'client_max_body_size' /etc/nginx
/etc/nginx/nginx.conf:36:    client_max_body_size 10m;

Ce que cela signifie : Nginx rejettera les corps de plus de 10 Mo (avec un 413).

Décision : Si les admins uploadent de gros payloads sérialisés de constructeurs ou des modifications de variations produit, vous devrez peut-être augmenter cela aussi. Si vous ne voyez pas de 413, ne le touchez pas.

Tâche 10 : Confirmer les limites de corps de requête Apache si Apache est en jeu

cr0x@server:~$ sudo apachectl -M | head
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)

Ce que cela signifie : La liste des modules confirme qu’Apache est installé et ce qui est chargé (cet extrait ne montre pas encore le handler PHP).

Décision : Si Apache fait face au site, cherchez LimitRequestBody quand vous observez des 413/400.

Tâche 11 : Trouver quel handler PHP Apache utilise (mod_php vs proxy_fcgi)

cr0x@server:~$ sudo apachectl -M | grep -E 'php|proxy_fcgi'
 proxy_fcgi_module (shared)

Ce que cela signifie : Apache utilise le proxy FastCGI, généralement vers PHP-FPM.

Décision : Les changements doivent se faire dans PHP-FPM, pas dans le php.ini d’Apache (à moins que vous utilisiez aussi mod_php, ce qui n’est pas le cas ici).

Tâche 12 : Valider le chemin php.ini actif et les overrides via un endpoint temporaire réservé aux admins

cr0x@server:~$ sudo -u www-data php -r 'echo "SAPI=".php_sapi_name().PHP_EOL; echo "max_input_vars=".ini_get("max_input_vars").PHP_EOL;'
SAPI=cli
max_input_vars=1000

Ce que cela signifie : Ceci montre encore les valeurs CLI, pas les valeurs web. Rappel utile : le contexte compte.

Décision : Si vous ne pouvez pas exposer phpinfo de manière sûre, préférez inspecter FPM directement (php-fpm8.2 -i) et les logs. Évitez de laisser des endpoints de diagnostic traîner.

Tâche 13 : Confirmer que WordPress reçoit un POST tronqué en comptant les clés dans un test contrôlé

cr0x@server:~$ sudo tee /var/www/html/wp-content/mu-plugins/input-vars-debug.php >/dev/null <<'EOF'

Ce que cela signifie : Un plugin mu qui affiche des comptes pour les admins quand vous ajoutez ?input_vars_debug=1 dans wp-admin. Cela aide à prouver la troncation sans deviner.

Décision : Utilisez-le brièvement, puis supprimez-le. Les plugins de debug sont comme des échelles : utiles jusqu’à ce que quelqu’un se prenne les pieds dedans.

Tâche 14 : Surveiller PHP-FPM pour l’impact ressource après avoir augmenté la limite

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager | sed -n '1,15p'
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 10:55:02 UTC; 16min ago
       Docs: man:php-fpm8.2(8)
    Process: 18110 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php8.2-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: 18106 (php-fpm8.2)
     Status: "Processes active: 1, idle: 5, Requests: 914, slow: 0, Traffic: 0.00req/sec"

Ce que cela signifie : Surveillez la montée des comptes « slow » ou l’instabilité après l’augmentation de la capacité d’analyse.

Décision : Si les requêtes lentes augmentent, vous devrez peut-être ajuster les enfants FPM, les timeouts, ou protéger wp-admin par des accès plus restreints plutôt que d’autoriser une analyse illimitée.

Remarque sur la sécurité : Chacune de ces tâches est opérationnellement réversible. Ce n’est pas un accident. Quand vous changez la config en production, vous voulez que l’« annulation » soit banale.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait un site WordPress « piloté par le marketing », mais il n’était pas petit. Il y avait plusieurs langues, des centaines de landing pages, et une structure de navigation qui continuait d’accumuler des éléments comme des bernacles. Un mardi, la responsable marketing a demandé un nettoyage du menu. Un éditeur a passé une heure à réorganiser les menus et a cliqué sur enregistrer.

Le site n’est pas tombé. C’était le problème. Cela ressemblait à un enregistrement réussi, mais le menu avait perdu une partie des éléments. L’éditeur les a rajoutés, a enregistré à nouveau, et a perdu un autre morceau. Les tickets de support ont commencé par « l’en-tête n’a plus de liens ». L’équipe sociale a escaladé parce que des campagnes payantes envoyaient du trafic vers des pages qui n’étaient plus accessibles depuis la navigation.

L’ingénierie a supposé que c’était un problème de cache — parce que la plupart des bizarreries WordPress en production sont liées au cache. Ils ont purgé le CDN, vidé l’object cache, redémarré PHP-FPM, et rechargé Nginx. Rien n’a changé. La mauvaise hypothèse était : « Si l’interface affiche un message de succès, le serveur a accepté les données. » Ce n’était pas le cas.

La correction a été d’augmenter max_input_vars et de vérifier que l’avertissement avait disparu des logs. La leçon plus profonde était culturelle : traitez les actions d’administration comme des écritures en production. Loggez-les, surveillez-les, et ne supposez pas que les « changements marketing » sont inoffensifs. Ce sont des changements en production avec une interface différente.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation était obsédée par le « durcissement ». Ils avaient une checklist : réduire les timeouts, diminuer les limites, désactiver tout ce qui semble optionnel. Quelqu’un a remarqué que PHP avait par défaut max_input_vars=1000 et a jugé que c’était trop généreux. Ils l’ont descendu à 300 globalement pour « réduire la surface d’attaque ».

Rien n’a cassé immédiatement. Le site servait les pages correctement. La surveillance restait verte. Puis l’équipe contenu a déployé un nouveau méga-menu pour une campagne saisonnière, plus quelques variantes multilingues. L’éditeur de menu est devenu un jeu de hasard. Parfois ça s’enregistrait ; parfois non ; parfois à moitié. Les gens accusaient WordPress. Les gens accusaient le plugin de menu. Les gens s’accusaient entre eux.

L’optimisation s’est retournée contre eux parce qu’elle a réduit la tolérance pour des charges légitimes sans améliorer vraiment la posture de sécurité. Les attaquants cherchant à DoSser votre parseur PHP ne s’arrêteront pas poliment à 301 variables ; ils useront d’autres vecteurs. Pendant ce temps, vos utilisateurs métier butent sur une limite qui n’a jamais été mesurée contre leur usage réel.

Ils ont restauré la valeur à 5000 pour le trafic wp-admin et l’ont couplée à de meilleurs contrôles : allowlist IP pour l’admin, rate limiting, et règles WAF ciblant les vrais schémas malveillants. La sécurité s’est améliorée. La productivité est revenue. L’« optimisation » est devenue une anecdote de mise en garde chaque fois que quelqu’un voulait « resserrer » un réglage sans télémétrie.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe faisait tourner WordPress à l’échelle dans des conteneurs. Rien de glamour : images standard, GitOps, et le type de gestion de config qui fait bâiller les auditeurs. Ils avaient un ensemble connu de directives PHP dans un fichier de config monté, y compris max_input_vars. Ils avaient aussi un job de smoke test qui effectuait un enregistrement wp-admin en staging en utilisant un fixture de menu volumineux.

Une semaine, un ingénieur a bumpé l’image de base et a involontairement changé l’ordre de recherche des ini. Le fichier monté existait toujours, mais il n’était pas lu par le processus FPM. En staging, le smoke test a échoué : l’enregistrement du menu a entraîné des éléments manquants, et les logs montraient l’avertissement max_input_vars.

Parce que la pratique était ennuyeuse et automatisée, l’échec n’a jamais atteint la production. Ils ont ajusté l’entrypoint du conteneur pour s’assurer que le fragment ini atterrisse dans le bon répertoire conf.d pour cette image. Le pipeline suivant est passé au vert, et personne en dehors de l’ingénierie n’a su qu’il y avait presque eu un incident.

C’est tout l’intérêt. Les meilleures victoires d’opérations sont celles pour lesquelles personne n’a à applaudir parce que rien n’a pris feu.

Erreurs courantes : symptômes → cause racine → correctif

1) Les éléments de menu disparaissent après enregistrement

Symptôme : Vous enregistrez un grand menu ; des éléments s’évaporent ou se réordonnent étrangement.

Cause racine : Troncation due à max_input_vars. WordPress enregistre des données POST partielles.

Correctif : Augmenter max_input_vars pour le runtime web (FPM/mod_php) et confirmer via les logs que l’avertissement disparaît.

2) Les lignes du répétiteur ACF disparaissent lors de la mise à jour

Symptôme : Des sous-champs du répétiteur manquent après l’enregistrement d’un article.

Cause racine : Le total des variables d’entrée dépasse la limite en raison de tableaux de champs imbriqués.

Correctif : Augmenter max_input_vars ; si vous atteignez des comptes absurdes, envisagez de refactorer la structure des champs ou de répartir le contenu en plusieurs posts/groupes de meta plus petits.

3) Le formulaire est soumis mais certains champs arrivent vides

Symptôme : L’email de soumission/payload CRM manque des champs aléatoires.

Cause racine : Variables d’entrée tronquées ; le plugin lit des clés manquantes comme vides.

Correctif : Augmenter max_input_vars et vérifier qu’il n’y a pas d’erreurs post_max_size / taille du corps. Vérifiez aussi l’encombrement des cookies si le formulaire est proche du seuil.

4) Vous avez augmenté max_input_vars mais rien n’a changé

Symptôme : Vous avez édité php.ini ; l’avertissement persiste.

Cause racine : Mauvais fichier ini ou mauvaise SAPI ; override au niveau du pool FPM qui force l’ancienne valeur ; service non rechargé.

Correctif : Utilisez php-fpmX.Y -i pour confirmer le « Loaded Configuration File », cherchez les overrides de pool, rechargez le service FPM correct.

5) WP-Admin retourne 413 Request Entity Too Large

Symptôme : L’enregistrement échoue avec un 413 ou une page blanche.

Cause racine : Limite de taille du serveur web (client_max_body_size ou LimitRequestBody) plutôt que le nombre d’input vars.

Correctif : Augmentez la limite serveur pertinente pour les chemins wp-admin si possible ; n’ouvrez pas globalement sans raison.

6) Des enregistrements admin aléatoires échouent seulement pour certains utilisateurs

Symptôme : Un éditeur ne peut pas enregistrer de gros formulaires ; un autre peut.

Cause racine : Différences de cookies. Certains utilisateurs portent des ensembles de cookies plus volumineux (segments analytics, outils de preview), ce qui les fait dépasser la limite.

Correctif : Réduisez l’encombrement des cookies pour wp-admin, assurez-vous que les outils de consentement n’injectent pas de cookies marketing dans les sessions admin, et augmentez max_input_vars si nécessaire.

7) Vous avez augmenté les limites et la mémoire PHP-FPM a grimpé

Symptôme : Après le changement, les workers FPM consomment plus de mémoire, ou des OOM kills surviennent sous charge.

Cause racine : Des charges d’analyse plus importantes par requête augmentent l’utilisation mémoire ; les requêtes wp-admin sont lourdes et sérialisées.

Correctif : Utilisez une valeur sensée, ajustez FPM (children, limites mémoire), et restreignez l’accès admin. Ne « corrigez » pas en mettant des valeurs illimitées en espérant que tout ira bien.

Listes de vérification / plan étape par étape

Étape par étape : correction sûre en production pour un enregistrement de menu cassé

1. Reproduire et horodater l’échec. Vous voulez un point de corrélation dans les logs.
2. Vérifier les logs pour l’avertissement explicite. S’il est présent, continuez ; s’il est absent, ne tombez pas dans le tunnel.
3. Identifier le runtime (FPM/mod_php) et les chemins ini actifs. Utilisez l’introspection FPM, pas des suppositions.
4. Augmenter max_input_vars à un seul endroit faisant autorité. Préférez un fichier conf.d dédié avec des commentaires.
5. Recharger le bon service. Reload FPM pour des changements FPM ; reload Apache pour mod_php.
6. Vérifier la valeur runtime. Confirmer via php-fpm -i ou une sortie contrôlée réservée aux admins.
7. Retester le workflow exact de l’éditeur. Même menu, mêmes étapes, même utilisateur si possible.
8. Supprimer l’instrumentation de debug temporaire. Surtout les mu-plugins que vous avez ajoutés pour le comptage.
9. Surveiller les effets secondaires. Requêtes lentes, mémoire FPM, augmentation des temps de requête.

Checklist : ne manquez pas les limites adjacentes

• Le serveur renvoie-t-il un 413 ? Si oui, c’est la taille du corps, pas les input vars.
• Le corps POST est-il volumineux ? Vérifiez post_max_size.
• PHP met-il trop de temps à parser ? Vérifiez max_input_time et les timeouts FPM.
• Un WAF bloque-t-il les POST wp-admin ? Vérifiez des 403 au bord.
• Les cookies sont-ils énormes pour les utilisateurs affectés ? Comparez nombre/taille des cookies.

Checklist : valeurs sensées et garde-fous

• Commencez à 3000 ou 5000 pour les grands sites ; augmentez uniquement avec des preuves.
• Alignez post_max_size et la taille du corps serveur avec les besoins réels.
• Protégez wp-admin : MFA, allowlist IP si possible, rate limits, et exposition réduite.
• Versionnez les changements : config dans le contrôle de version ou au moins dans un système de gestion de configuration.
• Rendez le rollback simple : un fichier, un reload, une commande de vérification.

FAQ

1) Quelle est la valeur par défaut de max_input_vars pour PHP ?

Souvent 1000, mais « défaut » varie : paquets de distro, panneaux d’hébergement et builds durcis peuvent la modifier. Vérifiez la valeur active du runtime.

2) Pourquoi WordPress affiche « Menu enregistré » quand tout n’a pas été sauvegardé ?

Parce que WordPress ne voit que ce que PHP a parsé. Si PHP tronque les entrées, WordPress reçoit un jeu de données valide (mais incomplet) et le traite normalement.

3) Est-ce un bug WordPress ?

Non. C’est une limite d’analyse côté serveur PHP. WordPress pourrait éventuellement mieux avertir, mais la cause racine est la configuration et la taille de la requête.

4) Jusqu’où dois-je monter max_input_vars ?

Pour beaucoup de sites, 3000–5000 fonctionne. Les produits variables WooCommerce et les constructeurs lourds peuvent nécessiter 10000+. Mesurez, puis définissez la plus petite valeur qui empêche la troncation.

5) Si j’augmente max_input_vars, dois-je redémarrer quelque chose ?

Oui. Pour PHP-FPM vous devez recharger/restart le service FPM. Recharger Nginx ou Apache seul n’appliquera pas les changements ini PHP sauf si vous utilisez mod_php.

6) J’ai modifié php.ini mais phpinfo affiche encore l’ancienne valeur. Pourquoi ?

Le plus souvent : vous avez édité le mauvais php.ini (CLI vs FPM), un override au niveau du pool force une autre valeur, ou le service n’a pas été rechargé. Utilisez php-fpm -i pour confirmer les fichiers de configuration chargés.

7) Les cookies peuvent-ils vraiment affecter les problèmes max_input_vars ?

Oui. Les cookies sont des variables d’entrée aussi. Habituellement c’est le corps POST la cause principale, mais des cookies volumineux peuvent faire basculer des requêtes borderline.

8) Y a-t-il un inconvénient de sécurité à l’augmenter ?

Cela peut augmenter le travail d’analyse et l’usage mémoire par requête, ce qui peut être abusé dans des scénarios de DoS. Atténuez par des contrôles sur wp-admin, du rate limiting, des règles WAF et des limites de taille raisonnables.

9) max_input_vars affecte-t-il les uploads de fichiers ?

Pas directement. Les uploads sont gouvernés par les limites de taille (upload_max_filesize, post_max_size, et les limites du serveur web). Mais les formulaires d’upload peuvent aussi contenir beaucoup de champs, donc les deux aspects peuvent importer.

10) Puis-je le corriger dans WordPress sans toucher la config serveur ?

Parfois vous pouvez réduire le nombre de variables d’entrée en simplifiant les menus, en scindant les formulaires, en réduisant la complexité des répétiteurs, ou en évitant des plugins qui génèrent de nombreux champs cachés. Mais si le site a légitimement besoin de complexité, la correction correcte est côté serveur.

Conclusion : étapes sûres pour la production

Si les menus WordPress ou les formulaires complexes « s’enregistrent » mais ne sont pas réellement sauvegardés, considérez cela comme une perte de données. Pas une nuisance. Le coupable le plus fréquent est la troncation par max_input_vars, et c’est diagnostiquable avec les logs et quelques vérifications runtime.

Faites ceci ensuite, dans l’ordre :

1. Reproduisez l’échec et vérifiez les logs PHP-FPM pour l’avertissement « Input variables exceeded ».
2. Confirmez quel runtime PHP sert wp-admin et d’où il charge sa configuration.
3. Augmentez max_input_vars à une valeur mesurée (souvent 5000), rechargez le service correct, et vérifiez la valeur runtime.
4. Retestez le workflow admin exact et surveillez les limites adjacentes (413s, tailles/timeouts).
5. Placez la modification de config dans un emplacement durable (fragment conf.d, IaC, montage de conteneur) pour qu’elle survive au prochain déploiement.

La meilleure correction est celle qui n’exige pas d’héroïsme à 4h du matin. Définissez-la, vérifiez-la, et rendez le changement reproductible. Vos éditeurs ne vous remercieront jamais. C’est comme ça que vous saurez que ça a marché.