Visual Editor Missing, Server-Side Problem, How Would You Debug It?

4 Views

I already tried all of the solutions you can find online like adding this to wp-config.php:

1 define(‘CONCATENATE_SCRIPTS’, false);

Read More

2 I also deactivated all plugins and changed the theme, still no dice

3 Verified that permissions are correct and visual editor is enabled

4 Tried replacing with other editor than TinyMCE, no dice

I suppose it is a server problem because another site on the server has the same problem.

Any suggestions how to debug it? “Add Media” works fine, so its not a JS issue or a permissions issue.

I believe it could be related to mod_sec, but I disabled it and still no dice. Not sure where to begin the debugging process. Any suggestions?

Edit: I have found the problem, but no solution yet.

The following two lines are missing in the source on my broken server – on a working server they are not missing: 

<div id="wp-content-editor-tools" class="wp-editor-tools hide-if-no-js">
    <a id="content-html" class="wp-switch-editor switch-html" onclick="switchEditors.switchto(this);">Text</a>
    <a id="content-tmce" class="wp-switch-editor switch-tmce" onclick="switchEditors.switchto(this);">Visual</a>

Update: Apparently some people had luck disabling their antivirus, see here http://wordpress.org/support/topic/htmlvisual-missing-on-341-and-342

Post Views: 4

Related posts

4 comments

  1. I had a related issue and it wasn’t solved using the above answers. I lost access to the Visual Editor in the classic editor, and was stuck in HTML. When using Gutenberg, I lost access to the visual editor, could not add blocks, and could not switch from Visual to Code tabs.

    The problem was caused by AWS CloudFront removing the UserAgent headers, which WP uses to determine whether or not visual editing is available.

    If anyone comes here and the above answers don’t help, look into your hosting solution and see if you have a similar scenario to mine.

    The fix is adjusting the way your host/AWS treats headers, like this post specifies, or you can use the following code to re-enable the flags removed by WP due to the lack of the UserAgent header:

    function richedit_wp_cloudfront () {
   add_filter('user_can_richedit','__return_true');
}

add_action( 'init', 'richedit_wp_cloudfront', 9 );

    The problem and solution are detailed in a few places:

  2. If you are using AWS and CloudFront, you need to pass the following headers:

    Host
Options
Referer
Origin
User-Agent

    You could do another behaviour and only do this when it is “wp-admin” to take advantage of Cloudfront caching for all the pages (except for admin ones).

    Also if you are using CloudFront for HTTPS and your origin is HTTP, add the following line to the start of your wp-config.php file (the Origin header should have solved this, but if it didn’t):

    $_SERVER['HTTPS'] = 'on';

    As the server is http (port 80) and you are using an AWS public certificate, you need to fool wordpress into thinking that the site is HTTPS otherwise script and css links will not load, as the links will be http and not https. WordPress is unable to determine if a Cloudfront redirection is https when it uses the function is_ssl(), so this hack fools it.

    This link has a bit of an explantion as well:

    https://jeffreyeverhart.com/2018/12/07/setup-aws-cloudfront-for-wordpress-scaling-this-blog/

  3. I forgot to add the solution. Turns out for some reason my php.ini dropped the apc segmentation and thus my entire server got fragmented and it would break JavaScript.

  4. HERE’S THE SOLUTION)

    You might already know this but if your go to your WordPress profile, there is a checkbox to ” Disable the visual editor when writing” be sure it is unchecked.

    Good luck!

Comments are closed.