Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#45375 closed task (blessed) (fixed)

Support the richtext editing option in the block editor

Reported by: youknowriad's profile youknowriad Owned by: danielbachhuber's profile danielbachhuber
Milestone: 5.0 Priority: normal
Severity: normal Version: 5.0
Component: Editor Keywords: has-patch fixed-5.0
Focuses: Cc:

Description

Gutenberg should not be loaded if the user disables the visual editor.

Here's the corresponding Gutenberg PR

https://github.com/WordPress/gutenberg/pull/12000

Attachments (2)

rich-text-editing.patch (1.1 KB) - added by youknowriad 6 years ago.
rich-text-editing.2.patch (584 bytes) - added by youknowriad 6 years ago.

Download all attachments as: .zip

Change History (29)

#1 @ocean90
6 years ago

#45379 was marked as a duplicate.

#2 follow-up: @zodiac1978
6 years ago

Gutenberg should not be loaded if the user disables the visual editor.

I'm not sure that people expect this to happen after checking this box. *I* would expect to see a HTML/text editor now in Gutenberg (for example in the Classic bock). But not a disabled Gutenberg ...

We should at least change the text to add this changed behavior.

#3 in reply to: ↑ 2 @mkaz
6 years ago

Replying to zodiac1978:

Gutenberg should not be loaded if the user disables the visual editor.

I'm not sure that people expect this to happen after checking this box. *I* would expect to see a HTML/text editor now in Gutenberg (for example in the Classic bock). But not a disabled Gutenberg ...

We should at least change the text to add this changed behavior.

If a user wants Gutenberg in HTML mode, they can always switch within Gutenberg by selecting "Code Editor" in the Editor Settings behind the gear icon.

I think checking the user preference box to disable the visual editor is to go beyond just the editor settings.

Also this issue does not change any current user experience, it actually keeps it exactly the same. A user with that field checked will see the same editor they used previously.

#4 @zodiac1978
6 years ago

Also this issue does not change any current user experience, it actually keeps it exactly the same. A user with that field checked will see the same editor they used previously.

I understand that you really think that's true. But it isn't.

The UX is of course changing. We do tell the people that they can use the Classic Editor plugin to disable Gutenberg. I don't think they will expect that it is sufficient to just check this box.

And as a forum moderator I think of the people who don't see the relation between this "visual editor" in this sentence and Gutenberg, as these things are not commonly related. There will be many people in the forums asking why Gutenberg is not working if this will be implemented.

Just wanted to add these concerns from a support perspective here.

So please, change at least the text to something what states that this is disabling the block editor too.

#5 @pento
6 years ago

  • Milestone 5.0 deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Has GB12000 has been reverted, I'm closing this ticket. We can re-open it if a better solution comes up.

#6 @youknowriad
6 years ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

Actually the revert includes a better solution. I'll make sure to backport it I'm reopening the ticket.

#7 @zodiac1978
6 years ago

Actually the revert includes a better solution.

Hi @youknowriad - Can you please add a short explanation of the new approach, so we can discuss it here and/or give feedback. Otherwise I don't know why this ticket exists on this place.

If we need to change to Github, please share the link/place at which this issue can be discussed.

#8 @youknowriad
6 years ago

Looks like something unrelated slipped-in into the patch. Yes, I'll explain in a bit.

#9 @youknowriad
6 years ago

The patch should be correct now, if you want to test, you also need the latest patch from https://core.trac.wordpress.org/ticket/45145

The idea is that it just disables the visual editor of Gutenberg. you don't fallback to the code editor of the classic editor. You stay in Gutenberg but within the code editor.

#10 @youknowriad
6 years ago

I think the patch is trivial here. As soon as the patch from https://core.trac.wordpress.org/ticket/45145 lands, I'll commit it.

#11 @youknowriad
6 years ago

  • Component changed from General to Editor
  • Keywords has-patch added
  • Milestone set to 5.0
  • Version set to 5.0

#12 @zodiac1978
6 years ago

I'v tested this with Gutenberg 4.5.1 - works for me.

Much better than disabling the new block editor completely. 👍

