Printful : HTTP Error 500 Internal Server Error

J’ai participé il y a quelques temps à la mise sur pieds d’une boutique en ligne connectée au service Printful. Dans l’ensemble, le processus de conception et réalisation s’est bien déroulé, de même que les premières synchronisations. Toutefois, nous avons commencé à un moment donné à observer des erreurs récurrentes, qui empêchaient la synchronisation des produits entre la boutique Printful et le plugin WooCommerce.

Gros plan sur notre douloureux, mais finalement glorieux parcours!

Printful : Comment résoudre les erreurs de synchronisation avec WooCommerce ?

Contexte

Nous avons obtenu d’assez bons résultats lors des premières synchronisations. À un moment donné cependant, sur Printful, nous avons commencé à recevoir des messages d’erreur. Tous n’étaient pas les mêmes, mais la plupart s’affichaient comme des erreurs “HTTP Error 500 Internal Server Error”

Configuration

Il est important de préciser que les démarches que nous avons utilisées se sont avérées plus ou moins efficaces, dans notre configuration spécifique. Il se pourrait que votre cas soit différent. Les solutions présentées ici ne seront donc peut-être pas efficaces pour vous.

Voici la configuration de départ de notre cas de figure:

• Hébergeur : Hostgator
• Plan : Shared / Business
• WordPress : 4.9.8
• WooCommerce : 3.4.5
• Theme : OceanWP 1.5.26 + Elementor (version gratuite, pas pro) 2.2.1
• PHP Version : 5.6.30
• MySQL Version : 5.6.39
• PHP Max Post Size : 64M
• PHP Max Input Vars : 1000
• Max Upload Size : 64M
• Memory Limit : 40M
• Permalink Structure : /%postname%/

Démarche

Les journaux (logs)

Lorsque des erreurs surviennent, et que le message que l’on obtient est plus ou moins subliminal comme “HTTP Error 500 Internal Server Error“, une des premières ressources consiste à examiner les journaux d’erreur. L’emplacement de ceux-ci pourrait varier d’un hébergeur/plan à l’autre. Dans notre cas, nous avons trouvé le fichier error.log à la racine du dossier d’installation de notre site web.

L’accès à ce fichier fut troublant : non seulement aucune information ne faisait référence à l’erreur serveur interne 500, mais en plus, nous étions envahis par une horde de messages du type :

[04-Sep-2018 10:50:08 UTC] PHP Fatal error: Out of memory (allocated 84934656) (tried to allocate 86 bytes) in /home4/thisismyhomenotyours/public_html/andtheyhadmanychildren/wp-includes/cache.php on line 534
[04-Sep-2018 05:59:15 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 05:59:17 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 05:59:21 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 06:12:02 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 06:12:05 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 06:12:08 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 17:11:03 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 17:11:06 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Sep-2018 17:11:10 America/Chicago] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0

Le Ping-Pong

Contacter le Support de Printful

Avant l’installation et l’inerconnexion des plateformes Printful et WordPress+WooCommerce, le site web se comportait bien, très bien même. Il est vrai que les premières synchronisations de produits furent correctes. Mais sachant que

• le message d’erreur apparaît sur le site de Printful,
• Printful déclare ne pas être en mesure de se connecter à notre site web,

nous nous sommes dits que les experts de Printful auraient une solution à nous donner.

Nous leur avons envoyé la configuration, ainsi que les journaux d’erreur. Ils ont promis examiner le problème, mais nous ont conseillé contacter notre hébergeur, car ils ne voyaient pas de problème de leur côté. Le souci provenait donc probablement de notre hébergement.

Contacter l’Hébergeur

Nous avons pris attache avec l’Hébergeur. Ici, même approche. On leur a fait parvenir la configuration et les logs. Les experts de Hostgator ne savaient que penser car leurs journaux n’affichaient aucune trace d’erreur 500, au point où ils nous ont demandé d’où provenaient nos captures d’écran!!!

Pour finir, ils nous ont renvoyé chez Printful, puisque c’est un plugin tiers. Ils ne pourraient pas nous aider davantage!

À ce moment là, nous ne tenions absolument pas à assister à une version courrielique du match entre Nicolas Mahut et John Isner à Wimbledon en 2010. Nous avons quitté la boucle plutôt deux fois qu’une, afin de nous en remettre à notre lumière intérieure!

php.ini

