Sitehealth cURL error 28

I don’t have problems using the WP API (or the WC REST API I work most frequently with) while this plugin is activated, nor did I see the cURL error. What did trigger it, specifically? I have checked the logs, or double checked with Query Monitor too, I don’t see anything like you mention unfortunately.

Have you reverted to the default theme? Are there any must use or multi-site plugins enabled?

As for the site health check, as far as I know it hooks very early, before I could hook with WP PHP Console, therefore fatal errors would at run time may not be caught anymore by this plugin, but rather by WordPress itself, which I guess is still ok. All the rest would work as before.

Hello Fulvio,

Thank you for your swift reply. Please forgive me for being a novice with WP, so some of your response is a little over my head at this time. But simply, what triggered the error:
1. In the Dashboard, I choose Tools/Site Health.
2. If WP PHP Console is Activated I see the errors as described reported as Critical Performance issues in the results pane on the Dashboard (nothing to do with the WP PHP Console interface).
3. If I Deactivate WP PHP Console the errors go away.
Further:
4. The issue was diagnosed for me by Siteground Support who progressively deactivated plugins in Troubleshooting mode.
5. This is a single site, so no multi-site plugins are enabled.

Reading your reply with what little understanding I have, it looks like you’re more ‘under the hood’, but this is all just Dashboard UI.

HTH and best regards,
Barry

I see what you mean. I visited the same page and noticed the cURL error. I am not sure if this is directly related to WP PHP Console as you can use the WP API correctly, or the Gutenberg editor with WP PHP Console active. It may just be an interaction in that page. Perhaps I can look into it in the future and see if an exclusion is possible there, if WP PHP Console is confirmed to be the issue.

I think you can still enjoy the benefits of both site health check and WP PHP Console. Please remember not to use WP PHP Console in production. The site health check may be more relevant in a production environment, probably.

Thanks for the heads up

Excellent point. I shouldn’t have had it installed on a live site. Live and learn. Thank you.

Hi,

I’m having the same issue, and I think I’ve identified part of the problem (although not the solution, unfortunately.)

derrickr’s excellent comment here explains it well: https://www.ads-software.com/support/topic/the-loopback-request-to-your-site-failed-4/page/2/#post-10662220

I then searched the plugin code and found a session_start() without a session_write_close(). It’s in Plugin.php at line 158. I tried adding the 'read_and_close' => true parameter suggested here and here, and suddenly all the errors disappeared on the Site Health page, and loopback requests magically work again. But the problem is, now the plugin doesn’t work :/ So obviously that’s not the proper solution, but I wanted to mention it here in case it’s helpful to you.

Also, there is another session_start() in Session.php at line 25, but this one doesn’t seem to be problematic, probably because it’s followed by register_shutdown_function('session_write_close'); // force saving session data if session handler is overridden.

I also spotted the following comments which seem relevant. They seem to be suggesting the use of File storage instead of Session, but I’m not entirely sure how to do that.

* Set storage for postponed response data. Storage\Session is used by default, but if you have problems with overridden session handler you should use another one. (source)

* File storage for postponed response data. Use it if session handler in your project is overridden. (source)

Hope this is at least somewhat helpful. A solution would be much appreciated! This plugin is awesome and I’d love to be able to keep using it. Thanks!

Hey @nielash

Much appreciate your digging into the plugin code and PHP Console.

Anything related to https://github.com/barbushin/php-console is dependency so I can’t edit within the plugin files, but a issue/PR needs to be logged there and propose a change that is still framework/cms/project agnostic.

Do you have cUrl/loopback request issues elsewhere on the site? I have not noticed those and I use loopback in other projects with WP PHP Console active.

If you are having this problem only on the site health check page, I guess it’s safe to add an exclusion there for WP PHP Console not to initialize on that page specifically.

I’ve kept this issue open to remind about this problem: https://github.com/unfulvio/wp-php-console/issues/19

I’ve been going back and forth around session problems between PHP Console and WordPress, so I’m not so eager to move the current handling if everything else works fine. As you noticed, just making a little change breaks WP PHP Console. In other times I had other errors appearing in WP about headers already sent or session already started, etc.

Ideally PHP Console should initialize at a different (earlier) time than plugins, so there’s a bit of compromise on how PHP Console works in WordPress.

Thanks!

Hey @nekojira thanks so much for the quick response! I understand about not being able to change certain things, and thank you for logging an issue in the github repo.

I have been seeing some related symptoms elsewhere on the site. For example my WP-Cron Events page showed this error and I’ve also received error messages like this one when trying to trigger an import job with cron.

But I’ve been playing with it a bit more and I think I may have found a solution, albeit kind of a hacky one. It looks like there is an option to use a file to store the postponed response data instead of writing it back to the session. And then we can close the session which allows the loopback to complete. And the plugin still seems to work ??

Here are the specific changes I made:

I changed line 91 of Connector.php from this:
self::$postponeStorage = new Storage\Session();
to this:
self::$postponeStorage = new Storage\File('/home/path/to/my/textfile');
(where textfile is a writeable text file)

And then I changed line 158 of Plugin.php from this:
@session_start();
to this:

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

I’m sure there’s a better way to do it but this seems to do the trick for now. Do you think it’s possible that the plugin could support file storage instead of session storage in the future? From what I read in this thread, it sounds like WP core is getting stricter about forcing plugins to not use session.

Thanks!

at some point I did try to use file storage, found this old ticket with PHP Console from 4 years ago:

https://github.com/barbushin/php-console/issues/88

I probably need to revisit some of that…