Cloudfront dynamic content delivery compatibility: Visual editor breaks

I have exactly the same problem. It took me ages to figure out what the problem was. I tried enabling/disabling all plugins and all the other options when you google ‘no visual editor wp’.

I ended up installing a fresh WordPress installation of a fresh EC2 instance, worked perfectly with our current theme. But when I put Cloudfront in front of it, the visual editor breaks…

I suspect it has something to do with domains and redirects. When you use Cloudfront, you have to add a CNAME in your DNS records that point to the Cloudfront url, in Cloudfront you take the ec2 url as source and configure that all requests, cookies and url parameters should be forwarded.

I’ve enabled logging in WordPress, Apache and Cloudfront, but I don’t see any errors or warnings about this. Anyone?

Tech support from AWS tried to reproduce the issue but apparently could not. I’m glad there’s someone else out there experiencing it besides me!

Out of curiosity, what AMI did you base your fresh EC2 instance on?

Hi,

I contacted AWS support and they were able to reproduce the problem.

Here is the reason why:

I have been able to successfully reproduce the issue with a WordPress site running on an EC2 instance sitting behind an ELB and accessible through a CloudFront distribution.
I have also found the reasoning behind this. The answer lies with the modification of the User-Agent HTTP header that goes through CloudFront. CloudFront essentially modifies the User-Agent header to: Amazon CloudFront.
The visual WYSIWYG editor is only made available based on the User-Agent header and since WordPress does not anticipate the User-Agent to be ‘Amazon CloudFront’, WordPress disables the visual editor.
The exact function that accomplishes this is located in wordpress/wp-includes/general-template.php file:
function user_can_richedit() {
global $wp_rich_edit, $is_gecko, $is_opera, $is_safari, $is_chrome, $is_IE;

if ( !isset($wp_rich_edit) ) {
$wp_rich_edit = false;

if ( get_user_option( ‘rich_editing’ ) == ‘true’ || ! is_user_logged_in() ) { // default to ‘true’ for logged out users
if ( $is_safari ) {
$wp_rich_edit = ! wp_is_mobile() || ( preg_match( ‘!AppleWebKit/(\d+)!’, $_SERVER[‘HTTP_USER_AGENT’], $match ) && intval( $match[1] ) >= 534 );
} elseif ( $is_gecko || $is_chrome || $is_IE || ( $is_opera && !wp_is_mobile() ) ) {
$wp_rich_edit = true;
}
}
}
/**
* Filter whether the user can access the rich (Visual) editor.
*
* @since 2.1.0
*
* @param bool $wp_rich_edit Whether the user can access to the rich (Visual) editor.
*/
return apply_filters( ‘user_can_richedit’, $wp_rich_edit );
}

Once I modified the function above to have the wp_rich_edit variable to always evaluate to true, I was able to see the Visual Editor just fine through CloudFront. However, I would suggest that you modify the above code to anticipate that the $_SERVER[‘HTTP_USER_AGENT’] could be ‘Amazon CloudFront’ and then test the functionality of WordPress editor.

WordPress needs to be updated to support CloudFront as a user-agent or there needs to be a way to force it to always use the Visual Editor.

How did you configure WordPress to create “cachable” pages and posts which can be cached by CloudFront?