How to fix the Visual Editor or Text Editor in WordPress when it’s not working

I had a weird phenomenon on a Multisite installation the other day. I can’t tell you with which update exactly it happened, as I only write a post on that site once every couple of months, but it must have been around the 4.7 or 4.8 upgrade. Here’s what was happening:

I could log into the site fine, I could display all posts in the backend fine, but editing them, or creating a new post (or page) resulted in an unresponsive editor window. Neither the Visual Editor nor the standard Text Editor wanted to accept any keyboard input. Moreover, none of the buttons could be pressed, including the Publish button.

The rest of the admin interface looked and behaved completely normal. I could even write posts from the iOS app, so fundamentally the installation wasn’t broken, just the editor part of it. Made no sense to me at all.

Things I’ve tried

I tried the usual tricks for getting rid of such a spurious affair:

• re-install WordPress manually
• disable all plugins
• use a different default theme (in fact, I’ve tried several)
• try logging in as a different user
• since this was multisite, try writing a post on another site (same issues there)
• since this was an installation managed from Plesk via the WP Toolkit, try more lax security settings

I probably tried other things, but none of it was making that editor working again. I didn’t understand what was going on.

The Solution

The solution came after extensive research, one part of which lead me to this thread in which Peter Luit explained a related problem that he could fix by defining a constant in the wp-confg.php file. I had never heard of it either:

define('CONCATENATE_SCRIPTS', false);

Turns out that this constant is enabled by default and means that all JavaScript files are loaded with a single call, rather than multiple calls to multiple files. The idea is that, if your site is healthy, and every single JavaScript file is working fine, all of them together will execute and work fine too. However, should one in the middle not work so well, then the rest of them won’t be executing, and I guess that’s what happened on my installation.

By setting this constant to false, each JavaScript file is loaded individually, resulting in more http requests to the server (potentially making the overall load time slower), but every JavaScript file can be executed individually. If one isn’t working, none of the others are impacted. Hence, now my editor is working again, however I still have at least one JavaScript file that has an issue executing. Finding which one would be the next step.

So this constant isn’t a “fix” as such, it’s part of a debug strategy. But it’s great to have my site back up and running so I can continue to write posts.

Thanks for sharing, Peter!