5

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

1 define('CONCATENATE_SCRIPTS', false);

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

Improve this question
6
  • 4
    Are there any errors in browser's debug tools console?
    – Rarst
    Dec 11, 2013 at 13:58
  • I had this problem once , Just need to remember what caused it - but I am 95% sure it was NOT a server problem .. Try Installing a fresh WP - no plugins , default theme and ENGLISH as language - to verify reproduction of problem.
    – krembo99
    Dec 11, 2013 at 14:08
  • 2
    Use something like HttpFox (FireFox Extension) or WireShark to look for 404s in the resources.
    – s_ha_dum
    Dec 11, 2013 at 14:29
  • Yea I checked the debug console already, no errors - will check HttpFox now, good idea
    – mashup
    Dec 11, 2013 at 18:14
  • It's definitely a server issue, tried with default install - no dice. Its either Varnish or Mod Sec
    – mashup
    Dec 11, 2013 at 18:51

4 Answers 4

Reset to default
14

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:

Improve this answer
2
  • 3
    This is such an important tip. I know we're not supposed to respond with "thanks", but honestly I cannot thank you enough for this solution!
    – Biranit Goren
    Jun 8, 2019 at 9:28
  • After trying so many solutions I tried the solution suggested by @jrsconfitto and the issue reolved. Thats for the great answer.
    – Kishor Patidar
    Nov 17, 2020 at 10:03
5

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/

Improve this answer
1
  • hey justin you are awesome until now
    – Theo
    Oct 23 at 10:58
2

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.

Improve this answer
2
  • Update 2: 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 JS
    – mashup
    Jan 8, 2014 at 6:46
  • Any chance you can give more detail about the solution? What exactly did you change in your php.ini to solve the problem?
    – Sheri Bigelow
    Dec 20, 2018 at 22:22
1

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!

Improve this answer
1
  • 1
    This question was asked referring to WP 3.4 or something. I doubt your answer is helpful for the OP now.
    – Nilambar Sharma
    Jun 5, 2019 at 4:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.