-
Notifications
You must be signed in to change notification settings - Fork 4.9k
In-editor revisions (initial changes, without diffing) #74771
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
d046d05
0e3292e
1629a01
2f05405
9f60765
9c8631e
3ecd4d5
8354457
5808464
7a9d9d1
9bfdcdd
2e97e42
052b77c
c564c90
7f29dd0
b74d096
11439e3
f763d80
1c1bc1d
5e11c83
2470e93
c2faf77
b657574
071eb49
b912e87
733b8cd
cd32037
19a72dd
0dc940f
988e0c1
06baf88
70543b9
451b48a
5b81953
ee88a60
5261b01
b75955a
69b1585
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,13 +32,15 @@ const BlockSettingsMenuControlsSlot = ( { fillProps, clientIds = null } ) => { | |
| selectedClientIds, | ||
| isContentOnly, | ||
| canToggleSelectedBlocksVisibility, | ||
| canEdit, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you clarify why these canEdit changes are needed? Any performance concerns?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should not render action buttons for actions that cannot be performed. It's actually good to have a look a these, for example in the next file you'll see that the Cut action was missing |
||
| } = useSelect( | ||
| ( select ) => { | ||
| const { | ||
| getBlocksByClientId, | ||
| getBlockNamesByClientId, | ||
| getSelectedBlockClientIds, | ||
| getBlockEditingMode, | ||
| canEditBlock, | ||
| } = select( blockEditorStore ); | ||
| const ids = | ||
| clientIds !== null ? clientIds : getSelectedBlockClientIds(); | ||
|
|
@@ -52,6 +54,7 @@ const BlockSettingsMenuControlsSlot = ( { fillProps, clientIds = null } ) => { | |
| ).every( ( block ) => | ||
| hasBlockSupport( block.name, 'visibility', true ) | ||
| ), | ||
| canEdit: canEditBlock( ids[ 0 ] ), | ||
| }; | ||
| }, | ||
| [ clientIds ] | ||
|
|
@@ -105,17 +108,17 @@ const BlockSettingsMenuControlsSlot = ( { fillProps, clientIds = null } ) => { | |
| onClose={ fillProps?.onClose } | ||
| /> | ||
| ) } | ||
| { showLockButton && ( | ||
| { canEdit && showLockButton && ( | ||
| <BlockLockMenuItem | ||
| clientId={ selectedClientIds[ 0 ] } | ||
| /> | ||
| ) } | ||
| { showRenameButton && ( | ||
| { canEdit && showRenameButton && ( | ||
| <BlockRenameControl | ||
| clientId={ selectedClientIds[ 0 ] } | ||
| /> | ||
| ) } | ||
| { showVisibilityButton && ( | ||
| { canEdit && showVisibilityButton && ( | ||
| <BlockVisibilityViewportMenuItem | ||
| clientIds={ selectedClientIds } | ||
| /> | ||
|
|
@@ -127,12 +130,14 @@ const BlockSettingsMenuControlsSlot = ( { fillProps, clientIds = null } ) => { | |
| onClose={ fillProps?.onClose } | ||
| /> | ||
| ) } | ||
| { fillProps?.count === 1 && ! isContentOnly && ( | ||
| <BlockModeToggle | ||
| clientId={ fillProps?.firstBlockClientId } | ||
| onToggle={ fillProps?.onClose } | ||
| /> | ||
| ) } | ||
| { canEdit && | ||
| fillProps?.count === 1 && | ||
| ! isContentOnly && ( | ||
| <BlockModeToggle | ||
| clientId={ fillProps?.firstBlockClientId } | ||
| onToggle={ fillProps?.onClose } | ||
| /> | ||
| ) } | ||
| </MenuGroup> | ||
| ); | ||
| } } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -583,7 +583,7 @@ const PublicForwardedRichTextContainer = forwardRef( ( props, ref ) => { | |
| ref={ ref } | ||
| { ...contentProps } | ||
| dangerouslySetInnerHTML={ { | ||
| __html: valueToHTMLString( value, multiline ), | ||
| __html: valueToHTMLString( value, multiline ) || '<br>', | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is this about?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have to pad empty rich text elements such as paragraphs (just like we do for the editable version), otherwise they collapse.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change seems low level though, won't this have impact on RichText usage outside revision mode. Just want to make sure it doesn't create regressions for folks using RichText in contexts we might not have thought about.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Previews have always been the editor, but with some performance improvements. Omitting the BR padding was an oversight. |
||
| } } | ||
| /> | ||
| ); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we avoid a global style like that, also why can't we use the useDisabled that we already have in useBlockProps instead of adding yet a new behavior/hook/mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
useDisabled adds inert to all child elements, so that doesn't work. What do you want instead of a style like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see I think we should at least target a specific class of an element and not a generic modifier class like this which could impact a lot of things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I also don't like class and CSS to solve this is also because there's a huge chance for conflicts with other things. For instance, would this risk "enable" interactions on content-only patterns (or patterns in general when the experiment is on). Instead it feels the logic being tied together in useBlockProps with the block editing... feels safer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really follow. How could it interact with content-only? The preview mode is a global thing, not really per-block. I don't really understand what I'd have to add to useBlockProps, there's no related prop at the block level. Even if there was, we'd still need separate CSS to disable pointer-events on child elements within.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't test but:
These two things can conflict with each other depending on how they are implemented. Also, patterns is potentially not the only think that disable selection on blocks, we need to check all of them, block locking might be another one, block editing mode is another one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly, they are two different things. One disables everything inside block, the other disables entire blocks. It doesn't seem possible to reuse logic there.
There was actually an issue with content-only not enabling for revisions, but it was because the selector data was not present. Fixed in 4c4b009. This just selects data from an object so I'm not worried about performance.
Yes, preview mode enables pointer events, but lower specificity than content only. I can make it even lower if you want by wrapping it in :where()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we at least make this more specific like:
.block-editor-block-list__block.is-root-container.is-preview-mode