PrestaShop max_input_vars : Pourquoi les produits avec de nombreuses déclinaisons ne s'enregistrent pas

Comprendre max_input_vars dans PrestaShop

Si vous avez déjà essayé de sauvegarder un produit avec des dizaines ou des centaines de déclinaisons dans PrestaShop et obtenu un échec silencieux, une sauvegarde partielle ou une erreur cryptique, le coupable est presque certainement la directive PHP max_input_vars. Ce paramètre contrôle combien de champs de formulaire individuels PHP acceptera dans une seule requête POST. Lorsque PrestaShop soumet un formulaire produit qui dépasse cette limite, chaque champ au-delà du seuil est silencieusement écarté, conduisant à des sauvegardes incomplètes, des déclinaisons manquantes ou des données qui disparaissent tout simplement sans aucun message d'erreur visible.

Par défaut, la plupart des installations PHP sont livrées avec max_input_vars défini à 1000. Pour un simple blog ou un site vitrine, c'est largement suffisant. Pour PrestaShop en revanche, les pages d'édition de produits peuvent générer des milliers de champs de formulaire, surtout lorsque les déclinaisons, les champs multilingues et les caractéristiques personnalisées sont impliqués. Comprendre cette directive, savoir comment calculer la valeur dont votre boutique a réellement besoin et appliquer correctement le correctif vous fera gagner des heures de débogage.

Pourquoi PrestaShop nécessite des valeurs élevées de max_input_vars

Le formulaire d'édition de produit de PrestaShop est l'un des formulaires les plus complexes de toute plateforme e-commerce. Chaque déclinaison d'un produit génère de multiples champs de saisie : un pour l'impact sur le prix, un pour l'impact sur le poids, un pour la quantité, un pour la référence, un pour le code EAN-13, un pour le code UPC, un pour le MPN, un pour la quantité minimale, un pour le seuil de stock bas, un pour la date de disponibilité, et plusieurs autres selon votre configuration. Une seule déclinaison peut facilement produire 15 à 25 champs de formulaire.

Maintenant multipliez cela par le nombre de déclinaisons. Un t-shirt disponible en 5 tailles et 10 couleurs a 50 déclinaisons. À 20 champs par déclinaison, cela représente déjà 1 000 champs rien que pour l'onglet des déclinaisons. Ajoutez les champs de base du produit, les champs SEO pour chaque langue, les valeurs de caractéristiques, les prix spécifiques et les autres onglets, et vous pouvez facilement atteindre 1 500 à 2 000 champs pour un produit modérément complexe.

Pour les boutiques vendant des produits avec des ensembles d'attributs étendus, comme l'électronique avec différentes capacités de stockage, couleurs, options de RAM et variantes régionales, un seul produit peut avoir 200 déclinaisons ou plus, générant plus de 4 000 champs de formulaire. La limite par défaut de 1 000 n'est même pas proche d'être suffisante.

Symptômes d'un max_input_vars trop bas

L'aspect le plus frustrant lorsqu'on atteint la limite max_input_vars est que PHP ne génère pas d'erreur. Il tronque silencieusement les données d'entrée. Cela signifie que vous verrez une variété de symptômes déroutants sans aucune indication claire de ce qui a mal tourné.

Le symptôme le plus courant est que les déclinaisons disparaissent après la sauvegarde. Vous créez 80 déclinaisons, cliquez sur sauvegarder, et lorsque la page se recharge, seules 40 sont présentes. Le formulaire a soumis les 80, mais PHP n'a traité que la première partie des données POST avant d'atteindre la limite, de sorte que les déclinaisons restantes n'ont jamais été reçues par le serveur.

Un autre symptôme courant est que les données du produit se sauvegardent partiellement. L'onglet des informations de base se sauvegarde correctement, mais les données de tarification, SEO ou déclinaisons sont perdues. Cela se produit car les champs de formulaire sont soumis dans un ordre spécifique, et tous les champs situés après le point de coupure sont écartés.

Vous pouvez également constater que la page produit se recharge simplement sans sauvegarder du tout, ou PrestaShop affichant une erreur générique telle que « Une erreur s'est produite lors de la mise à jour du produit. » Dans PrestaShop 1.7 et 8.x, la page produit basée sur Symfony peut afficher des erreurs de validation pour des champs obligatoires qui étaient en fait remplis mais tronqués par PHP.

