Conversation
Fixes #5667 See wp-includes/class-wp-editor's behavior around self::$this_tinymce: https://github.com/WordPress/WordPress/blob/176a28905041fd79c439946a4ba290a87db5991f/wp-includes/class-wp-editor.php#L360
0b21f36 to
e75be7a
Compare
|
Related: #4634
There's room for different interpretations. This PR is concerned with avoiding the total failure to load the editor described in #5667, but further steps may be:
The latter is much more aggressive. The decision hinges on the what we believe are the needs that a user expresses by disabling this setting. For instance, can it signal a stronger technical imperative (e.g., no JS execution desired?) than a simple UX choice? Is a11y a factor for those who disable it? If so, can we ensure that Gutenberg's Code view fulfills these needs, thereby eschewing the cop-out of redirecting to the classic editor? |
aduth
left a comment
There was a problem hiding this comment.
Noting further improvements to considering the setting, I agree this is a good interim fix to the immediate issue 👍
|
In considering general removals as part of #13569, it does not appear to me that something like this made its way as part of a WordPress 5.0 merge, and is unclear whether it needed to. |
Yes, the custom filter doesn't seem to be in 5.0.
Going back to the original issue, #5667, I now see that, in WP 5.0 with the Gutenberg plugin disabled, enabling user setting "disable visual editor" makes the block editor load in Code mode, with no option to switch to Visual. So it seems like the contract is honoured. I don't see any remaining action here; do you? |
Fixes #5667
See
wp-includes/class-wp-editor's behavior aroundself::$this_tinymce:https://github.com/WordPress/WordPress/blob/176a28905041fd79c439946a4ba290a87db5991f/wp-includes/class-wp-editor.php#L360
How Has This Been Tested?
Follow steps in parent issue.
Types of changes
Bug fix.
Checklist: