17 septembre 2022

Comment activer les connexions de bouclage WordPress ?

Nous avons rencontré des plugins qui nécessitent l'activation de WordPress Loopback, voyons ce que c'est et comment l'activer.

Activer les connexions de bouclage WordPress

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.

127.0.0.1

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.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de The FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Retour en haut de page