Reconnaître des valeurs tronquées à l’enregistrement
Vous enregistrez un grand formulaire de réglages, puis certaines valeurs reviennent à leur état initial ou disparaissent. Le journal mentionne « Input variables exceeded » avec un nombre. PHP peut avoir arrêté la lecture d’une partie des variables de la requête avant que WordPress traite le formulaire. Un message de succès dans l’interface ne suffit pas à prouver que toutes les valeurs ont été conservées.
Le résultat recherché est un envoi complet, reçu dans le bon contexte PHP, puis des réglages identiques après réouverture. Ce guide concerne les formulaires de réglages et les interfaces de composants qui transmettent beaucoup de champs. Il ne faut pas attribuer automatiquement chaque menu incomplet ou chaque erreur d’éditeur à cette limite.
Sur un site auto-hébergé, les droits d’administration permettent le relevé et les comparaisons ; la modification de PHP demande l’accès correspondant à l’hébergement. Sur une plateforme gérée, les paramètres peuvent être imposés. En multisite, mesurez la portée des réglages communs avant de toucher à un formulaire ou à une configuration partagée.
Préserver les réglages avant de cliquer de nouveau
Arrêtez les enregistrements répétés dès que vous constatez une perte. Un formulaire rouvert avec des valeurs manquantes peut ensuite les enregistrer comme si elles étaient volontaires. Conservez les informations encore visibles, une capture privée de la structure utile et l’export de réglages prévu par le composant s’il existe. Gardez la date de ces relevés.
Préparez une sauvegarde adaptée des données et une copie pour les essais. Un export de contenu WordPress ne conserve pas nécessairement tous les réglages du module concerné. Si la procédure modifie aussi un fichier PHP de configuration, préservez ce fichier séparément hors du répertoire public. Les deux protections ne se remplacent pas.
Choisissez une valeur témoin sans effet commercial, par exemple un libellé de test sur la copie. Évitez les réglages qui lancent une synchronisation, un envoi ou un changement de prix. Notez les panneaux ouverts et le nombre approximatif d’éléments : certains composants n’ajoutent leurs champs qu’après ouverture d’une zone. Le même formulaire apparent peut donc produire deux requêtes différentes.
Séparer le nombre de variables des autres plafonds
max_input_vars borne les variables d’entrée que PHP accepte, séparément pour les ensembles GET, POST et cookies. La documentation prévoit un avertissement et la troncature des variables au-delà du plafond. La valeur standard documentée est 1 000, mais votre hébergement peut en appliquer une autre. Compter seulement les éléments visibles à l’écran ne donne pas le nombre réel de champs transmis.
D’autres limites portent sur des objets différents. post_max_size concerne le poids du corps POST ; max_input_nesting_level concerne la profondeur des tableaux de paramètres. Une requête multipart peut aussi rencontrer un plafond de parties, avec un message distinct. Augmenter la mémoire ne relève pas automatiquement ces limites.
Consignez le nom exact de la directive citée et le nombre annoncé. Si le serveur répond 403 ou 413 sans avertissement de variables, étudiez ce refus séparément. Si l’application reçoit du JSON et le décode elle-même, le nombre de propriétés JSON ne se confond pas automatiquement avec les variables que PHP remplit dans POST. La requête réelle détermine le diagnostic.
Observer la requête envoyée par le formulaire
Sur la copie, ouvrez les outils de développement de Chrome, puis Réseau ou Network avant l’enregistrement. Cochez Preserve log si une navigation suit l’action et gardez le filtre All : un formulaire peut créer une requête de document, pas seulement Fetch/XHR. Réalisez une seule modification témoin et sélectionnez la requête qui l’envoie. Dans Headers, relevez Request Method et Content-Type ; dans Payload, examinez Form Data ou Request Payload selon le format. Ne publiez ni les jetons de sécurité ni les valeurs privées du formulaire.
Vérifiez si les champs attendus sont déjà absents de l’envoi. Dans ce cas, une limite serveur n’explique pas à elle seule leur disparition : l’interface ou un script peut avoir omis de les préparer. S’ils figurent dans l’envoi mais qu’un avertissement PHP correspond à la même heure, faites rapprocher les deux observations.
Les menus classiques natifs des versions récentes de WordPress conservent une copie JSON des données dans nav-menu-data pour les reconstituer côté serveur. Leur nombre d’entrées ne prouve donc pas à lui seul une perte due à l’ancienne limite de menus. Vérifiez que ce champ est présent et renseigné dans la requête avant d’accuser le plafond. Un script en erreur, un formulaire tiers ou une charge tronquée demande son propre contrôle. Ne désactivez pas ce mécanisme et ne recopiez pas ses fonctions internes dans une extension pour reproduire une ancienne recette.
Relever la valeur effective dans le contexte du domaine
Dans Outils, Santé du site, Informations, ouvrez Serveur et relevez la version PHP ainsi que le nombre maximal de variables d’entrée affiché. Conservez ce relevé avec le domaine et l’heure. La valeur chargée pour le site peut différer de celle d’un autre domaine du compte ou de celle obtenue en ligne de commande.
Consultez le journal PHP privé de l’hébergement au moment exact de l’essai. Un avertissement de démarrage de requête peut se produire avant que la journalisation WordPress soit initialisée. Son absence dans un journal WordPress ne suffit donc pas à exclure une troncature. Évitez de créer une page publique phpinfo() pour obtenir plus de détails.
Si le panneau annonce déjà une valeur supérieure au nombre du message, faites confirmer le fichier chargé et le moteur du domaine. Une configuration enregistrée au mauvais endroit n’a pas encore corrigé le contexte utile. Gardez un exemple unique permettant de comparer l’avant et l’après ; plusieurs augmentations simultanées dans plusieurs fichiers empêcheraient de savoir laquelle s’applique.
Réduire l’envoi lorsque l’outil le permet réellement
La première approche consiste à utiliser un mode d’édition qui transmet moins de champs tout en préservant le résultat. Elle convient lorsque le composant documente des lots, une pagination de réglages ou un enregistrement indépendant par élément. Relevez l’état initial et travaillez sur la copie avant de modifier des données importantes.
Essayez une petite modification avec les panneaux inutiles fermés, puis rouvrez le contenu pour vérifier sa conservation. Le fait de fermer un panneau ne garantit pas que ses champs cessent d’être envoyés : confirmez la différence dans Réseau. Si l’outil offre un lot réduit, conservez son périmètre et contrôlez aussi les éléments non traités.
Ne supprimez pas la moitié d’un menu public pour tester une hypothèse, et ne découpez pas des données exportées arbitrairement. Si une version à peu de champs fonctionne et la grande échoue avec le même avertissement, vous obtenez un indice utile, pas un nombre universel d’éléments admissibles. Remettez les réglages témoins initiaux après l’essai et passez au composant ou à la configuration lorsque la réduction ne répond pas au besoin réel.
Comparer un composant qui ajoute des champs
Si un composant ajoute des réglages au formulaire, comparez son effet sur une copie récente. Dans Extensions, Extensions installées, relevez l’état du seul suspect et désactivez-le si l’opération testée garde son sens sans lui. Enregistrez le même petit cas, contrôlez le résultat puis réactivez le composant avant d’en comparer un autre.
Troubleshooting constitue une aide facultative pour comparer des composants dans votre session. La version documentaire 1.0.2, de Marius L. J., annonce WordPress 5.8 et PHP 7.1 au minimum, testé jusqu’à WordPress 7.1.4 ; cela ne recommande pas une branche PHP ancienne. Dans Extensions, Ajouter une extension, vérifiez le produit puis installez et activez-le si vos droits le permettent. Ouvrez Outils, Santé du site, Troubleshooting, puis Enable Troubleshooting Mode. Le widget du Tableau de bord et le menu de la barre d’administration permettent ensuite de réactiver les composants utiles un par un, puis de terminer avec Disable Troubleshooting Mode.
Ce mode ne relève aucune limite PHP et n’isole pas les données dans une base séparée. Un formulaire enregistrant des réglages produit encore des écritures : utilisez la copie. Les extensions Must Use restent actives et un cache peut fausser la comparaison. Si le composant qui ajoute les champs est confirmé, examinez sa version et son correctif officiel plutôt que de conserver une désactivation qui retire une fonction nécessaire.
Modifier la directive dans le panneau du bon domaine
- La deuxième approche convient lorsqu’un besoin légitime dépasse la limite effective et que l’hébergement autorise une hausse proportionnée. Avec cPanel, ouvrez Logiciel ou Software, puis MultiPHP INI Editor. Sélectionnez le domaine exact ; Home Directory peut élargir l’effet à tout le compte. Conservez les valeurs et fichiers gérés avant modification.
- Dans Basic Mode, sélectionnez le domaine dans Configure PHP INI basic settings. Si
max_input_varsest proposé, modifiez uniquement ce réglage puis cliquez sur Apply. Si l’hébergeur demande Editor Mode, choisissez à nouveau le domaine dans Edit PHP INI settings et vérifiez le chemin indiqué par Path. Modifiez la ligne existante ou ajoutez-la une seule fois, puis cliquez sur Save. Un éditeur vide signifie qu’aucun fichier n’a été chargé à cet emplacement : faites confirmer le contexte avant d’en créer un. Choisissez une valeur fondée sur l’envoi observé et les ressources, pas un chiffre supposé convenir à tous les sites. - Le panneau peut reporter ce réglage dans plusieurs fichiers compatibles, notamment
php.ini,.user.iniet.htaccess. Évitez ensuite une modification manuelle concurrente des mêmes paramètres. Revenez dans Santé du site pour vérifier la valeur chargée, puis testez le même formulaire sur la copie. Une valeur sauvegardée dans le panneau mais inchangée dans le site demande une vérification de contexte. Pour annuler l’essai, restaurez l’ancienne valeur dans le même écran et contrôlez son effet, sans réinitialiser toute la configuration PHP.
Utiliser .user.ini seulement dans un environnement confirmé
- Si le prestataire confirme PHP en CGI ou FastCGI et l’usage de
.user.ini, un accès SFTP ou au gestionnaire de fichiers peut permettre un réglage par répertoire. PHP parcourt les dossiers depuis celui du script demandé jusqu’à la racine web. Pour une requête traitée danswp-admin, un fichier placé seulement danswp-contentne s’applique donc pas. Faites confirmer le dossier commun utile et le nom de fichier attendu : l’hébergeur peut désactiver cette recherche. Conservez l’existant en privé avant édition, sans remplacer son contenu complet. - Modifiez la définition existante de
max_input_vars, ou ajoutez une seule ligne si elle est absente et autorisée. L’exemple utilise 3 000 comme valeur illustrative à adapter. Ce fichier emploie une syntaxe INI, sans ouverture PHP et sansphp_value. Gardez un accès permettant de restaurer la modification indépendamment du tableau de bord. - La relecture de
.user.inipeut être temporisée ; le délai standard documenté est de cinq minutes, mais il est configurable. Attendez le délai confirmé puis relevez la valeur effective avant de refaire l’essai. Si rien ne change, cherchez le fichier chargé ou un plafond imposé au lieu de multiplier les copies. Pour annuler, remettez la valeur initiale ou retirez seulement la ligne ajoutée. N’effacez un fichier nouvellement créé que s’il ne contient aucun autre réglage nécessaire.
max_input_vars = 3000Traiter séparément un plafond de parties multipart
Un message « Multipart body parts limit exceeded » désigne le nombre de parties d’un envoi multipart, pas seulement le nombre de variables simples. Gardez son texte et sa valeur avec le premier avertissement. Une hausse de max_input_vars peut donc ne pas suffire si une autre limite explicite reste plus basse.
Lorsque max_multipart_body_parts existe dans la version PHP utilisée, faites examiner sa valeur effective par le même responsable. Dans le code PHP 8.3 vérifié, sa valeur par défaut -1 déclenche un calcul fondé sur max_input_vars plus max_file_uploads. Une valeur explicite peut donc continuer à limiter la requête après une hausse de max_input_vars. Ne recopiez pas un second nombre dans tous les fichiers et ne modifiez pas max_file_uploads si aucun besoin de fichiers supplémentaires n’est établi.
Si le problème est confirmé, le prestataire adapte cette directive au besoin dans le même contexte autorisé, avec sa valeur initiale conservée. Rejouez ensuite le petit cas, puis le volume représentatif, et vérifiez toutes les données. Un fichier qui n’est plus transféré ou un champ final absent reste un échec même si le premier avertissement a disparu. Restaurez le seul réglage testé s’il n’apporte rien ou dépasse le périmètre validé.
Écarter les corrections qui ne peuvent pas agir à temps
Cette limite est appliquée pendant la préparation des entrées PHP. Ajouter ini_set pour max_input_vars dans wp-config.php, dans le thème ou dans un extrait d’extension n’est pas le bon mécanisme pour la modifier. La directive n’est pas classée comme un réglage librement modifiable pendant l’exécution. Une extension qui affiche un nombre ne garantit pas qu’elle a modifié le traitement du serveur.
Ne changez pas WP_MEMORY_LIMIT, la durée maximale d’exécution ou le poids d’envoi uniquement parce que leurs noms évoquent une limite. Ils répondent à d’autres causes. Gardez la preuve qui désigne le plafond atteint au lieu de cumuler des hausses préventives.
N’insérez pas non plus une directive PHP dans .htaccess en supposant que tout serveur l’accepte. Le mécanisme dépend du mode d’exécution, et une syntaxe non prise en charge peut provoquer une autre panne. Utilisez le panneau ou le fichier confirmé par le prestataire. Sur WordPress.com et les offres qui imposent PHP, une correction du composant ou une intervention du service remplace la modification locale de configuration.
Valider les valeurs, pas seulement le message de sauvegarde
Relevez la nouvelle valeur effective après l’application de la configuration. Sur la copie, ouvrez le même formulaire avec les mêmes panneaux et réalisez la modification témoin. Notez l’heure, puis rouvrez entièrement l’écran. Les valeurs situées au début et à la fin du formulaire doivent être conservées, avec les éléments que vous n’aviez pas voulu modifier.
Comparez le journal de la même requête et vérifiez qu’un autre plafond n’a pas pris le relais. Si l’envoi a changé parce qu’un composant a été corrigé, documentez cette différence au lieu d’attribuer la réussite à la seule hausse PHP. Un test de faible volume ne valide pas encore le volume habituel qui déclenchait le problème.
Contrôlez ensuite une fonction voisine et le rendu public concerné, notamment un menu ou une fiche configurée. La réussite locale se juge sur les données réellement enregistrées et utilisables. Une purge de cache peut aider à voir une correction déjà faite ; elle ne recrée pas les valeurs qui avaient été tronquées avant leur enregistrement.
Restaurer les valeurs perdues avec une portée limitée
Corriger le plafond ne restaure pas les données déjà écrasées. Reprenez votre relevé, l’export de réglages ou la sauvegarde disponible et identifiez exactement les valeurs concernées. Pour un petit ensemble connu, rétablissez-les dans l’interface après validation de l’envoi complet, puis rouvrez le formulaire pour vérifier leur conservation.
Une restauration de base entière pourrait remplacer des articles, inscriptions ou commandes plus récents. Faites préparer une récupération ciblée lorsque les données importantes ne peuvent pas être ressaisies avec certitude. N’importez pas un export de configuration sur la production sans connaître son effet sur les autres réglages et sur les identifiants d’éléments.
Si l’essai de configuration doit être annulé, revenez au réglage initial par la méthode utilisée et contrôlez sa valeur effective. Gardez séparées la restauration de configuration PHP et la récupération des données. Le retour de la première ne remet pas les secondes en place. Conservez les preuves jusqu’à validation du formulaire et des usages qui dépendent de ses valeurs.
Prévenir la croissance silencieuse des formulaires
Documentez le composant propriétaire du formulaire, la limite chargée et le volume qui a été vérifié. Lorsqu’une mise à jour ajoute des champs, un nouvel onglet ou un ensemble de variantes, contrôlez de nouveau l’envoi sur la copie. Une marge adaptée aujourd’hui n’est pas une garantie permanente pour un formulaire qui continue à grandir.
Privilégiez les mécanismes de lots ou d’édition ciblée prévus par l’éditeur plutôt qu’un écran unique accumulant toutes les données. Une amélioration du traitement peut éviter une escalade de limites. Le nombre choisi doit rester justifié et compatible avec la politique de ressources du serveur ; la disparition d’un avertissement ne justifie pas une valeur indéfiniment élevée.
Pour demander une correction, transmettez la version du composant, le chemin de l’écran, le type de requête, l’heure et les messages utiles. Décrivez les valeurs conservées et celles perdues après réouverture. Ne partagez pas une capture complète de charge utile contenant des jetons ou des secrets. Un cas réduit, reproduit sur copie, permet de poursuivre au bon niveau sans réenregistrer sans cesse les mêmes données incomplètes.
