Assistendo un nostro cliente sviluppatore nella manutenzione ed ottimizzazione di un importante sito di attrezzi da bricolage realizzato di piattaforma WordPress e con l’ausilio di WooCommerce, ci siamo imbattuti per la prima volta in una richiesta quanto meno singolare: l’abilitazione delle connessioni Loopback per WordPress.
Nello specifico il plugin WooCommerce Customer / Order / Coupon Export ci richiedeva proprio questa feature abilitata a livello server al fine di poter elaborare in background l’export degli ordini.
Ad esempio, nella sezione Requirements (di cui riportiamo lo screenshot di seguito), era ben chiara ed eloquente la richiesta che il sito dovesse supportasse il “Background Processing” per automatizzare l’esportazione dei dati in background.
Il test di diagnosi del plugin anche era piuttosto chiaro, ed il responso del test era che il nostro hosting stava mancando di questa nuova feature assolutamente vitale ed indispensabile per poter far funzionare la feature dei processi in background.
Automated Exports are currently unavailable because your site does not support background processing. To use automated exports, please ask your hosting company to ensure your server has loopback connections enabled, or switch to a recommended hosting provider. In the meantime, you can process manual exports by enabling the Batch processing setting.
di cui riportiamo per brevità la rispettiva traduzione in lingua italiana:
Le esportazioni automatiche non sono attualmente disponibili perché il tuo sito non supporta l’elaborazione in background. Per utilizzare le esportazioni automatiche, chiedi alla tua società di hosting di assicurarsi che il tuo server abbia le connessioni di loopback abilitate o passa a un provider di hosting consigliato. Nel frattempo, puoi elaborare le esportazioni manuali abilitando l’impostazione Elaborazione batch.
Cercando online su Google le possibili cause e motivazioni, ci siamo trovati di fronte una miriade di risposte purtroppo errate. Seguendo quei tutorial, infatti, si arriva al massimo a risolvere delle problematiche inerenti ai Cron di WordPress, wp-cron.php e simili, che non ha niente a che vedere con la richiesta sopra.
Anche leggendo guide di Hoster statunitensi famosi e persino il supporto di WordPress si arrivano a interpretazioni completamente errate della vicenda che porta solo ad effettuare tentativi che non solo non portano a nessuna soluzione efficace, ma portano fuori strada, lasciandoci entrare in ragionamenti e tentativi che portano solo al continuo fallimento.
La soluzione per abilitare WordPress Loopback Connections
Dopo alcuni tentativi abbiamo approcciato con un pizzico di intuito tenendo in considerazione le nozioni in nostro possesso, ovvero che sui sistemi informatici, sia UNIX, che Linux che Windows, (verosimilmente tutti i sistemi operativi che dispongono di uno stack TCP/IP) quando si parla di loopback (o interfaccia di loopback) si fa sempre riferimento a quell’indirizzo 127.0.0.1 che fa riferimento al famoso localhost.
Nelle reti di computer, l’interfaccia di loopback permette la comunicazione tra processi, ma esclusivamente tra processi che sono eseguiti nella stessa macchina. Un esempio tipico di utilizzo è quello in cui si deve testare il funzionamento di un server web, realizzando una connessione con un client eseguito sulla stessa macchina su cui è eseguito anche il server.
All’interfaccia di loopback, come ad ogni altra interfaccia di rete, si deve attribuire un indirizzo IP. Secondo gli standard internazionali della Internet Engineering Task Force (IETF) l’interfaccia di loopback può utilizzare per convenzione questi indirizzi riservati:
- 127.0.0.1/32, cioè un indirizzo appartenente al blocco di indirizzi IPv4 127.0.0.0/8 secondo la notazione CIDR
- un indirizzo IPv6 0:0:0:0:0:0:0:1/128 che può essere indicato anche come ::1/128
Pertanto, abbiamo deciso di modificare la configurazione del Web Server NGINX aggiungendo oltre che l’ascolto sull’indirizzo IPv4 pubblico, anche l’ascolto sull’indirizzo di loopback 127.0.0.1
Ovvero la configurazione da questa precedente:
server {
listen 65.108.12.1:80;
server_name nomesito.it www.nomesito.it;
## redirect http to https ##
rewrite ^ https://$server_name$request_uri? permanent;
}
server {
listen 65.108.12.1:443 ssl http2;
server_name nomesito.it www.nomesito.it;
root /home/nomesito.it/htdocs/; è stata modificata come questa seguente:
server {
listen 65.108.12.1:80;
listen 127.0.0.1:80;
server_name nomesito.it www.nomesito.it;
## redirect http to https ##
rewrite ^ https://$server_name$request_uri? permanent;
}
server {
listen 65.108.12.1:443 ssl http2;
listen 127.0.0.1:443 ssl http2;
server_name nomesito.it www.nomesito.it;
root /home/nomesito.it/htdocs/; ed il test del plugin ha dato finalmente esito positivo permettendo di effettuare connessioni in loopback per avviare l’esportazione degli ordini in background.
La configurazione sopra ovviamente tiene conto dell’utilizzo del performante NGINX piuttosto che dell’obsoleto Web Server Apache; tuttavia, il concetto alla base è esattamente lo stesso e basta adattarlo alla sintassi del file di configurazione per i virtual host di Apache per ottenere lo stesso identico risultato.
Considerazioni sulle problematiche e limitazioni possibili
In merito alla procedura sopra descritta non c’è molto da dire se non che effettivamente quella sia la soluzione e che il plugin abbia iniziato a funzionare correttamente dopo l’implementazione della connessione di Loopback per WordPress, tuttavia, bisogna anche tenere in considerazione che questa operazione è stata possibile solo perché il nostro cliente disponeva presso la nostra gestione managed di un server dedicato in cui aveva la possibilità di modificare (o far modificare la configurazione) a proprio piacimento.
Un grado di libertà e un margine di manovra possibile in un ambiente dedicato ma non altrettanto possibile, ad esempio, in uno shared hosting condiviso.
Oltretutto nel nostro caso specifico in cui utilizziamo Varnish Cache, utilizziamo l’indirizzo di Loopback 127.0.0.1 per mettere in ascolto Varnish sulla porta 80 come da prassi consueta. Di fatto sebbene sia possibile cambiare l’indirizzo IP di ascolto ed anche la porta (molte configurazioni ascoltano sulla 8080 ad esempio), la consuetudine porta a considerare dai vari plugin che si interfacciano con Varnish per operazioni di PURGE della cache (vedi plugin come Varnish Purge, Proxy Purge o W3 Total Cache) l’indirizzo 127.0.0.1 e la porta 80 come indirizzo di default a cui connettersi per effettuare le operazioni di PURGE.
La necessità, dunque, di mettere in ascolto la nuova configurazione NGINX anche sul 127.0.0.1:80 ci ha portato necessariamente a dover variare l’indirizzo su cui ascoltava Varnish al nuovo 127.0.0.2 e rivedere tutte le configurazioni dei vari vhost NGINX che agisce come terminatore (per fortuna ne erano solo 4) di fare un reverse proxy sul nuovo indirizzo Varnish.
Si capisce facilmente dunque come in caso di configurazioni standardizzate o provider che utilizzano i canonici indirizzi, sia impossibile forzare la mano in autonomia per risolvere il problema aggiungendo regole alla configurazione che ovviamente non potrà funzionare.
Se anche voi che state leggendo state trovando difficoltà nell’abilitare le loopback connections per WordPress e non riuscite a trovare un fornitore di hosting accondiscendente a seguire questa guida per permettervi di risolvere la problematica aggiungendo l’indirizzo di loopback in ascolto sul vostro sito Web, contattateci pure.