But ...

The idea is that it just disables the visual editor of Gutenberg. you don't fallback to the code editor of the classic editor. You stay in Gutenberg but within the code editor.

I don't see any chance to switch to the visual editor (besides unchecking the box in settings again). Imagining the onboarding process, this seems to be a problem too. User would see the Gutenberg UI, but there is no way to convert Classic to Blocks now.

People could think this is it, or not? Is this intended? Should we better add a notice?

Wouldn't it be better to turn on the code editor in the classic block and the "Edit as HTML"-option for every block in this case? This would be for the people who want to see the code instead of the visual presentation, or not?

#13 @youknowriad
6 years ago

I don't see any chance to switch to the visual editor (besides unchecking the box in settings again). Imagining the onboarding process, this seems to be a problem too. User would see the Gutenberg UI, but there is no way to convert Classic to Blocks now.

That's what the option is for, it's not about on boarding into Gutenberg. It's a permanent option. The on-boarding is more something the classic editor plugin should address IMO.

People that want the code editor, don't want to add blocks and then edit them as HTML.

#14 @zodiac1978
6 years ago

That's what the option is for

No, it was an option for a complete different case. We are just guessing what's the best way to move on here.

it's not about on boarding into Gutenberg.

Imagine someone with "Disable the visual editor when writing" checked and this person updates to WP 5.0 - will this person expect the block editor to be disabled, the block editor not usable, because there is no option to convert to blocks or will the person expect the editor to show HTML markup like before in the current editor (Classic or blocks)?

People that want the code editor, don't want to add blocks and then edit them as HTML.

If I want to disable Gutenberg, I would install the Classic Editor plugin, that's what the callout is saying to the people. If I had checked the mentioned option I want to see markup instead of visual presentation.

Why do you think that people who had checked this option don't want to add blocks? I think this is the wrong assumption.

#15 @danielbachhuber
6 years ago

  • Owner set to danielbachhuber
  • Resolution set to fixed
  • Status changed from reopened to closed

In 43916:

Block Editor: Expose value of user_can_richedit().

In order for the Block Editor to know whether to allow visual editing, it needs to know the value of user_can_richedit().

Props youknowriad.
Fixes #45375.

#16 @danielbachhuber
6 years ago

  • Keywords fixed-5.0 added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for merge to trunk.

#17 @zodiac1978
6 years ago

Hi @danielbachhuber - how do I have to understand this? Did you cut the ongoing discussion and commited the patch although there is no decision made here and there are arguments against the latest patch?

#18 @youknowriad
6 years ago

@zodiac1978

If I want to disable Gutenberg, I would install the Classic Editor plugin, that's what the callout is saying to the people. If I had checked the mentioned option I want to see markup instead of visual presentation.

Agreed and that's what's happening with this patch.

Imagine someone with "Disable the visual editor when writing" checked and this person updates to WP 5.0 - will this person expect the block editor to be disabled, the block editor not usable, because there is no option to convert to blocks or will the person expect the editor to show HTML markup like before in the current editor (Classic or blocks)?

I expect the Gutenberg editor to show the HTML markup in the current editor of WordPress which is Gutenberg in 5.0

Why do you think that people who had checked this option don't want to add blocks? I think this is the wrong assumption.

That's a decision that has already been made in Gutenberg and that is independent from this patch. When you are in the Code editor of Gutenberg (regardless of the option in the user profile), you can't add blocks.

--

Did you try the patch? I think the patch is doing what you expect more or less. It's showing Gutenberg's code editor.

This commit is not doing anything more than just back porting something from the Gutenberg editor which was already approved and merged. We can still iterate on that but it's better to open a GitHub issue for that.

#19 @zodiac1978
6 years ago

Agreed and that's what's happening with this patch.

Yes, but with all the comment markup for the blocks. Which is risky to edit. I wouldn't want to edit this code manually. I just want to see my markup instead of visual presentation in my blocks if I checked the box - at least this would be my interpretation.

I expect the Gutenberg editor to show the HTML markup in the current editor of WordPress which is Gutenberg in 5.0

