Conversation
|
Size Change: +390 B (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 0016ea8. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7138476850
|
| ? contextPost?.title?.rendered || | ||
| 'Back' | ||
| : undefined | ||
| } |
There was a problem hiding this comment.
To be honest, it feels like the back button shouldn't be part of the block breadcrumb but just rendered before it. (It has nothing to do with blocks)
Also, should we do the same in the post-editor, we could write that component in the editor package
| withIllustration={ true } | ||
| > | ||
| <p> | ||
| { __( 'This is where your post or page content will go.' ) } |
There was a problem hiding this comment.
Given the block is also used for custom post types, restricting this to "post" or "page" could be confusing for those templates. Also, from a user perspective, the template already appears to have content so the current wording could seem a bit odd.
What about something like:
This is where the dynamic content (for example the blocks from a specific "post" or "page") will go.
There was a problem hiding this comment.
If this placeholder is in a post-type-specific template, it could be more context-aware (and ideally would be using text provided when registering the post type).
| 'is-focus-mode': | ||
| isFocusMode || | ||
| !! editorCanvasView || | ||
| isEditingTemplate, |
There was a problem hiding this comment.
What's the reason for the change here and why it's limited only to the site editor?
|
Alternative version (WIP) for the empty post content block only here: |
What?
Why?
#55025
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast