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 bit of intuition taking into consideration the notions in our possession, namely that on computer systems, both UNIX, Linux and Windows, (probably 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 allows the communication between processes, but exclusively between processes that run on the same machine. A typical example of use is that in which you have to test the functioning of a web server, making a connection with a client running on the same machine on which the server is also running.
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 room for maneuver possible in a dedicated environment but not as possible, for example, in shared shared hosting.
Moreover, in our specific case where we use Varnish Cache, we use the Loopback address 127.0.0.1 to listen to Varnish on port 80 as usual. In fact, although it is possible to change the listening IP address and also the port (many configurations listen on the 8080 for example), the custom leads to consider from the various plugins that interface with Varnish for PURGE cache operations (see plugins such as Varnish Purge, Proxy Purge or W3 Total Cache) the address 127.0.0.1 and port 80 as the default address to connect to for 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 case of standardized configurations or providers that use canonical addresses, it is impossible to force the hand independently to solve the problem by adding rules to the configuration which obviously won't 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.