That's exactly what I say: Show me the markup, like after I switched on the "Edit as HTML" feature.

That's a decision that has already been made in Gutenberg and that is independent from this patch. When you are in the Code editor of Gutenberg (regardless of the option in the user profile), you can't add blocks.

I wouldn't show the code editor in the first place. Just show me the blocks, but with the "Edit as HTML" option enabled. Problem solved.

Did you try the patch?

Yes, sort of, like I wrote in https://core.trac.wordpress.org/ticket/45375#comment:12 I updated to Gutenberg 4.5.1 which showed me the new behavior.

We can still iterate on that but it's better to open a GitHub issue for that.

Like I wrote above, if I need to open a Github issue for it I will do this. Obviously Github is still the place to discuss things instead of Trac. Confusing, but now I know. Thanks.

#20 @youknowriad
6 years ago

I wouldn't show the code editor in the first place. Just show me the blocks, but with the "Edit as HTML" option enabled. Problem solved.

This is not possible technically as all blocks don't have this option. For example dynamic blocks don't show anything in this mode as it's only a comment.

#21 @zodiac1978
6 years ago

This is not possible technically as all blocks don't have this option.

Showing it for all blocks with this option is not possible?

#22 @youknowriad
6 years ago

Showing it for all blocks with this option is not possible?

Unfortunately not, this option is meant for static blocks essentially as it doesn't show the block demarcations (the comments surrounding the blocks) and dynamic blocks (like "recent posts", "categories"...) don't have this option.

Worth noting that third party blocks can opt-out of this option too.

#23 @youknowriad
6 years ago

Showing it for all blocks with this option is not possible?

Oh sorry I misread your comment. What will you show for the rest?

#24 @zodiac1978
6 years ago

What will you show for the rest?

Exactly what you are showing if the check box is not checked.

I think this option is mostly for people who are safe in HTML (maybe not more) and just want to be sure about there markup. To fix things like empty elements (not visible in visual mode) or avoid breaking markup through the visual editor (it sometimes "eats" markup).

If there is no markup to fix then it will be safe to just show the block IMHO.

I opened a Github issue for it:
https://github.com/WordPress/gutenberg/issues/12211

#25 follow-up: @MattyRob
6 years ago

Sorry for being a little late contributing this but the current approach and applied patches are a regression from current WordPress functionality.

With the Visual Editor disabled at the moment there is still the option to apply styling via buttons including bold and italic styling, links, lists etc - I can provide screen shots if needed.

With the current code and the Visual Editor disabled there is a very basic editor deployed still within what looks like the Gutenberg framework but without any tools to add styling as there were before.

Currently the only way I have found to restore the old functionality is with the following code added to a plugin or functions.php file in the theme:
add_filter( 'use_block_editor_for_post', '__return_false' );

Can the oldnon-visual editor be restored more fully?

#26 in reply to: ↑ 25 @knutsp
6 years ago

Replying to MattyRob:

With the Visual Editor disabled at the moment there is still the option to apply styling via buttons including bold and italic styling, links, lists etc - I can provide screen shots if needed.

With the current code and the Visual Editor disabled there is a very basic editor deployed still within what looks like the Gutenberg framework but without any tools to add styling as there were before.

Can the oldnon-visual editor be restored more fully?

Created a feature issue herehttps://github.com/WordPress/gutenberg/issues/12244.

Currently the only way I have found to restore the old functionality is with the following code added to a plugin or functions.php file in the theme:
add_filter( 'use_block_editor_for_post', '__return_false' );

Or simpler, install and activate the Classic Editor plugin. Ok for the coming years, but not a permanent solution. It also makes it troublesome to use the block editor in combination. A permanent solution is better, hopefully in core.

Last edited 6 years ago by knutsp (previous) (diff)

#27 @desrosj
6 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 44267:

Block Editor: Expose value of user_can_richedit().

In order for the Block Editor to know whether to allow visual editing, it needs to know the value of user_can_richedit().

Props youknowriad, danielbachhuber.

Merges [43916] into trunk.

Fixes #45375.

Note: See TracTickets for help on using tickets.