Table of contents of the article:
Assisting one of our developer clients in the maintenance and optimization of an important DIY tools site built on the WordPress platform and with the help of WooCommerce, we came across for the first time an at least singular request: the enabling of Loopback connections for WordPress.
Specifically, the WooCommerce Customer / Order / Coupon Export plugin required us to have this feature enabled at the server level in order to be able to process the export of orders in the background.
For example, in the Requirements section (of which we report the screenshot below), the request that the site should support the "Background Processing" to automate the export of data in the background was very clear and eloquent.
The diagnostic test of the plugin was also quite clear, and the test response was that our hosting was lacking this absolutely vital and indispensable new feature to be able to make the background processes feature work.
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.
of which we report for the sake of brevity the respective translation in Italian:
Automatic exports are not currently available because your site does not support background processing. To use automatic exports, ask your hosting company to make sure 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.
Looking online on Google for the possible causes and reasons, we were faced with a myriad of unfortunately incorrect answers. Following those tutorials, in fact, you get to the most of solving problems related to WordPress Cron, wp-cron.php and the like, which has nothing to do with the request above.
Even reading guides of famous American Hoster and even WordPress support we arrive at completely wrong interpretations of the story that leads only to attempts that not only do not lead to any effective solution, but lead us astray, letting us enter into reasoning and attempts that lead only to continuous failure.
The solution to enable WordPress Loopback Connections
After a few attempts we approached with a pinch of intuition taking into account the notions in our possession, that is, that on computer systems, be they UNIX, Linux or Windows, (presumably all operating systems that have a TCP/IP stack) when we talk about loopback (or loopback interface) we always refer to that address 127.0.0.1 which refers to the famous localhost.
In computer networks, the loopback interface allows communication between processes , but only between processes running on the same machine. A typical use case is to test the operation of a web server by establishing a connection with a client running on the same machine as the server.
An IP address must be assigned to the loopback interface, like any other network interface. According to the international standards of the Internet Engineering Task Force (IETF), the loopback interface can use these reserved addresses by convention:
- 127.0.0.1/32, i.e. an address belonging to the IPv4 address block 127.0.0.0/8 according to the CIDR notation
- an IPv6 address 0: 0: 0: 0: 0: 0: 0: 1/128 which may also be referred to as :: 1/128
Therefore, we have decided to modify the configuration of the NGINX Web Server by adding not only listening on the public IPv4 address, but also listening on the loopback address 127.0.0.1
That is the configuration from this previous one:
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/; has been modified as follows:
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/; and the plugin test finally gave a positive result allowing you to make loopback connections to start exporting orders in the background.
The above configuration obviously takes into account the use of the performing NGINX rather than the obsolete Apache Web Server; however, the concept behind it is exactly the same and you just need to adapt it to the syntax of the configuration file for Apache virtual hosts to get the exact same result.
Considerations on possible problems and limitations
Regarding the procedure described above there is not much to say except that indeed that is the solution and that the plugin has started to work correctly after the implementation of the Loopback connection for WordPress, however, it must also be taken into account that this this was possible only because our client had a dedicated server in our managed management where he could modify (or have the configuration changed) as he pleased.
A degree of freedom and leeway that is possible in a dedicated environment but not as possible, for example, in shared hosting.
Furthermore, in our specific case where we use Varnish Cache, we use the Loopback address 127.0.0.1 to make Varnish listen on port 80, as is standard practice. In fact, although it is possible to change the listening IP address and even the port (many configurations listen on 8080, for example), customarily leads the various plugins that interface with Varnish for cache purge operations (see plugins like Varnish Purge, Proxy Purge, or W3 Total Cache) to consider the address 127.0.0.1 and port 80 as the default address to connect to for performing purge operations.
The need, therefore, to listen to the new NGINX configuration also on 127.0.0.1:80 necessarily led us to have to change the address on which Varnish listened to the new 127.0.0.2 and review all the configurations of the various NGINX vhost that acts as terminator (luckily there were only 4) to reverse proxy the new Varnish address.
It is therefore easy to understand how, in the case of standardized configurations or providers that use canonical addresses, it is impossible to force the problem independently by adding rules to the configuration that obviously will not work.
If you, who are reading this, are also finding it difficult to enable loopback connections for WordPress and cannot find a condescending hosting provider to follow this guide to allow you to solve the problem by adding the listening loopback address on your website, feel free to contact us.
