-
Notifications
You must be signed in to change notification settings - Fork 808
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
Testimonial Block #11723
Testimonial Block #11723
Conversation
/** | ||
* Internal dependencies | ||
*/ | ||
import { __ } from '../../utils/i18n'; |
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.
Just wanted to give heads up that we'll remove the custom i18n wrapper soon, in which point this can just be changed to @wordpress/i18n
import. :-)
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.
Aight, #11743 is merged so this can be rewritten to:
import { __ } from '@wordpress/i18n';
__( 'My testimonial', 'jetpack' ); // note textdomain!
c3c5afd
to
a7f7260
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.
So great to see this coming to life 👍 A few minor points I noticed.
return ( | ||
<Fragment> | ||
<BlockControls> | ||
<AlignmentToolbar value={ attributes.align } onChange={ this.onChangeAlign } /> |
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.
Do you need this or can you just set align
in the supports
definition?
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've tried supports: { align: [ … ] }
but it automatically applies some styles to the block for left/right which made it float around other blocks (like an image block would). I need the block to stay where it is and only use the alignment attr to restyle things inside. I couldn't get it with out of box alignment so I made my own implementation. Would be great to hear from somebody else whether it makes sense.
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.
supports.align
is block aligment and for content alignment you'd need something custom as you've done here. I think even core Paragraph is custom. Maybe some day core will have supports.contentAlignment
or similar :-)
.wp-block-jetpack-testimonial__meta { | ||
display: flex; | ||
flex-direction: column; | ||
color: #999; |
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.
Should you use a color var here?
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.
It's definitely a placeholder. I think I'll need to run this by design folks whether to use something like opacity so it works universally across themes and dark/light variants or whether there is a variable to use. There definitely are vars in editor but we also need to figure out the color for the frontend and that might be different between themes.
display: flex; | ||
flex-direction: column; | ||
color: #999; | ||
font-size: 80%; |
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.
Should you use em
s here?
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.
Another placeholder, I don't even know the exact styles we will use yet so I just put random percentages.
description: __( 'Lets you display testimonials from customers and clients.' ), | ||
icon: 'embed-photo', | ||
category: 'jetpack', | ||
keywords: [ __( 'testimonial' ) ], |
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 shouldn't need to duplicate this if it's the name of the Block itself? Some useful alternative keywords could be
{ name: 'normal', label: _x( 'Normal', 'block style' ) }, | ||
], | ||
attributes: { | ||
align: { |
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 this not be handled by supports
? Or is it more custom?
className="wp-block-jetpack-testimonial__content" | ||
value={ content } | ||
/> | ||
{ mediaId && mediaUrl && <img src={ mediaUrl } alt="" /> } |
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 alt
attribute is currently blank. Is this intentional? It feels like it should have a valid value as the only time an empty alt
is valid is when the image is always guaranteed to be purely presentational in nature.
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'm thinking about using the authors name || title || ""
as the alt. Does it make sense?
…thout the media too
The block now looks much more like a final product in terms of the editing experience.
What we are lacking now is a proper CSS for all those different styles and some other related questions. I'll pull those from Figma and convert absolute px values into ems for font-sizes, line-heights and paddings. What colors should we use? The prototype contains some specific grays but we should rather inherit the theme colors and lighten the author name and title using opacity. Sounds good? I'm still conflicted on the decision to make three of same styles, differentiating only in font size. One of the even uses italics users cannot opt out of, even though in all other styles they can control whether their text is in italics or not via the formatting toolbar. As per me, I would prefer either removing the size options at this form completely or bring back the size picker into the sidebar for all styles. |
Have a look at the Quote Block for the CSS.
Yep, sounds good 👍
Having 3 fairly similar styles doesn't make sense. Originally, I received the feedback that a font-size setting was too much complexity for this block but it was before looking at block location and homepage template.
|
/** | ||
* Testimonial Block. | ||
* | ||
* @since 7.1.0 |
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.
Remember to bump this to 7.3
/** | ||
* Internal dependencies | ||
*/ | ||
import registerJetpackBlock from '../../utils/register-jetpack-block'; |
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.
Please rebase; as of #11971 this has been moved to shared
from utils
.
@@ -20,6 +20,7 @@ | |||
], | |||
"beta": [ | |||
"seo", | |||
"testimonial", |
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.
Please rebase; as of #11971 this file has been moved to extensions/index.json
from setup
.
It seems to me this block is trying to do too much on its own and so it ends up replicating some interactions through somewhat ad hoc means — like using "styles" to change the position of elements. Have you thought about using inner blocks to assemble a block with children instead? <InnerBlocks
template={ [
[ 'core/image', { style: 'round' } ], // the profile picture
[ 'core/quote', { style: 'large' } ], // the quote and name
] }
/> <InnerBlocks
template={ [
[ 'core/image', { style: 'round' } ], // the profile picture
[ 'core/heading' ], // the person's name
[ 'core/paragraph', { style: 'large' } ], // the quote text
] }
/> The block itself could have some attributes like style variations or background (or just integrate the new "group" block) but the main advantage is that the user can move the picture to go below the quote, etc, and you don't have to replicate functionality that is already provided through those blocks (font sizing, etc). You can lock the template so that new blocks cannot be inserted. |
I agree with your ideas in general but looking at the block (and its design iterations), I don't think our editing capabilities are there yet to just take other core blocks and make a composite. Sure, your code drafts would work but they simplify the block to the point where we can just build the content in the editor, not using any extra block. The devil is in details here and I'll take the multi-axis centering and optional fields as an example: This block has a "footer" with the author name, title and avatar. All those fields are optional and when you focus you'll see "fill-the-blanks" template like this: On the frontend (and also in the editor when not selected), we make sure the content is always centered perfectly based on data that are filled in. The center alignment shows this the best: Just a name - simply centeredName and title - again, just centered. Name, title and avatar - this time text fields are left-centered, next to the avatar and the whole thing is in center. Just the name and avatar - same as the case above and now the name is also vertically centered against the avatar. In the right alignment we flip the order of image and text fields, text-alignment, margins etc… I hope that makes a point that this block has some capabilities that are not (easily) possible with just core blocks. With what is available today, I've chosen to implement a custom block for this purpose. You seem to suggest that moving the avatar doesn't fit into the "Style" category. Is that somewhere defined? All docs I've found about styles are purely technical and explain the mechanics and that they are used to "provide alternative styles to block". |
Is that even if you use the block wrapper to control the specific styles, etc?
There are no established patterns for this yet. Moving elements is something that is learned through the block movers, so it's expected to apply to elements of the block. A good example might be the fields of the Jeptack Contact Form block. Even if you create your own block, it might be good to have custom child blocks for the different parts to benefit from further UI clarity (movers, drag and drop, etc). |
I don't see how to achieve that. There are additional wrapping elements needed, not just those holding the content, in order for the centering to work. The save() generates an HTML with this shape:
With InnerBlocks, I can only make paragraphs of content, media, name and title elements as immediate siblings (correct?) which doesn't allow for the appropriate layout to be coded. |
@marekhrabe with InnerBlocks you can have your own custom blocks, which will let you have any wrapper you want. What child blocks afford you in that case is more granular control over the experience, since each "element" can have its own controls. Does that make sense? |
Thanks to both @marekhrabe and @mtias for the productive discussion. Having reviewed the comments my understanding is that the suggested approach is to:
We may also consider exploring a CoBlocks style approach to the Design variations. Variations that switching out the If we're going down this route then we'll need agreement from Marek. As the person who has authored the Block so far, I feel we need to give his concerns due credence (I'm not suggesting for one minute that this hasn't happened so far, but merely reinforcing that he has raised these for a good reason). Perhaps we could explore a proof of concept using Matias's suggested approach? If this looks like it it's heading in the right direction we can then embark on a full refactor. I'd rather we don't commit to this upfront and then find ourselves having to back out at considerable effort. Thanks again to Marek for all his work on bringing the Block to its current state. Great work which I'm sure we can build on going forward! |
This PR has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this PR has clear testing instructions, is it up to date with master, and it is still valid. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
cc @mkaz in case Tinker is interested in this. ;-) |
This PR has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this PR has clear testing instructions, is it up to date with master, and it is still valid. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
Changes proposed in this Pull Request:
This PR adds a new block for presenting Testimonials. Its basic structure is:
Testing instructions:
Proposed changelog entry for your changes:
TODOs