Support » Fixing WordPress » WordPress 4.9.x: Editing Themes/Plugins (Unable to communicate error) temp fixes

  • Ever since WordPress 4.9 (and 4.9.1) have come out, I’ve seen multiple complaints about people getting the following error message, when trying to use WP Admin’s Plugin and/or Theme Editors:

    WordPress editor 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.

    WP announced changes to Theme/Plugin editors in version 4.9.

    I installed the WordPress Health Checker, and did the whole troubleshooting thing on one of our customer sites. I was unable to identify any plugin that would cause a conflict with the known session_start() issue outlined in this bug report.

    A bit further down, I did see someone recommend that two files be replaced inside the wp-admin file folder (wp-admin/theme-editor.php and wp-admin/includes/file.php). I took it a step further and replaced wp-admin/plugin-editor.php, as well… all from the WordPress 4.8.3 release.

    While I know this is absolutely not the preferred way to “fix” this issue, I am happy to report that by replacing these three files with ones from 4.8.3, the error message has gone away.

    The WordPress Team needs to get this issue addressed, and the issue affecting the “loopback” issue, as identified in the Health Checker:

    The loopback request to your site took too long to complete, this may prevent WP_Cron from working, along with theme and plugin editors.

    Result from testing without any plugins active: The loopback request to your site took too long to complete, this may prevent WP_Cron from working, along with theme and plugin editors.

    There’s a separate manual workaround available for that (WP Cron, and having it run at the server level), but that’s for another topic, for another day.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Moderator Steven Stern (sterndata)


    Forum Moderator & Support Team Volunteer

    1. Hacking core is a really, really, really (really!) bad idea.

    2. It seems to me that if you’re one of the edge cases where the prior debugging has not worked, you’d be doing the community a service by helping figure out why this isn’t working for you, thus leading to a fix, than by avoiding the problem with a hack.

    Moderator Marius L. J.


    Hi there,

    So I’d love to look into this, you mentioned having the health check plugin, would you be so kind as to post the output from the Debug tab (at the top there’s a button that will let you copy things into the forums in a formatted manner).

    I’d also love to know who you are hosting your site with, what kind of hosting plan you are on (they often have various tiers, some even have specialized solutions for WordPress hosting), and lastly, if possible, I’d love to know the URL of your site if possible, as it often helps identify things faster if it’s a host whom we communicate with regularly that can give us more information about specific server configurations but would need to know the domain name to identify which host the site is then on.

    I’m going to try this – nothing else works for me either. And that’s on a server with plenty of wordpress sites running flawlessly until the update.

    WordPress 4.9.x is simply broken.

    • This reply was modified 2 years, 11 months ago by robotor.
    • This reply was modified 2 years, 11 months ago by robotor.

    @robotor, let me know if you’ve had the same success that I did. But definitely pay attention to this thread, please. If we’re able to help find a fix, I will come back here and confirm/share.

    @sterndata, believe me, it’s not my first choice to replace specific files in order to get a “bug” to go away. When it’s a fairly high profile sports site, though, I had to do what was needed in order to get the customer’s functionality back into place, especially since the team this site covers is competing for a national championship in less than two weeks.

    Trust me, Steve, I’d love to help be a part of the permanent solution here. I actually did my part in contributing towards bug resolutions that affected WordPress MultiSite (I actually was one of the first to cross-relate two separate bug reports as being hand in hand). The fix was put in for 4.2.4 and 4.3. This was within my second month of working with WordPress, by the way.

    This is why I’m going to do what Marius requested. 🙂

    @clorith, debug info posted below.

    I actually work for the hosting provider. We’re not just a WordPress hosting provider, we maintain over 175 WordPress sites, plus actively develop sites for customers.

    I would rather not share this customer’s domain/URL publicly (as noted below in the blockquoted text), however, I can absolutely work with you directly to provide that information. Let me know how we can get connected, please.

    As far as the hosting platform… we really only use two types of configs. A standalone WordPress system (NginX, Apache, PHP on the server, MySQL on a separate server), or if they’re a large site like this particular customer, Load Balancer runs NginX, four Apache and PHP servers with a separate MySQL DB.

    This customer that I’ve worked on today, has the multi-web server front end.

    I have a personal site that is also running 4.9.1, but running on the NAP combined single standalone config, and I don’t have any problems with the theme/plugin editor.

    In addition to being one of the WP Devs, I’m also one of the server administrators (and DNS/domain guru). We’re not WP Engines, but Richweb’s not a small “fish”, when it comes to WordPress.

    ### WordPress ###
    Version: 4.9.1
    Language: en_US
    Permalink structure: /%year%/%monthnum%/%day%/%postname%/
    Is this site using HTTPS?: Yes
    Can anyone register on this site?: No
    Default comment status: closed
    Is this a multisite?: No
    User Count: 10
    Communication with is reachable
    Create loopback requests: The loopback request to your site took too long to complete, this may prevent WP_Cron from working, along with theme and plugin editors.

    ### Active theme ###
    Name: transcript
    Version: 2.7
    Author: Gabfire Themes
    Author website:
    Parent theme: Not a child theme
    Supported theme features: widgets, automatic-feed-links, menus, custom-background, post-thumbnails

    ### Other themes (3) ###
    transcript (transcript): version 2.0.1 by Gabfire Themes
    Twenty Fifteen (twentyfifteen): version 1.9 by the WordPress team
    Twenty Fourteen (twentyfourteen): version 2.1 by the WordPress team

    ### Active Plugins (15) ###
    Advanced Custom Fields: version 4.4.12 by Elliot Condon
    Advanced Most Recent Posts Mod: version by Kailey Lampert
    Akismet Anti-Spam: version 4.0.2 by Automattic
    Change Author: version 1.3 by Martin Teley
    Countdown Pro Wpdevart: version 10.0 by wpdevart
    Facebook Comments Plugin: version 2.3.6 by talspotim
    Gabfire Widget Pack: version 1.4.13 by Gabfire Themes
    Google XML Sitemaps: version 4.0.9 by Arne Brachhold
    Health Check: version 0.7.0 by The community
    Jetpack by version 5.6.1 by Automattic
    Mobile Theme Ads for Jetpack: version 1.2.1 by Jeremy Herve
    Richweb WP Lockdown: version 2.6 by Jordan Burch, Jacob Dunn & Doug Hazard
    Simple Tags: version 2.4.7 by Amaury BALMER
    Tapatalk for WordPress: version 1.4.0 by Tapatalk
    TinyMCE Advanced: version 4.6.7 by Andrew Ozz

    ### Inactive Plugins (3) ###
    Google AdSense: version 1.2.1 by Google
    vBulletin lateset threads comments – WordPress Plugin: version 0.1 by Arfan
    WP Maintenance Mode: version 2.0.9 by Designmodo

    ### Server ###
    Server architecture: Linux 3.16.0-4-686-pae i686
    PHP Version: 5.6.30-0+deb8u1
    PHP SAPI: apache2handler
    PHP max input variables: 1500
    PHP time limit: 90
    PHP memory limit: 300M
    Upload max filesize: 32M
    PHP post max size: 32M
    cURL Version: 7.38.0 OpenSSL/1.0.1t
    SUHOSIN installed: No
    Is the Imagick library available: Yes

    ### Database ###
    Extension: mysqli
    Server version: 5.5.5-10.2.8-MariaDB-log
    Client version: 5.5.54
    Database prefix: wp_

    ### WordPress constants ###
    WP_HOME: Undefined
    WP_SITEURL: Undefined
    WP_DEBUG: Enabled
    WP_DEBUG_DISPLAY: Disabled
    WP_DEBUG_LOG: Disabled
    SCRIPT_DEBUG: Disabled
    WP_CACHE: Disabled
    COMPRESS_CSS: Undefined
    WP_LOCAL_DEV: Undefined

    ### Filesystem permissions ###
    The main WordPress directory: Not writable
    The wp-content directory: Not writable
    The uploads directory: Writable
    The plugins directory: Not writable
    The themes directory: Not writable
    The Must Use Plugins directory: Not writable

    Note on File Permissions: We (Richweb) have a security plugin that “locks” / “unlocks” the site, which allows files/folders to be writeable. Every customer can manage this via their WP Admin interface. Sites are locked when not in active development/updating status.

    Moderator Marius L. J.


    I’m curious about that loadbalancer, as we’ve eyed those for a bit now, how is yours set up?

    Is it set with identification so you end up on the same server instance as your existing request?

    Also does it run any kind of WAF that might be blocking things, generally we’d expect at least a response even behind a loadbalancer but in your case it just times out which has me a bit puzzled, and are you running mod_secuity?

    I know it’s a lot of questions, but honestly so far we’ve been able to knock it down to plugin or theme issues in every situation but one (not counting this thread), so that leaves many potential doors open and it’s hard to know which rabbit hole jump down 🙂
    Thank you for taking your time to work through it with us though, it is truly appreciated!

    On our network, the load balancer servers as the “entry point” for incoming http requests and routes it to one of the front end servers. The LBs also run NginX, which serves the static content (and caches it), almost in a CDN style format. It passes all Apache and PHP requests to the web servers themselves. No WAF (we have firewalls situated with all the networking/routing stuff, however, we don’t filter legitimate web requests (in or out).

    As far as how the Apache/PHP requests are handled, some of our customers keep their visitors on the same server for X amount of time, while others bounce them around, each page they visit (this is discouraged, due to potential problems, but allows quicker response times in case one of the web servers is offline for any reason).

    For this particular customer, we’re keeping the visitor on the same server for 20 minutes, I believe. There’s four webservers in the mix.

    I know that we do take advantage of PHP’s OpCaching, but as I noted, I don’t have this issue on a standalone NginX, Apache, PHP server.

    I just tested this on another site, running WordPress with a LB/NginX server and two front end servers, and can make the changes without any error message. Similar “server jumps” as the first customer above.

    I also installed the Health Checker on this other customer site. Loopback comes through juuuuuust fine. “The loopback request to your site completed successfully.”

    I need to clarify one point in my original post… when I was doing the troubleshooting, I enabled the plugins, one by one, in hopes that I could get the error message. I worked through getting all the plugins enabled, and still didn’t get that error message. When I exited out of troubleshooting (with the standard plugin configs enabled), I received that error message.

    No, we don’t use mod_security, due to problems we’ve noticed on several configs.

    Moderator Marius L. J.


    OK so did I read this wrong that you enabled Troubleshooting Mode on the health check plugin, and the loopback error went away? But when you left the troubleshooting mode, they returned. And you were also unable to get the error when enabling all plugins and still in troubleshooting mode?

    If I understood the above correctly, did you also test the theme, because it is reverted to a default theme during troubleshooting mode as well.

    @clorith, your summary is correct. Excellent catch on the theme question. Confirmed that when I switch to the transcript Gabfire Theme, I get the error. I do not get it on the default theme.

    I had to temporarily restore the three files I replaced with 4.8.3 files back with the 4.9.1 files to recreate the error.

    I can confirm, again, that the theme itself (“transcript” by Gabfire Themess) is the “instigator” here.

    FYI, I did a recursive search on “session” and “session_start” on that theme. No instances of that were found.

    Moderator Marius L. J.


    We only know that incorrect session usage is one possible cause of the issues, so that’s fine (you can also swap between the active theme and a default theme using the health checker, for future reference 🙂 ).

    I’m not familiar with the theme in question, but I’d suggest reaching out to your theme developer here and telling them they are doing something wrong so that they can correct the problem on their end.

    @clorith, thank you for helping me narrow down the culprit. I’ll let my customer know the results of the findings (The theme developer has not released an update, as of yet, so the timing might be good here).

    If you’d like, I can also get you a copy of the theme itself. For now, I’ve got a temp fix in place (noted above).

    To everyone else, again, swapping files with an older version of WordPress should be your absolute last resort in this situation.

    Just a quick update… after some frustration with not being able to reach @gabfire Themes, I was successful in alerting them to this issue with their Transcript theme.

    Between Gabfire and @clorith, I’m a little more confident that they’ll be able to track down the issue indicated in this thread. Gabfire, please do respond to this thread with what changes you made. This is an issue that’s been hard to track down for WordPress Developers (there’s no real commonality right now… so anything that can be shared will only benefit the community as a whole).

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘WordPress 4.9.x: Editing Themes/Plugins (Unable to communicate error) temp fixes’ is closed to new replies.