Quelques recherches sur Internet nous ont permis de constater que certaines personnes, ayant rencontré des situations semblables, avaient dû changer les paramètres de leur fichier php.ini. La plupart des informations glanées se rapportaient il est vrai à GoDaddy. Mais en l’absence de repère, nous avons décidé d’essayer cette méthode.

Dans HostGator, la méthode qui permet de changer les paramètres de php.ini est plutôt chevaleresque. Nous lui avons donc préféré la création d’un fichier .user.ini qui a l’avantage de n’impacter que le site web au sein duquel on se trouve. De plus, cette solution est élégante dans la mesure où si elle ne fonctionne pas ou pire, si elle brise notre configuration, il nous suffit de renommer ou supprimer le fichier .user.ini, et on retournerait à la case départ.

Pour y parvenir nous avons donc

• accédé par CPanel à la racine de notre site web
• créé un fichier .user.ini (bien veiller à rajouter un point au début du nom du fichier)
• inséré les valeurs suivantes :

upload_max_filesize = 256M
memory_limit = 256M
max_execution_time = 700
post_max_size = 256M
max_input_time = 700
max_input_vars = 5000
set_time_limit = 700

Ces valeurs nous ont permis d’accroître sensiblement la capacité d’envoi des fichiers par le système, ainsi que la durée des temps d’attente/traitement. En effet, nous avions l’impression que plus les produits ajoutés avaient de variations, moins nous avions de chances de réussir la synchronisation. Notre désir était donc de gonfler la capacité de PHP, afin de rendre fluide les traitements.

Nous avons commencé à obtenir quelques résultats. Toutes les synchronisations ne fonctionnaient pas, mais au moins quelques unes s’exécutaient jusqu’au bout! Nous avons cependant été contraints de jouer avec le nombre de variations de nos produits. Ainsi, nous avions réduit à un maximum de 10 variations les produits à synchroniser dans un premier temps.

Compatibilité des plugins

Lorsque plusieurs entités cohabitent ensemble, garantir la sérénité et l’harmonie n’est pas toujours chose aisée. Les plugins n’échappent pas à cette règle. En effet, il n’était pas impossible que certains plugins ne soient pas compatibles entre eux. Nous avons donc entrepris de tous les désactiver, à l’exception de WooCommerce et Printful. Puis, nous avons progressivement réinstallé les autres, en procédant à chaque fois à des synchronisations. Si la synchronisation s’effectuait normalement, alors le plugin qu’on venait de réactiver n’était pas la cause. Si ça bloquait, alors nous venions de trouver le coupable, ou du moins un des complices du crime!

Cette procédure, longue, ennuyeuse et parfois pénible, nous a mené sur la piste de Ocean Sticky Header. Quel rapport y-a-t-il entre les entêtes fixes et la synchronisation de T-Shirts? Aucune idée. Mais vu que parfois ça marchait, nous l’avons gardé en quarantaine.

À partir de là, avec en plus les paramètres du fichier .user.ini, nous sommes passés à un taux de réussite de 67% environ. Bien, mais pas encore assez selon nous.

Alibi en carton

Avec désormais près de 70% de réussite, nous avions bien avancé. Mais quelque chose nous chiffonnait toujours. En effet, nous avons constaté que même lorsque la synchronisation fonctionnait, nous obtenions toujours, dans le journal d’erreur, l’intrigante phrase :

“PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. in Unknown on line 0”.

Cela ne semblait avoir aucun rapport avec l’erreur interne 500, mais ce n’est jamais agréable d’avoir un journal d’erreurs plein, alors que tout semble bien fonctionner. Ce n’est jamais annonciateur de bonne nouvelle. Nous avons donc écumé Internet à la recherche de solutions. Plusieurs solutions nous suggéraient de modifier le fichier php.ini pour éviter ces messages. Mais comme nous l’avons signalé plus tôt, ce n’était pas vraiment envisageable. Pour ce qui est de se servir du user.ini local pour le faire, nous n’avons pas trouvé de moyen.

Cependant, un fragment de phrase a attiré notre attention : depracated. La méthode avait donc expiré (façon de parler) et été abandonnée au profit d’une autre. Cela nous a amené à examiner les versions de PHP impliquées dans l’équation. Et là, illumination!

Solution Ultime

