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!
Great news – I’m so glad it worked for you too! I suspect that under the hood, the Classic Editor (as it’s now known) has quite a few bugs. Maybe that’s why the WordPress team were so keen on removing TinyMCE. Still, for me, Gutenberg is not what I need and I’ll stick with the Classic Editor until I find a new content management solution.
In my case it was wp_post Auto Increment value which was unset due to heavy database import query break.
SELECT `AUTO_INCREMENT`
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = ‘Database’
AND TABLE_NAME = ‘wp_post’;
ALTER TABLE wp_posts AUTO_INCREMENT=101
Please this issue is really making me suffer. I have this theme I purchased in 2016. It works very fine when I was using shared hosting but now the only issue is it refuses to toggle from either text editor to visual….Please is there any other solution because guide did not work in my case. If you can help me troubleshoot this I will appreciate so much. Thanks.
It’s probably a plug-in conflict. I would try disabling all plugins to see if WordPress itself has the problem, or if it’s introduced with a conflict. Then enable each plugin you need and see where the issue creeps in.