Need a better experience for users when switching between Visual Editor and code editor

[BryanBarrera]

I am testing out Gutenberg and so far it is looking great. I know my way around Wordpress but this is frustrating..I cannot be the first one to come across this..

How do I get back to the visual editor? I tried cmd+alt+shift+m but it is not working for me. There is no message or menu option in top right menu that says switch back to visual editor? Can anyone help me here? Overall this experience is not the best and very frustrating.

I am using Wordpress 5.0.1. Gutenberg 4.7.0

[swissspidy]

Hi there

When the option is missing from the top right menu, it looks like you have disabled the visual editor in your user profile.

If you go to Users -> Your Profile there's a setting called "Disable the visual editor when writing" at the top. Make sure it's not checked.

[BryanBarrera]

I just checked and it is indeed not checked.

Please advise...

Thank you for the reply.

[BryanBarrera]

Very strange.

I created a new username with an admin role and I was able to now see the visual editor/code editor option. But the old username still does not see that option.

Is this a bug?

[BryanBarrera]

There should be a notification checking to see if the user does have this checkbox enabled, and if so indicate it somewhere. This will avoid frustration.. perhaps an option in the menu to the right - enable visual editor - which then redirects user to their profile. This isn't the case for the issue I am having.

I guess it isn't a widespread issue but may be isolated just to me. How ever it should be worthy of noting in future enhancements. I solved this by creating a new user and then migrating all posts to this new user so he can experience the visual editor rather than the code editor.

Very strange this happened to this user. You can consider this solved for my issue.

[jrsconfitto]

I'm experiencing the same issue on my site, but forming new user accounts doesn't get the editor working for those new accounts. I've also found two other GitHub issues that seem related to mine, to each other, and to this issue: #12760 and #12927.

(I'm trying to connect all these cases that look similar to mine, please let me know if this isn't helpful!)

[swissspidy]

If you run wp.data.select( 'core/editor' ).getEditorSettings().richEditingEnabled in your browser's JS console, what does it return?

[jrsconfitto]

If you run wp.data.select( 'core/editor' ).getEditorSettings().richEditingEnabled in your browser's JS console, what does it return?

false

[BryanBarrera]

@swissspidy - I just tried this command with the user that does have this issue. See the results below.

[swissspidy]

Thanks to both of you for confirming!

Does this still happen with WordPress 5.0.1 only without the Gutenberg plugin active?

I am asking because that option's value is coming directly from user_can_richedit() and the plugin modifies it slightly.

Now, it can also be that another plugin modifies that value in some way.

You seem to be running a few other plugins as well, so try disabling all of them to see if the issue persists. From there we can narrow things down.

If that doesn't help, please try something like this for debugging:

add_action(
  'enqueue_block_editor_assets',
  function() {
    global $wp_rich_edit, $is_chrome;

    $debug = array(
      'wp_rich_edit global' => $wp_rich_edit,
      'is_chrome global' => $is_chrome,
      'rich_editing user option' => get_user_option( 'rich_editing' ),
      'user_can_richedit' => user_can_richedit(),
      'functions hooked to user_can_richedit' => $wp_filter['user_can_richedit'],
    );

    echo '<pre>' . print_r( $debug, true ) . '</pre>';
    die();
  }
);

[jrsconfitto]

Thanks for the debugging steps, @swissspidy 👍

