Classic editor: Visual editor is disabled when user agent is obscured by a proxy

[vmuryginIB]

user-agent checking is removing visual editor in function user_can_richedit. It took us many days to find a problem, which is described here: ​http://www.benjaminhorn.se/code/wordpress-visual-editor-not-visible-because-of-user-agent-sniffing/

It is not sensible to use user-agent as a check whether to show visual editor. Hopefully this check can be amended or removed in future WP versions.

There are various hosting environments where this check fails. Plus you would constantly need to manually add new strings over time.

We need to write plugins or theme hacks to circumvent this problem (that is after spending days of struggling to pinpoint the problem).

[SergeyBiryukov]

Introduced in [3283], changed in [4210], [4417], [5425], [18963], [19936], [20417], [20990].

[nacin]

What's the user agent that failed for you?

[azaozz]

From the post linked in the ticket:

"This usually won’t be a problem, but if you have your frontend servers behind a proxy or load balancer that strips the user agent..."

WordPress has to detect the user agent to properly output the textarea content depending on which editor is loaded first. It also doesn't make sense to load TinyMCE in browsers that don't support it.

It is possible to add an exception in user_can_richedit() for this particular case. However the user agent is used in several other places to adjust the output, most notably in wp_is_mobile(). It is not possible to make the right assumption in these cases.

[mcfedr]

Seeing similar problems because I am hosting wordpress behind Amazon CloudFront. For caching reasons there is no user-agent header and I have to patch the function to always return true.

How many browsers don't support the visual editor these days? maybe its better to remove check for user-agent and for that small percentage of users to pay the extra cost of downloading a js file and not using it.

[ChrisJDean]

+1 on @mcfedr's issue!

UA is blank or not recognized since it's "Amazon CloudFront" and therefore experience is degraded for CMS users on desktop and mobile in various ways.

Would be great to have the check removed or the ability to add/define further allowed UA's somewhere/somehow.

Affected installs for us: WP 4.6.1

[here]

Related ticket to add IE11 with new User-Agent string, https://core.trac.wordpress.org/ticket/42503

[mcfedr]

Seeing this pop up a few years later, first thought, surely, by now, the default should be to enable user_can_richedit, and only disable in a few known cases? how many people are using browsers that dont support the rich editor?

[noisysocks]

Defaulting to enabled makes sense in my mind. Most browsers support the classic visual editor. We should only disable when we know that the user's browser doesn't support the classic visual editor.

I added 29159.diff​ which makes true the default. Testing is needed to ensure that user_can_richedit:

• Returns true when browser is Edge, Chrome, etc.
• Returns true when browser is IE 11
• Returns true when user agent is something like "Amazon CloudFront"
• Returns false when browser is < IE 11
• Returns false when browser is Mobile Safari < 534

Unit tests should be added.

Note that the block editor is always enabled. This only affects users with the Classic Editor plugin.

[noisysocks]

#50483 was marked as a duplicate.