Un tour dans les versions de PHP utilisées sur le site nous a appris que notre site utilisait PHP 5.6. Jusque-là, rien de traumatisant. WordPress n’a pas crié, WooCommerce non plus, et notre the OceanWP non plus. Donc tout est parfait.

Nous avons entrepris de passer à une version inférieure, la 5.2 en l’occurennce, puisque certaines personnes sur Internet semblaient dire qu’en rétrogradant, elles avaient parfois retrouvé un semblant de stabilité. Dans notre cas, ce fut une alerte au tsunami : WordPress, WooCommerce et un paquet d’autres plugins nous ont bien fait comprendre que pour leur survie, il était important que PHP soit au moins à la version 5.6.

Nous avons alors décidé d’essayer la version 7.0. Histoire de voir. Et nous avons vu! Disparus, éliminés, résorbés, anéantis, volatilisés, et j’en passe! Nous avons bondi à 100% de réussite!

Dans l’excitation palpable, ayant encore du mal à gérer un tel flot de succès, nous avons entrepris de remettre en liberté conditionnelle, pour bonne conduite, les quelques plugins sur lesquels nous avions encore quelques doutes. Et de manière complètement transparente, la transition s’est effectuée. Toujours 100% de réussite! Incroyable!

Nous étions tellement surpris que nous voulions tester la limite de cette nouvelle armure. Nous avons décidé de créer un produit et d’activer toutes les variations possibles, pour voir si notre configuration tiendrait la route. Et vous savez quoi? Elle l’a tenu. Un de nos produits, malgré ses 120 variations, a été synchronisé sans un gémissement!

Et le plus beau dans tout cela? C’est que le journal d’erreur a retrouvé son immaculée apparence!

Canevas

Avec le recul, il est tout à fait possible que juste passer à la version 7 eusse suffi à résoudre nos troubles. Mais au final, nous ne regrettons pas ce parcours, car il nous a permis de mieux comprendre un certain nombre de choses.

Dans une situation comme celle-là (en cas de problème de synchronisation), nous recommanderions donc de procéder de la manière suivante :

• ne pas rendre votre site web actif tant qu’il n’est pas pleinement fonctionnel : pendant les phases de test et débogage, il faut parfois désactiver certains plugins, ce qui pourrait affecter les fonctionnalités et l’apparence de votre site web.

• vérifier et ajuster au besoin la version de PHP : notre expérience semble indiquer que notre version de PHP n’était pas optimale. Pour vous éviter d’écumer la toile à la recherche de solutions miracles, peut-etre faudrait-il commencer par là! Si votre version de PHP est 5.6 ou moins, essayez donc de passer à la version 7.0 au moins.

• examiner et corriger au besoin les paramètres de PHP : la synchronisation de produits de Printful à WooCommerce peut parfois être longue et lourde, suivant la qualité des images choisie, le nombre de variations, etc. Une bonne mémoire, des délais d’attente suffisamment longs, et d’autres variables bien configurées pourront faire la différence … ou l’addition!

• limiter le nombre de variations : quelque soit la puissance de votre installation, il est clair que plus vous aurez de variations, et plus l’opération de synchronisation sera à risque. Lorsque vous créez un produit sur Printful, dans la mesure du possible, essayez de limiter les variations. Si ce n’est pas pertinent, ne les incluez pas, surtout si votre infrastructure est limitée.

• Si les problèmes persistent, il est possible que ce soit un cas d’incompatibilité entre vos plugins. Le cas échéant, tous les désactiver, à l’exception de WooCommerce et Printful, puis observer pour voir si les soucis se poursuivent. Par la suite,
  • effectuer un test de synchronisation
  • si le test fonctionne, activer un nouveau plugin et recommencer
  • si le test ne fonctionne pas, alors vous avez peut être identifié le coupable ou un des complices
    • laisser le suspect désactivé, puis continuer l’activation des autres plugins
    • trouver un plugin équivalent, ou laisser tomber la fonctionnalité

Conclusion

La mise sur pied d’une boutique basée sur l’impression à la demande s’est grandement facilitée au fil du temps et des technologies. Il ne faut cependant pas sous estimer le nombre d’intervenants et de parties prenantes. Les hébergeurs, les plugins, les versions des logiciels et des langages de programmation sont autant de facteurs qui peuvent accélérer ou ralentir, voire arrêter le processus global. Il est donc important de garder un œil ouvert sur les différentes configurations, afin d’identifier plus rapidement les causes potentielles de soucis!

Bonne impression!