(I'll make a separate post about your debugging suggestions)

Does this still happen with WordPress 5.0.1 only without the Gutenberg plugin active?

My report is based on WP 5.0.1 and the Gutenberg plugin is not active (it's not installed, actually).

You seem to be running a few other plugins as well, so try disabling all of them to see if the issue persists. From there we can narrow things down.

I am running many other plugins but have been basing all of my reports here, and on the support forum, on running in troubleshooting mode with everything disabled and the default 2019 theme active. Would disabling all plugins give a different outcome than running troubleshooting mode with all plugins disabled?

[swissspidy]

I am running many other plugins but have been basing all of my reports here, and on the support forum, on running in troubleshooting mode with everything disabled and the default 2019 theme active. Would disabling all plugins give a different outcome than running troubleshooting mode with all plugins disabled?

Excellent! Troubleshooting mode should be enough.

Let me know if these debugging steps produced any helpful output. We can continue from there.

[jrsconfitto]

@swissspidy, please excuse my ignorance here, I'm new to WP development. Where do you suggest I add the action?

I suppose I'll start with the 2019 theme's functions.php file but I'm not sure this is the best location.

[swissspidy]

Yeah functions.php would work. You could also add it to a (mu-)plugin of yours or something. It's just a super hacky way to get some debug information in the editor. Please don't add it on a live site though 🙂

[jrsconfitto]

My site's live though! 😆

I'll wait until a time when traffic's typically low.

[swissspidy]

The only thing it does is breaking your editor in the admin, because of the die() in there.

You could also try this (untested):

add_action(
  'enqueue_block_editor_assets',
  function() {
    global $wp_rich_edit, $is_chrome;

    $debug = wp_json_encode( array(
      'wp_rich_edit global' => $wp_rich_edit,
      'is_chrome global' => $is_chrome,
      'rich_editing user option' => get_user_option( 'rich_editing' ),
      'user_can_richedit' => user_can_richedit(),
      'functions hooked to user_can_richedit' => $wp_filter['user_can_richedit'],
    ) );

    echo "<script>console.log( $debug );</script>";
  }
);

This shouldn't break anything and print this information in the browser's dev console.

[jrsconfitto]

Thanks!

The only thing it does is breaking your editor in the admin, because of the die() in there.

And i'm only using that theme in troubleshoot mode anyway, we have our own custom theme in production.

[jrsconfitto]

Debug test 1 results (with die) on post edit:

Array
(
    [wp_rich_edit global] => 
    [is_chrome global] => 
    [rich_editing user option] => true
    [user_can_richedit] => 
    [functions hooked to user_can_richedit] => 
)

Debug test 2 results (no die) in JS console on post edit:

{
  wp_rich_edit global: false,
  is_chrome global: false,
  rich_editing user option: "true",
  user_can_richedit: false, 
  functions hooked to user_can_richedit: null
}

They agree, so looks like the untested script was 👍 😄

[jrsconfitto]

Because I was curious, I get the same result in Edge for the 2nd debug test. The previous post was all in Chrome.

[jrsconfitto]

I have a working editor again! Woohoo 🙌

Looks like CloudFront not passing along headers is the issue here, more information in #12927 (comment) and in this reply to my support forum post.

My own post details how my host chose to fix our issue.

[jrsconfitto]

@BryanBarrera Are you using AWS? If so, I think that the solutions in #12927 should fix the behavior you're seeing.

[designsimply]

Closing and asking if you can reply here to let us know if jrconfitto's solution at #12881 (comment) does not work for you. I can re-open the issue in that case, and please include any notes about if you were able to check that headers are getting passed through properly in your setup or any other new details you think might be noteworthy. Thank you and I'm so sorry this case started out by being super frustrating. 😞

[hoangvannhandotcom]

Debug test 1 results (with die) on post edit:

Array
(
    [wp_rich_edit global] => 
    [is_chrome global] => 
    [rich_editing user option] => true
    [user_can_richedit] => 
    [functions hooked to user_can_richedit] => 
)

Debug test 2 results (no die) in JS console on post edit:

{
  wp_rich_edit global: false,
  is_chrome global: false,
  rich_editing user option: "true",
  user_can_richedit: false, 
  functions hooked to user_can_richedit: null
}

They agree, so looks like the untested script was

I have same problem and i was add code as swiss told above.
So next step is what?How todo to fixed.
The problem not yet solve?? :((

[jrsconfitto]

@hoangvannhandotcom Hi, I recommend exploring the options presented in #12881 (comment), they've helped a number of people with this issue.

[hoangvannhandotcom]

Hi! I alr add action on functions.php but, after that ? What next steps? *Thanks and Best Regard.* *Hoàng Văn Nhân* *Mobile phone: 0985 444 386* ===================== *E**mail: **vannhan87@gmail.com <thoiu792010@gmail.com>** ; Williamprime8719@gmail.com <Williamprime8719@gmail.com>* *Facebook: **https://www.facebook.com/nhanmmo <https://www.facebook.com/nhanmmo>* *Fanpage: https://www.facebook.com/AffiliateMarketingOnline2108/ <https://www.facebook.com/AffiliateMarketingOnline2108/> * Vào Th 6, 5 thg 4, 2019 vào lúc 20:52 James Sconfitto < notifications@github.com> đã viết:

…

@hoangvannhandotcom <https://github.com/hoangvannhandotcom> Hi, I recommend exploring the options presented in #12881 (comment) <#12881 (comment)>, they've helped a number of people with this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12881 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AvApbijJ1nuy9_p6KVna_hZJ2wxHBKdeks5vd1UvgaJpZM4ZT2cE> .

[hoangvannhandotcom]

@jrsconfitto
Hi!
Hi!
I alr add action on functions.php but, after that ? What next steps?
I am not WP develop.

[designsimply]

@hoangvannhandotcom if you have confirmed you have not disabled the visual editor in your profile settings, the next thing for you to do will be to check with your web host to see if they are blocking headers that the editor relies on—send them #12881 (comment) to see details about that.