WP 4.9 Loopback error and Pods

It might help to know what you’re actually trying to edit. Are you using a custom theme? If your theme code or functions.PHP is calling something that is specifically asking for Pods to do something, that’s not Pods at fault but the theme not checking to see if the plugin is active.

Obviously, the important thing to do is get you working, so let’s focus on the changes you’re trying to make. Can you share your functions.php?

Thanks for the fast response, Jim – much appreciated.
I’m using a child of the Hueman theme. But I get the same error with the parent or with Bootstrap Basic (the only other theme installed).

I don’t think that what I’m trying to do with functions.php matters. I get the error when trying to edit a comment, or even trying to remove all its contents. I also get the error when trying to edit any other php file. It’s not an instant error message, it appears after about 2 minutes – a timeout. CSS files can be edited OK.

There’s a long topic about this problem on that first link I provided. No-one seems to be sure what’s causing the loopback timeouts that were introduced with WP 4.9. I was following the topic, hoping for a resolution, but it has now been closed due to all the “me too” posts and a stated certainty that it’s not a problem in WP core code.

So I ran the Health Check plugin as recommended and it’s pointed at Pods.

Yes, I’ve read the long topic about the problem, primarily dealing with ‘editing your theme files on the back-end’.

Honestly, editing theme files on the back-end, especially anything PHP related is never a good idea unless you know what exactly what you’re doing. Editing theme files is how you get the dreaded ‘white screen of death’, which then requires going to the server to edit them to fix it. It’s smarter to work locally or on a development server, making sure all your changes are how you’d like them and then pushing those changes to your live production server. That’s what we recommend at Pods and before doing any major updates to WordPress or Pods (or any other tightly integrated plugin like WooCommerce, etc.)

I’ve put an alert up to our developers for this loopback check from the Health Check plugin, but honestly, I can’t help you in that particular area because I think it’s an error you’re getting from the new WP Core Change to the Theme Editor and it’s not relevant to what you’re actually having an issue with; it’s also not providing the PHP error that the Debug Log or Debug settings would provide. It would help me more, to know exactly what you’re trying to do.

Did you code this child yourself? Did you configure the Pods changes and do you have any code in the theme that is calling pods without checking to see if the plugin is installed? This is what we discovered with someone else who was in that gigantic thread: they were frustrated just like you, and came to us because they weren’t getting any answers, and I asked them for what was in the two theme files that were giving errors and I was able to help them.

That’s what I’m also recommending to you; you’ve got something that is broken that is based around ‘editing php’ on the back-end and you’re using a child theme, which usually means you’ve got some custom code in there doing special work. That’s where we need to start.

Are you getting the “Unable to check back with site…” when editing comments or is that a different error? I can see the above error with anything to do with the new WordPress Editor for PHP, but it would help us troubleshoot your issue if we knew exactly what errors you’re getting, taking the ‘editor’ out of the picture. Something is going wonky in there: it’s pointing at Pods because more than likely something in the theme is calling Pods directly. It would give that kind of an error if suddenly Pods was deactivated (which is all the health-check does) and the theme was calling it directly.

I hope this helps, because we want to help get you working again ??

• This reply was modified 6 years, 12 months ago by Jim True. Reason: adding clarification for debug

Thanks again for the fast response, Jim. I am working on a development installation – my live site is still running WP 4.8.4.

I hope I’m not misleading you in what the problem is. To help clarify things, I’ve now done the following:

(1) Installed the Twenty Sixteen theme and enabled it
(2) Manually deactivated *all* plugins
(3) Edited line 2 of functions.php from /** to /** test. Almost immediately after clicking the “Update file” button I’m told File edited successfully.
(4) Reactivated the Pods plugin.
(5) Edited line 2 of functions.php again to /** test2. About 100 seconds after clicking “Update file” I get:
Unable to communicate back with site to check for fatal errors, so the PHP change was reverted. You will need to upload your PHP file change by some other means, such as by using SFTP.

I think that gets to the core of the problem. It’s nothing to do with the code in PHP files, and there are no other errors at all. As far as Pods itself goes, I’ve just got one CPT with 4 fields, a simple template, and 3 custom taxonomies.

To me, the evidence indicates a conflict between Pods and the WP 4.9+ editor which, I read, now makes loopback requests (which I don’t understand). It obviously only occurs in certain circumstances, since not everyone is having this problem.

What should I try next?

It sounds like you’re getting some debug errors that weren’t being visible before. That’s what the:

Unable to communicate back with site to check for fatal errors, so the PHP change was reverted. You will need to upload your PHP file change by some other means, such as by using SFTP.

is hiding from you. That’s the largest change they did with this new editor addition; hiding debug warnings, to prevent White Screens of Death. You were able to edit in the Theme Editor before, but they weren’t capturing and hiding the warnings from you. That’s why on Development sites, you should be running with full debug warnings on.

From most of the folks I’ve checked with who got the ‘unable to communicate…’ loop back error from the editor, it’s had to do with some debug warning that wasn’t there before. That’s what we need to see and what we can’t see as long as the editor is ‘blocking’ them.

Unfortunately, I don’t know if you enable the debugs if it will bypass their ‘editor’ loopback or not. At a minimum, to find out what’s really happening is to edit your wp_config.php to add the following:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );

You can’t do this from the Theme Editor. You need to edit it on your development server. You can find that form this location:
https://codex.www.ads-software.com/Debugging_in_WordPress

Once you do this, you should be able to actually see the errors that the Editor Loopback is hiding from you.

Just so you know I am testing on my side. I’ve just installed a blank empty WordPress 4.9.1 with Pods 2.6.1.1, Added a couple of post types and content.

Went into the Twenty Seventeen theme (it was the default) and edited the Functions.php in the same way you did above. I received no errors. Just to be on the safe side, I also flipped to Twenty Sixteen like you did above and edited the functions.php in the same way you did above. No issue or errors.

So we really need to get past the loopback error and see what the actual error is behind it with debug.

• This reply was modified 6 years, 12 months ago by Jim True.
• This reply was modified 6 years, 12 months ago by Jim True.

OK, I’ve added the recommended debug lines from https://codex.www.ads-software.com/Debugging_in_WordPress to wp-config.php. No errors appear in debug.log when I try editing functions.php, either with or without Pods enabled, or by browsing round the site etc. I can force a white screen by wrecking functions.php by editing it externally using ftp (I removed a closing bracket), and an error then appears in debug.log, so I know the debug system is working.

Thanks for trying to replicate with a similar setup – it occurs to me that it’s entirely possible that I wouldn’t get this loopback timeout error if I upgraded my live server to WP 4.9: it’s a difficult bug to pin down.

One of our developers has pretty much said the same thing on his end. He can force the error to happen, but trying to capture it is another story.

Our viewpoint: They should have implemented this better to at least give some feedback to the user and even allow override. They require the override to even let you edit the theme files in the Appearance, Editor, so you’d think they’d allow an override to the theme editor loopback.

Question: Have you been able to make the changes you want through SFTP and are you getting any errors on the site or are the only errors coming in the form of this new feature with 4.9?

No I’m not trying to make any changes at present, Jim – I apologise if I inadvertently gave you that impression. Everything is working as I want on the live site. The only errors are those related to the loopback timeout and the WP 4.9 editor on my development installation.

I can’t even recall now why I tried editing functions.php – I was probably looking at the new syntax highlighting in the editor and decided to tweak a comment, then the timeout and error message prompted me to look further, eventually leading via that other long topic to here, since the evidence indicated that Pods was the cause. As well as trying to help myself, I hoped the info I was able to provide (meagre though it was) might help in working towards a general solution. I should just add how useful Pods has been in implementing my needs for the website (a series of articles with author, topic, source, date, etc).

Thanks for your help – I don’t suppose there’s much else we can do here?

We’re realizing that most of the issues with the Editor (and the Health Check tool) are the timing of the timeouts and the lack of returning errors that are actually helpful. One of our contributing developers provided a fix to the Health Check plugin that increases the timeout value and fixes it so it captures the actual error and passes it back to the plugin. In the cases he had tested, Pods was not the issue, it was either the hosting setup or an actual theme issue (when he forced one). The plugin pointing to Pods is an erroneous error.

The error from the Editor? There’s not much we can do there; if WP Core isn’t willing to listen to suggestions, then there’s not much we can do but tell them what it should do. Our contributing developer who wrote the fix for the Health Check suggested that the Editor _should_ do the following: Try the loopback test when the editor is first loaded (and cache the result) then if that fails on the ‘working’ site it would add a checkbox saying the loopback test isn’t working and editing this file could break your site, check to confirm/override editing. The way it is now, even though you’ve already given the override that you’re okay editing the theme on the back-end, it doesn’t allow you to override at all.

I’m going to mark this ticket as resolved. There’s probably _something_ on your local that is kicking an error, but it might be all the way down at the web server logs. And thanks for thanking us for how useful Pods has been. We also have nearly instantaneous support on our Slack Chat at https://pods.io/chat/; it’s usually the best place to get quick answers.

Yes, I think this has run its course. I’ve been floundering around at the edge of my knowledge here, so I want to thank you for your patient help. I’ll keep an eye out for further developments. In the meantime I need to decide whether to be brave and update the live site to 4.9! Best wishes.

We always try to be patient; I know how hard it is to be on the other side of these kinds of issues. It’s very frustrating to see an issue and to only get everyone on the other side pointing fingers. You just want to get working again ??

What I’d do is check your configurations between Live and Development and see how they differ. If they’re on different servers, duplicate your live into a staging copy on the same hosting platform and test the update there first. Basically, the idea is to make your dev/staging area as close to production as possible so it’s easier to test updates.

I love WPEngine for this kind of thing, because they have instant staging copies. Really easy when you want to fix the theme, test updates, etc. Just make a copy to staging, update staging and if it all looks good, push staging over live.

Good luck! ??

I’ve had the same issue and in my case it was one of the plugins, “Social Share WordPress Plugin – AccessPress Social Share” to be specific – I’ve updated it to the latest version and it’s fine now.