-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Block Library: Implement Post block and Post blocks editing. #19572
Conversation
function PostPreview() { | ||
const [ blocks ] = useEntityBlockEditor( 'postType', 'post' ); | ||
return ( | ||
<div className="wp-block-post__placeholder-preview"> |
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.
Two accessibility-related questions:
- Is this a preview similar to a full post preview one can invoke from the top toolbar? If so, this would need a role="document" so screen readers that invoke a virtual reading mode can be sure to get this even if the surrounding controls would normally cause it to be in focus/direct interaction mode.
- Should this be tabable via the keyboard? If so, it would also need tabindex="0" or a similar mechanism to make it focusable so keyboard users can reach it.
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.
- No.
- No.
It's a small preview of the post with the input's current ID.
@WordPress/gutenberg-core We should review this soon. |
"category": "layout", | ||
"context": { | ||
"postType": "core/post", | ||
"postId": "core/post" |
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.
Again, I don't think we should target blocks explicitly here instead of should have "context names". What happens if I want to build an alternative post block with an alternative UI to select posts.
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.
You filter the children you want to support.
Should the introduction of the "post" block be making all the other "post-" blocks children of it? |
No, I would advise against that, see #19685 (comment) and the rest of the thread on that point. |
I'm not sure that's talking about the same thing. I don't mean parent as "provider of context" but in terms of reducing proliferation of blocks in the global inserter by restricting insertion to the inner blocks of the parent ( |
Oh yeah, we can use the values of the children's |
Going to rebase. |
Ooh, the context-related changes to |
I think I'll have to leave this rebase to you @epiqueras, since you clearly have a better idea of how you want block contexts to work, and how to carry the changes from |
We don't need to rebase everything to review it. |
Would be great to rebase this now, @epiqueras. |
1101065
to
afbe57b
Compare
Done |
afbe57b
to
0e7843c
Compare
Size Change: +965 B (0%) Total Size: 890 kB
ℹ️ View Unchanged
|
Regarding #19572 (comment), to me it feels like the "Post" block would ideally never be surfaced to the end-user through the UI. For the purposes of testing this pull request, making it available helps. Ultimately, I'd imagine at the least we'd want |
0e7843c
to
5238269
Compare
…eading from providers.
e.g. Full-site editing experiment disabled, so "post" block not available
5238269
to
4fa6936
Compare
Superseded by #21467 Related follow-up tasks which may be able to draw from this pull request as reference:
|
Closes #19685
Description
This PR adds a new Post block for setting a specific post context in a block subtree.
Currently, the post is selected by ID. In the future, we should implement a Combobox post searching input.
To test this, it also implements editing modes in the Post Content and Post Title blocks. I.e. when provided a post context, these blocks now allow you to edit the post's content and title respectively.
The question remains of how to approach server-side rendering here. I propose we enhance
do_blocks
to support reading parent block attributes in a React Context like manner. That way things like Post Content blocks can opt-out of reading from the post loop if they detect they are nested under a Post block with an explicit post context.How has this been tested?
Screenshots
(We need to improve the dropzone logic there.)
Types of Changes
New Feature: The Post Content and Title blocks now support editing post content and titles.
New Feature: There is a new Post block for rendering specific posts.
Checklist: