17 September 2022

How to Enable WordPress Loopback Connections?

We have come across some plugins that require WordPress Loopback to be enabled, let's see what it is and how to enable it.

Enable WordPress Loopback Connections

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.

127.0.0.1

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.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

JUST A MOMENT !

Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top