En assistant l'un de nos clients développeurs dans la maintenance et l'optimisation d'un important site d'outils de bricolage construit sur la plateforme WordPress et avec l'aide de WooCommerce, nous sommes tombés pour la première fois sur une demande au moins singulière : l'activation des connexions Loopback pour WordPress.
Plus précisément, le plugin WooCommerce Customer / Order / Coupon Export nous obligeait à activer cette fonctionnalité au niveau du serveur afin de pouvoir traiter l'exportation des commandes en arrière-plan.
Par exemple, dans la section Exigences (dont nous rapportons la capture d'écran ci-dessous), la demande que le site prenne en charge le "Traitement en arrière-plan" pour automatiser l'exportation des données en arrière-plan était très claire et éloquente.
Le test de diagnostic du plugin était également assez clair, et la réponse du test était que notre hébergement manquait de cette nouvelle fonctionnalité absolument vitale et indispensable pour pouvoir faire fonctionner la fonctionnalité des processus en arrière-plan.
Les exportations automatisées ne sont actuellement pas disponibles car votre site ne prend pas en charge le traitement en arrière-plan. Pour utiliser les exportations automatisées, veuillez demander à votre société d'hébergement de vous assurer que les connexions en boucle sont activées sur votre serveur ou passez à un fournisseur d'hébergement recommandé. En attendant, vous pouvez traiter les exportations manuelles en activant le paramètre de traitement par lots.
dont nous rapportons par souci de brièveté la traduction respective en italien :
Les exportations automatiques ne sont pas disponibles actuellement, car votre site ne prend pas en charge le traitement en arrière-plan. Pour utiliser les exportations automatiques, demandez à votre société d'hébergement de s'assurer que les connexions en boucle sont activées sur votre serveur ou passez à un fournisseur d'hébergement recommandé. En attendant, vous pouvez traiter les exportations manuelles en activant le paramètre Traitement par lots.
En cherchant en ligne sur Google les causes et les raisons possibles, nous avons été confrontés à une myriade de réponses malheureusement incorrectes. En suivant ces tutoriels, en fait, vous obtenez le maximum de résolution de problèmes liés à WordPress Cron, wp-cron.php et autres, ce qui n'a rien à voir avec la demande ci-dessus.
Même en lisant les guides du célèbre hébergeur américain et même le support WordPress, nous arrivons à des interprétations complètement fausses de l'histoire qui ne conduisent qu'à des tentatives qui non seulement ne conduisent à aucune solution efficace, mais nous égarent, nous laissant entrer dans des raisonnements et des tentatives qui mènent seulement à un échec continu.
La solution pour activer WordPress Loopback Connections
Après quelques tentatives, nous avons abordé avec un peu d'intuition en tenant compte des notions en notre possession, à savoir celle sur les systèmes informatiques, à la fois UNIX, Linux et Windows, (probablement tous les systèmes d'exploitation qui ont une pile TCP / IP) lorsque nous parlons de bouclage (ou d'interface de bouclage), nous nous référons toujours à cette adresse 127.0.0.1 qui fait référence au fameux localhost.
Dans les réseaux informatiques, le loopback permet à l' communication entre processus, mais exclusivement entre des processus qui s'exécutent sur la même machine. Un exemple typique d'utilisation est celui dans lequel vous devez tester le fonctionnement d'un serveur Web, en établissant une connexion avec un client s'exécutant sur la même machine sur laquelle le serveur s'exécute également.
Une adresse IP doit être attribuée à l'interface de bouclage, comme toute autre interface réseau. Selon les normes internationales de l'Internet Engineering Task Force (IETF), l'interface de bouclage peut utiliser ces adresses réservées par convention :
- 127.0.0.1/32, soit une adresse appartenant au bloc d'adresses IPv4 127.0.0.0/8 selon la notation CIDR
- une adresse IPv6 0 : 0 : 0 : 0 : 0 : 0 : 0 : 1/128 qui peut également être appelée :: 1/128
Par conséquent, nous avons décidé de modifier la configuration du serveur Web NGINX en ajoutant non seulement l'écoute sur l'adresse IPv4 publique, mais également l'écoute sur l'adresse de bouclage 127.0.0.1
C'est la configuration de ce précédent:
serveur {écouter 65.108.12.1:80 ; nom_serveur nomesito.it www.nomesito.it ; ## rediriger http vers https ## réécrire ^ https : // $ nom_serveur $ uri_demande ? permanent; } serveur {écouter 65.108.12.1:443 ssl http2 ; nom_serveur nomesito.it www.nomesito.it ; racine /home/nomesito.it/htdocs/; a été modifié comme suit :
serveur {écouter 65.108.12.1:80 ; écouter 127.0.0.1:80 ; nom_serveur nomesito.it www.nomesito.it ; ## rediriger http vers https ## réécrire ^ https : // $ nom_serveur $ uri_demande ? permanent; } serveur {écouter 65.108.12.1:443 ssl http2 ; écouter 127.0.0.1:443 ssl http2 ; nom_serveur nomesito.it www.nomesito.it ; racine /home/nomesito.it/htdocs/; et le test du plugin a finalement donné un résultat positif vous permettant d'établir des connexions en boucle pour commencer à exporter des commandes en arrière-plan.
La configuration ci-dessus tient évidemment compte de l'utilisation du NGINX performant plutôt que du serveur Web Apache obsolète ; cependant, le concept sous-jacent est exactement le même et il vous suffit de l'adapter à la syntaxe du fichier de configuration des hôtes virtuels Apache pour obtenir exactement le même résultat.
Considérations sur les problèmes et limites possibles
Concernant la procédure décrite ci-dessus il n'y a pas grand chose à dire si ce n'est qu'effectivement c'est la solution et que le plugin a commencé à fonctionner correctement après la mise en place de la connexion Loopback pour WordPress, cependant, il faut aussi tenir compte du fait que cela a été possible uniquement parce que notre client disposait d'un serveur dédié dans notre infogérance où il pouvait modifier (ou faire changer la configuration) à sa guise.
Un degré de liberté et de marge de manœuvre possible dans un environnement dédié mais pas possible, par exemple, dans l'hébergement mutualisé mutualisé.
De plus, dans notre cas spécifique où nous utilisons Varnish Cache, nous utilisons l'adresse Loopback 127.0.0.1 pour écouter Varnish sur le port 80 comme d'habitude. En effet, bien qu'il soit possible de changer l'adresse IP d'écoute et aussi le port (de nombreuses configurations écoutent sur le 8080 par exemple), la coutume conduit à considérer parmi les différents plugins qui s'interfacent avec Varnish pour les opérations de cache PURGE (voir les plugins tels que Varnish Purge, Proxy Purge ou W3 Total Cache) l'adresse 127.0.0.1 et le port 80 comme adresse par défaut auquel se connecter pour les opérations PURGE.
La nécessité donc d'écouter la nouvelle configuration NGINX également sur 127.0.0.1:80 nous a forcément amené à devoir changer l'adresse sur laquelle Varnish écoutait la nouvelle 127.0.0.2 et revoir toutes les configurations des différents vhost NGINX qui agit comme terminateur (heureusement il n'y en avait que 4) pour inverser la nouvelle adresse Varnish.
Il est donc facile de comprendre comment en cas de configurations standardisées ou de fournisseurs utilisant des adresses canoniques, il est impossible de forcer la main indépendamment pour résoudre le problème en ajoutant des règles à la configuration qui évidemment ne fonctionnera pas.
Si vous, qui lisez ceci, avez également du mal à activer les connexions de bouclage pour WordPress et que vous ne trouvez pas d'hébergeur condescendant pour suivre ce guide pour vous permettre de résoudre le problème en ajoutant l'adresse de bouclage d'écoute sur votre site Web, n'hésitez pas à Nous contacter.