Un symptôme moins évident affecte les boutiques multilingues. Si votre boutique supporte 5 langues, chaque champ de texte est multiplié par 5. Un produit qui se sauvegarde correctement sur une boutique monolingue échoue sur une boutique multilingue car les champs de langue supplémentaires poussent le total au-delà de la limite.

Comment vérifier votre valeur actuelle de max_input_vars

Avant de faire des modifications, vérifiez votre paramètre actuel. Créez un fichier PHP dans le répertoire racine de votre PrestaShop (n'oubliez pas de le supprimer ensuite pour des raisons de sécurité) :

<?php phpinfo(); ?>

Accédez à ce fichier via votre navigateur et recherchez max_input_vars. Vous verrez à la fois la Valeur locale (celle qui est actuellement active) et la Valeur maître (celle par défaut depuis php.ini). Faites attention à la Valeur locale, car elle peut différer de la Valeur maître si un .htaccess ou une configuration par répertoire la surcharge.

Alternativement, vous pouvez vérifier depuis le back office PrestaShop. Naviguez vers Paramètres avancés, puis Informations. La section de configuration PHP affiche les paramètres PHP clés, y compris max_input_vars. PrestaShop 1.7.7 et les versions ultérieures affichent également un avertissement sur cette page si la valeur est considérée comme trop basse.

Calculer la valeur de max_input_vars dont vous avez besoin

Plutôt que de définir aveuglément un nombre élevé, vous pouvez estimer la valeur dont votre boutique a besoin. Utilisez cette formule comme base :

Valeur requise = (nombre de déclinaisons x champs par déclinaison) + champs de base du produit + (champs de texte x nombre de langues) + marge de sécurité

Pour un exemple pratique, considérons une boutique avec 3 langues et un produit qui a 100 déclinaisons. Le calcul serait le suivant : 100 déclinaisons multipliées par 20 champs chacune donnent 2 000. Les champs de base du produit à travers tous les onglets contribuent à environ 200. Les champs de texte (nom, description, titre meta, description meta, réécriture de lien et autres) multipliés par 3 langues ajoutent 150 supplémentaires. En ajoutant une marge de sécurité de 20 %, le total atteint environ 2 820.

Pour la plupart des boutiques PrestaShop, définir max_input_vars à 10000 offre une marge confortable. Les boutiques avec des produits ayant plus de 300 déclinaisons ou fonctionnant en 5 langues ou plus devraient envisager 20000 voire 50000. Le surcoût mémoire d'une valeur plus élevée est négligeable sur les serveurs modernes.

Comment augmenter max_input_vars

Méthode 1 : php.ini (recommandée)

Si vous avez accès à la configuration PHP de votre serveur, modifier php.ini est l'approche la plus propre. Localisez votre fichier php.ini (la sortie de phpinfo() vous indique exactement quel fichier est chargé) et trouvez ou ajoutez la ligne suivante :

max_input_vars = 10000

Après avoir sauvegardé le fichier, redémarrez votre serveur web ou le service PHP-FPM pour que le changement prenne effet. Avec Apache et mod_php, redémarrez Apache. Avec Nginx et PHP-FPM, redémarrez le service php-fpm. La commande exacte dépend de votre système d'exploitation et de votre version de PHP.

Méthode 2 : .htaccess (Apache avec mod_php ou mod_fcgid)

Si vous n'avez pas accès à php.ini, comme sur un hébergement mutualisé, vous pouvez essayer d'ajouter la directive au fichier .htaccess dans le répertoire racine de votre PrestaShop :

php_value max_input_vars 10000

Cette méthode ne fonctionne que si PHP s'exécute comme module Apache (mod_php). Si votre hébergeur utilise PHP-FPM ou CGI, cette directive causera une erreur 500 Internal Server Error. Dans ce cas, supprimez immédiatement la ligne et essayez la méthode suivante.

Méthode 3 : .user.ini (PHP-FPM / CGI)

Pour les serveurs exécutant PHP-FPM, créez ou modifiez un fichier .user.ini dans le répertoire racine de votre PrestaShop :

max_input_vars = 10000

Notez que les modifications de .user.ini ne sont pas immédiates. PHP met ce fichier en cache pour une durée définie par user_ini.cache_ttl, qui est par défaut de 300 secondes (5 minutes). Attendez au moins 5 minutes après la sauvegarde du fichier avant de tester.

Méthode 4 : Panneau de contrôle de l'hébergement

De nombreux hébergeurs exposent les paramètres PHP via leur panneau de contrôle. Dans cPanel, naviguez vers « Sélectionner la version PHP » ou « Éditeur INI MultiPHP » et cherchez max_input_vars. Dans Plesk, allez dans les Paramètres PHP de votre domaine. DirectAdmin et les autres panneaux ont des options similaires. C'est souvent la méthode la plus simple sur un hébergement mutualisé.

La complication du patch Suhosin

Suhosin est un patch de sécurité PHP qui était courant sur les anciens serveurs, particulièrement ceux exécutant PHP 5.x. Il impose son propre ensemble de limites d'entrée qui surcharge le paramètre standard max_input_vars. Même si vous augmentez max_input_vars à 10000, Suhosin peut toujours appliquer une limite inférieure via ses propres directives.

Les paramètres spécifiques à Suhosin que vous devez ajuster sont :

suhosin.post.max_vars = 10000
suhosin.request.max_vars = 10000

Ceux-ci doivent être définis en plus du max_input_vars standard. Si la sortie de votre phpinfo() affiche une section Suhosin, vous êtes concerné et devez ajuster les trois valeurs. Les paramètres Suhosin ne peuvent généralement être modifiés que dans php.ini, pas dans .htaccess ou .user.ini.

Sur les installations modernes PHP 7.x et 8.x, Suhosin est rarement présent. Si vous utilisez une version récente de PHP, vous n'avez presque certainement pas à vous en préoccuper. Cependant, si vous êtes sur un ancien compte d'hébergement mutualisé qui n'a pas été mis à jour, cela vaut la peine de vérifier.

Approches alternatives pour les produits avec plus de 500 déclinaisons

Bien qu'augmenter max_input_vars résolve le problème immédiat, les boutiques avec un nombre extrêmement élevé de déclinaisons par produit devraient envisager des approches alternatives qui réduisent le nombre de champs de formulaire ou contournent entièrement la limitation.

Importer les déclinaisons via CSV

La fonctionnalité d'importation intégrée de PrestaShop traite les déclinaisons par téléchargement de fichier plutôt que par soumission de formulaire, contournant complètement la limite max_input_vars. Préparez un fichier CSV avec vos données de déclinaisons et importez-le via le back office sous Paramètres avancés, Importer. C'est souvent l'approche la plus pratique pour les produits avec des centaines de déclinaisons.

Utiliser l'API Webservice PrestaShop

L'API webservice de PrestaShop vous permet de créer et mettre à jour des déclinaisons de manière programmatique. Les requêtes API ne sont pas soumises à max_input_vars car elles utilisent des charges utiles XML ou JSON structurées plutôt que des données POST encodées en formulaire. Cette approche nécessite des connaissances techniques mais s'adapte à n'importe quel nombre de déclinaisons.

Diviser les produits volumineux

Dans certains cas, il est plus pertinent d'un point de vue commercial de diviser un produit avec plus de 500 déclinaisons en plusieurs produits. Un produit avec 5 tailles et 100 couleurs pourrait être divisé en 5 produits, un par taille, chacun avec 100 options de couleur. Cela permet non seulement d'éviter la limitation technique mais améliore souvent aussi l'expérience client.

Gérer les déclinaisons par lots

Si vous devez utiliser le formulaire du back office, créez les déclinaisons par lots plus petits. Générez 50 déclinaisons à la fois, sauvegardez, puis générez les 50 suivantes. C'est fastidieux mais permet d'éviter d'atteindre la limite sans nécessiter de modification de la configuration serveur.

Vérifier le correctif

Après avoir augmenté max_input_vars, vérifiez que le changement a pris effet. Consultez à nouveau phpinfo() et confirmez que la Valeur locale correspond à ce que vous avez défini. Puis testez en éditant votre produit le plus complexe, en effectuant une petite modification et en sauvegardant. Toutes les déclinaisons et données devraient être préservées.

Si le problème persiste après avoir augmenté la valeur, vérifiez les possibilités supplémentaires suivantes. Votre hébergeur peut surcharger vos paramètres avec une configuration globale. L'instance PHP servant votre site web peut être différente de celle affichée dans un phpinfo() en ligne de commande. Il peut y avoir une limite du serveur web telle que le LimitRequestBody d'Apache ou le client_max_body_size de Nginx qui tronque également la requête. Certains pare-feu applicatifs web (WAF) ou plugins de sécurité (comme ModSecurity) imposent leurs propres limites sur la taille des données POST et le nombre de paramètres.

Paramètres PHP connexes à vérifier

Pendant que vous ajustez max_input_vars, passez en revue ces paramètres connexes qui peuvent également causer des problèmes avec les formulaires de produits volumineux :

post_max_size : Ce paramètre définit la taille maximale des données POST en octets. Si les données de votre formulaire dépassent cette limite (typiquement quand les produits ont de nombreux champs de texte volumineux à travers plusieurs langues), l'intégralité du POST est rejetée. Définissez cette valeur à au moins 32M pour PrestaShop.

memory_limit : Le traitement de milliers de champs de formulaire nécessite de la mémoire. Si PHP manque de mémoire pendant l'analyse des entrées, la requête échoue. Une valeur de 256M ou 512M est recommandée pour PrestaShop.

max_execution_time : La sauvegarde d'un produit avec de nombreuses déclinaisons implique de nombreuses requêtes de base de données. Si l'opération de sauvegarde prend plus de temps que le temps d'exécution autorisé, elle sera interrompue en cours de processus, entraînant des sauvegardes partielles. Définissez cette valeur à au moins 300 secondes pour les boutiques avec des produits complexes.

max_input_nesting_level : PrestaShop utilise des tableaux imbriqués dans ses données de formulaire (par exemple, les champs multilingues utilisent des tableaux comme name[1], name[2]). Le niveau d'imbrication par défaut de 64 est généralement suffisant, mais si vous rencontrez des problèmes avec des structures de formulaire profondément imbriquées, augmentez-le à 128 ou 256.

Notes spécifiques aux versions de PrestaShop

Dans PrestaShop 1.6, la page produit est entièrement en PHP legacy avec une soumission de formulaire traditionnelle. Le problème de max_input_vars affecte toutes les opérations sur la page produit. Il n'y a pas de solution de contournement autre que l'augmentation de la limite ou l'utilisation des importations.

PrestaShop 1.7 a introduit une page produit partiellement basée sur Symfony. Bien que l'architecture ait changé, la soumission de formulaire sous-jacente utilise toujours des données POST et est toujours soumise aux mêmes limites PHP. Le composant de formulaire Symfony peut afficher des messages d'erreur plus informatifs lorsque des champs sont manquants, mais la cause fondamentale est la même.

PrestaShop 8.x présente une page produit entièrement repensée avec une nouvelle structure de formulaire Symfony. La gestion des déclinaisons a été considérablement retravaillée, les déclinaisons étant désormais gérées via une interface dédiée qui charge et sauvegarde les données par AJAX en lots plus petits. Ce changement architectural réduit naturellement l'impact de max_input_vars pour les données de déclinaisons, bien que le formulaire principal du produit puisse toujours être affecté dans les boutiques multilingues avec de nombreuses caractéristiques.

PrestaShop 9.x poursuit la tendance vers la gestion des données basée sur AJAX, réduisant davantage la dépendance aux soumissions massives de formulaires. Cependant, max_input_vars reste pertinent pour les opérations en masse et les modules legacy qui utilisent encore les soumissions de formulaire traditionnelles.

Prévenir les problèmes futurs

Définissez max_input_vars à une valeur généreuse lors de votre installation initiale de PrestaShop plutôt que d'attendre que les problèmes apparaissent. Une valeur de 20000 est sûre pour pratiquement tous les scénarios et n'a aucun impact mesurable sur les performances. Documentez ce paramètre dans vos notes de configuration serveur afin que les futures migrations de serveur le préservent.

Si vous êtes un hébergeur ou un administrateur système gérant plusieurs installations PrestaShop, envisagez de définir max_input_vars = 20000 comme valeur par défaut dans vos modèles de configuration PHP. Ce seul changement élimine l'une des demandes de support les plus courantes liées à la gestion des produits PrestaShop.

Surveillez vos journaux d'erreurs après avoir effectué les modifications. Bien que la troncature de max_input_vars elle-même ne génère pas d'erreurs PHP, certaines versions de PrestaShop enregistrent des avertissements lorsqu'elles détectent que les données reçues ne correspondent pas aux données attendues. Ces entrées de journal peuvent vous aider à identifier si la limite est toujours atteinte malgré votre augmentation.