This problem has been driving me mad. For the past 3 months or so, the visual editor in WordPress has not been showing, this means that I can only add or edit posts using raw text. Its a major hassle. I quick google search revealed that there were many people having the same problem, I thought it would be the usual thing. Enter my problem in google, click a few links, and then follow a few instructions and I should have my Visual Editor back in a few mins. No such luck…. I was without the editor for months, during that time I installed a plugin called “CKEditor for WordPress” which at least allowed me to add and edit posts.
The visual editor area is white, you can not click on it or use it for typing.
The Solution for me
There are a number of reasons why this may happen. I will go through each and every one that I have come across and show you which one actually fixed my problem.
The first thing you need to do is go and try and edit any post or create a new post. When you are on that page, if the Visual Editor is not working, click F12 (on chrome). This brings up the console menu and tells you if there are any bugs or errors on the page itself.
For me that didnt work.
There were others who had no errors shown on the page, but the visual editor was still not showing. A common issue was that the editor was simply disabled in their settings, this can be fixed by clicking on “users”, then “your profile” and making sure that the “Visual Editor : Disable the visual editor when writing” box is not ticked. If it is ticked, simply untick it, and save, and your Visual Editor will return.
When I clicked on the file that was timing out, the tinymce one, it was showing as “not cached”, this is because I use Cloudflare. For whatever reason, Cloudflare would not cache the file, and therefore could not load it for visitors. What is weird is that if I removed the query, (the bit after and including the ?) , the file would load in my browser. This made me think it must be a Cloudflare problem.
I fiddled with the settings for hours, until I cracked it.
There are several settings that work, but the easiest and simplest is this. Add a page rule with the timed out file url, including the query, and put that as the url in the page rule. For me, the url was this :
Your URL for tinymce maybe different.
For the settings for the page rule put only this “Cache Level : Ignore Query String”. Make sure this page rule is at the top, the order of the page rules matter. Within seconds, my editor was back.
One of the added complications of this problem is the cache and cookies which mean that even if you have the perfect settings on Cloudflare, it may take a day or two (without clearing the cache/cookies) for the fixed version of the website to reach you. For this reason I suggest logging to your admin in “incognito” (Chrome) and after each Cloudflare change to purge the entire cache, and clear any cookies or browser files that you have.
Other Solutions I came across
Another issue can be the permission settings on your folders. All folders need to be 755 and files 644. The only exception is that wp-config.php should be 600 so that others can’t read or write to it.
Rarely, it can be a plugin or theme acting up and creating some incompatibility, to check for this you can deactivate all plugins and see if the Visual Editor is still missing.
Even more rarely is a database change. Use PHPMyAdmin (or another database editor) to search inside your WordPress database in your “
ngto_options” table for the record called “
can_compress_scripts“. and if it has a value of “
1” for the “
option_value“, change this to “
0” and save the change. You will find your editor working again! (Note: Sometimes this record won’t even exist, so in that case you need to add it. Look for a WordPress database that does have it in order to see what you need to add.)
“Wait! Why did this happen in the first place??” you ask? Explanation:
When you update your WordPress version, it does a ONE-TIME-ONLY test of your server environment to see if it supports compressing using the “deflate” method, if it thinks it detects that your server supports this, then it will set “can_compress_scripts” “
option_value” to have a value of “1”. But it OFTEN gets this wrong! (or it just doesn’t do “deflate” correctly etc.)
Then because that test doesn’t run again, you are stuck with an auto-screwed-up WordPress install that won’t work unless you know the above secret, or unless you use the “
define('CONCATENATE_SCRIPTS', true);” directive in your “
wp-config.php” file (but using that directive disables BOTH concatenating and compressing of all scripts, which makes your site SLOW!!).
You saved my day!
No Problem 🙂
Using the PHPAdmin worked for me except the ngto_Options was named nfto_Options and instead of changing option _value from 1 to 0, I changed from 0 to 1.
THX!!!!!!!!!!! for nothing cause none of this shit fucking worked
Me too, buddy.
I rarely leave comments but after a whole week of struggle, you solved my problem, although I do not know why cloudflare is doing this, I am just glad that it solved my problem…. thanks so so so much!
I did tell cloudflare about the problem, they werent interested.
Wow, the Cloudflare solution worked like a charm!
I hate when errors like this just turn up all of a sudden. The page rule trick worked and I now have my visual editor back after several days of fiddling with various settings.
Well done, sir!
I was facing the same issue, have searched a lot but all goes in vain. Finally landed on your site and saw this solution. As I’m also using Cloudflare. After adding page rule in Cloudflare, I got my editor back to normal.
It was too frustrating for me, thank you so much for the solution.
My editor is also not working. I am not that technical. i also modified configuration.php but still not working.
How would I figure out the URL for the Tiny MCE? I just installed CloudFlare and my editor disappeared.
Just wanted to add a possible solution – i had a problem with the tinyMCE editor not showing up after a site migration. It took running across a comment about .htaccess files to compare the .htaccess from a fresh install of wordpress on the new host to the .htaccess file transferred over from the old host – there was some code in the old host’s file that was causing the issue in the new host. Deleting that code so that my transferred site’s .htaccess matched the new host’s fresh install file worked a treat! Side bonus – I now have a dev subdomain set up for future development from doing the fresh install for comparison! 🙂