The loopback request to your site failed…

For those that might’ve found this thread by luck, I first came upon the problem (and now its solution!) of not being able to use WordPress’s built in theme editor to update php files as previously able prior to version 4.9

TL;DR Sessions hanging. Urge developers to remove use of sessions. In the meantime replace session_start(); with session_start(['read_and_close' => true,]);

As part of my ongoing diagnosis, I created a fresh server with a fresh WP 4.9.7 install with just the default TwentySeventeen theme and the ‘WordPress Simple PayPal Shopping Cart Plugin’. Since I was still unable to use WP’s built in editor on php files, I installed the WP HealthCheck plugin and found that my instance was failing the loopback check, due to the ‘WordPress Simple PayPal Shopping Cart Plugin’.

After many hours of sheer determination and stubborn research, I stumbled upon this thread:

https://www.ads-software.com/support/topic/loopback-request-error-401-updates-prevented-by-disabling-wp_version_check/

Which has @decentris .htaccess file. Thinking it wouldn’t hurt to try, I copy & pasted his .htaccess code into mine, used the HealthCheck and was very surprised to see that the loopback problem was gone!

After further tinkering (commenting out each line until it broke, again), I narrowed it down to this line:

php_value session.save_path “/var/cpanel/php/sessions/ea-php56”

I then looked on my server and saw that I don’t actually have ‘/var/cpanel/php/sessions/ea-php56’ as a directory path and therefore assumed that the sessions weren’t actually being saved, as directed by the ‘php_value session.save_path’ directive. I then tried removing the path value: php_value session.save_path “” but the server simply 500 errored. I then tried some arbitrary (false) value and again it worked. However, after setting the path to an actual useable value: ‘ /var/lib/php/sessions’ it failed, again. I then checked permission and ownership, but it still kept failing.

So, knowing the issue is session related, I carried out further research and found this thread:

https://www.ads-software.com/support/topic/plugin-is-blocking-loopback-requests-in-wordpress/

At last, @isaumya had put the effort in and worked it out:

from Day 1 WP Core Team decided not to use SESSION variables inside WP for some reason. But for years developers can still user SESSION variables inside their codes with some occasional PHP Notice. But it seems from v4.9 WP core has made sure that session cannot be used inside WP. So, if you are using something like session_start() PHP function, it will throw that loopback issue.

The only solution to this is rewrite your code in such a way that to do not use SESSION in any way whatsoever.

Another WP thread: https://www.ads-software.com/support/topic/cant-edit-main-theme-php-files-after-upgrading-to-4-9/page/8/#post-9716920

And I saw that @dpsachou had correctly informed us:

Saumya Majumder discovered that the issue is with themes or plugins that use PHP Sessions.

After the session_start() command, php session hangs causing a timeout. This prevents the loopback request.

After making some tests on my own, I found out that when the session is closed with a session_write_close() command, the issue disappears, and everything is working fine again. So the real issue does not seem to be on the php session itself, but rather to the open php sessions that never close.

More research and I found these:
https://stackoverflow.com/questions/4333209/session-start-hangs
https://www.bram.us/2017/11/20/php-session-locking-how-to-prevent-blocking-requests/

Which lead me to a (temporary) cure, to use the ‘read_and_close’ option in session_start() as follows:

session_start([
    'read_and_close' => true,
]);

ref: https://php.net/manual/en/function.session-start.php

I then replaced the standard session_start(); function calls in ‘wp_shopping_cart.php’ of the offending ‘WordPress Simple PayPal Shopping Cart Plugin’ code with session_start([‘read_and_close’ => true,]); and voila, it works!

I’m still testing the full effect this might have on the ‘WordPress Simple PayPal Shopping Cart Plugin’, but thought I’d share this golden nugget after being disappointed to be told by the developers:

The setup you are suggesting is not going to be trivial. It will be a little time consuming. Unfortunately, I can’t spend that much time for free. So it is totally fine if you need to find an alternative solution for this site.

BTW – the setup being referred to above is to use a public SSH key for SFTP access – which only takes a minute or two using PuTTY KeyGen.

So, there we have it – sessions are the root cause of this loopback problem. I appreciate some servers may have more power and may respond quicker / differently to session locks / hangs than others so it might not affect everyone, but the message from WP to developers is clear: don’t use sessions!

All I can say is a massive thank you and kudos to @isaumya for working out the problem!

I hope this helps others with the same / similar problems.

• This reply was modified 6 years, 2 months ago by derrickr.
• This reply was modified 6 years, 2 months ago by derrickr.

@derrickr Glad to know it helped you. ??

Thank you @derrickr for sharing this very important information. I will mark this support thread as resolved. I will also point others running into a similar issue to this thread.

Enjoy the plugin.

Kind regards

@derrickr I want to buy you a beer or a coffee for this! Excellent work and determination. Bravo!

@bmehder Happy it helped ??

why i’m facing this error,
The loopback request to your site failed, this means features relying on them are not currently working as expected.
Error: [] cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received

@hariswaheed, can you start a new support thread. This thread is marked as resolved. You can add a reference to this thread if you like.

Thank you

• This reply was modified 5 years, 5 months ago by mbrsolution.