-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add edit post comment block #30671
Add edit post comment block #30671
Conversation
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @diedexx! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
I wonder if the block name should be Post comment edit link, I know that the pseudo link is used in more than one block, but I think this needs to be reconsidered because it is still possible to right click and open the link, or select and open the link using a screen reader, and the result is not the expected since the current page is opened instead. I used the following markup to test the block in the post editor:
I only tested it with the administrator user role. Except for the remark about the link, the block is working well for me. |
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.
Thought I'd do a quick review and test, but I don't work regularly on FSE, so may be missing some aspects in my review.
Seems really good so far, nice work.
</PanelBody> | ||
</InspectorControls> | ||
<div { ...useBlockProps() }> | ||
<a href="#edit-comment-pseudo-link">{ __( 'Edit' ) }</a> |
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.
Clicking the link in the editor seems to cause an unusual crash and some console errors, not sure what's happening, but it's probably unrelated to this PR. Thought I'd flag it though.
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.
Nice catch! It could cause some pretty nasty behaviour. I've created an issue for that: #30967
I wouldn't know how to adres this in the scope of this block though besides removing the href. But removing the href has its own issues.
That name sounds better to me too 👍 |
Thank you for your feedback @carolinan and @talldan |
@diedexx How's it going on this task? Let me know when it's ready for review or if there's anything I can help with. |
Hi @talldan, I've just added the requested fixture. I'd really appreciate a review |
Co-authored-by: Carolina Nymark <[email protected]>
14d5f9b
to
a08e66a
Compare
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.
Nice work done @diedexx!
I've suggested some changes in order to make this component similar to other existing ones like post-comment-author
, post-comment-date
or site-logo
.
Hope they are fine!
<ToggleControl | ||
label={ __( 'Open in new tab' ) } | ||
checked={ openInNewTab } | ||
onChange={ () => | ||
setAttributes( { | ||
openInNewTab: ! openInNewTab, | ||
} ) | ||
} | ||
/> |
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.
Using the same approach as site logo block could be:
<ToggleControl
label={ __( 'Open in new tab' ) }
onChange={ ( value ) =>
setAttributes( {
linkTarget: value ? '_blank' : '_self',
} )
}
checked={ linkTarget === '_blank' }
/>
"openInNewTab": { | ||
"type": "boolean", | ||
"default": false | ||
} |
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.
There are similar approaches already on production blocks. Maybe we could change this one in order to keep consistency between them!
For example:
https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/site-logo/block.json#L19-L22
"fontSize": true, | ||
"lineHeight": true |
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.
When I tested on my local site, it appeared a notice telling: fontSize support is now declared under supports.typography.fontSize
Using this new approach should solve it.
"typography": {
"fontSize": true,
"lineHeight": true,
"__experimentalFontFamily": true,
"__experimentalFontWeight": true,
"__experimentalFontStyle": true,
"__experimentalTextTransform": true,
"__experimentalLetterSpacing": true
}
if ( $open_in_new_tab ) { | ||
$link_atts .= 'target="_blank"'; | ||
} |
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.
If we change to the other blocks approach. We have to change this into something like attributes['linkTarget']
in order to work on the frontend.
export { metadata, name }; | ||
|
||
export const settings = { | ||
title: _x( 'Post Comment Edit Link', 'block title' ), |
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 title and description should be in block.json
so it gets exposed also on the server.
Let's close this PR in favor of #35965 opened by @c4rl0sbr4v0. It has additional iterations and is ready for testing. @diedexx, thank you for working on this PR, it was very helpful. All your comments were cherry-picked to the new branch 🎉 |
Description
Fixes #30577
Adds a Edit Comment Link block which can be used inside a Post Comment block which renders the edit link if the logged in user has the right capabilities to edit the comment.
How has this been tested?
I've placed a Post Comment block on a post and selected an id of an existing comment. In that block, I've placed the new Edit Comment block and modified all available properties in the sidebar and checked if these changes were reflected on the published post.
Screenshots
Types of changes
New feature - New block type: Edit Comment.
Checklist:
*.native.js
files for terms that need renaming or removal).