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

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.

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 6 years, 11 months ago by robotor.
• This reply was modified 6 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 www.ads-software.com: www.ads-software.com 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: https://www.gabfirethemes.com
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 1.6.5.2 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 www.ads-software.com community
Jetpack by WordPress.com: 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 ###
ABSPATH: /data/www/[CUSTOMER DOMAIN REMOVED]
WP_HOME: Undefined
WP_SITEURL: Undefined
WP_DEBUG: Enabled
WP_MAX_MEMORY_LIMIT: 300M
WP_DEBUG_DISPLAY: Disabled
WP_DEBUG_LOG: Disabled
SCRIPT_DEBUG: Disabled
WP_CACHE: Disabled
CONCATENATE_SCRIPTS: Undefined
COMPRESS_SCRIPTS: Undefined
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.

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.

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.

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).