Update Post Author block to use __experimentalColor and __experimentalLineHeight #23044
Conversation
|
Size Change: -1.03 MB (89%) 🏆 Total Size: 1.15 MB
ℹ️ View Unchanged
|
|
|
||
| // If has background color. | ||
| if ( $has_custom_background_color || $has_named_background_color ) { | ||
| if ( $has_custom_background_color || $has_named_background_color || $has_named_gradient || $has_custom_gradient ) { | ||
| // Add has-background-color class. | ||
| $background_colors['css_classes'][] = 'has-background-color'; |
There was a problem hiding this comment.
Im wondering if this should just be 'has-background'. I notice that __experimentalColor applies the 'has-background' class as opposed to the 'has-background-color' class:
gutenberg/packages/block-editor/src/hooks/color.js
Lines 130 to 133 in c53d36b
Im assuming either this should be changed to 'has-background', or the hook should be using 'has-background-color' ?
There was a problem hiding this comment.
Definitely change this to has-background we should match __experimentalColor 💯
| @@ -24,7 +24,9 @@ function post_author_build_css_colors( $attributes ) { | |||
|
|
|||
There was a problem hiding this comment.
This PR is also a good opportunity to implement this #22872 (comment)
The idea being that you don't need to touch any backend or frontend code when applying the "useColors" flag, everything should just work.
There was a problem hiding this comment.
@youknowriad To clarify, you're suggesting to basically get #22872 #21420 merged (with a change to make the gutenberg_apply_style_attribute watch out for the supports flag, rather than just individual styling related attributes), right?
There was a problem hiding this comment.
I don't think #22872 implements any of that server side support for these hooks, so I guess the suggestion is to implement the render_block filter in this PR to add that support to __experimentalColor ? ( I don't totally follow the implementation details for that yet, but this would be something that would need to be set up for __experimentalColors, __expermentalFontSize, etc. separately? )
The idea being that you don't need to touch any backend or frontend code when applying the "useColors" flag, everything should just work.
That would be great! But currently we also have to touch the backend to inject the classNames and styles for __experimentalFontSize and alignment as well. It sounds like these need to be updated in the same way? Maybe we should handle all of these being updated in a separate PR?
But I agree, it would be really nice to implement them. Having to go through this manually in index.php is definitely a pain we would like to avoid.
There was a problem hiding this comment.
(I meant #21420 rather than #22872, fixed my original comment now.)
That would be great! But currently we also have to touch the backend to inject the classNames and styles for
__experimentalFontSizeand alignment as well. It sounds like these need to be updated in the same way? Maybe we should handle all of these being updated in a separate PR?
The way I was reading Riad's comment was to have a PR to cover all those flags in a render_blocks filter that's run regardless of block type 👍
There was a problem hiding this comment.
@Addison-Stavlo I'm planning on working on this, do you want to team up to tackle the server side rendering? If we can get that done then we don't need to write any custom className and style code in any of these FSE blocks.
There was a problem hiding this comment.
I was planning on using #23007 to add the code, so we have a block to test with at the same time.
There was a problem hiding this comment.
The way I was reading Riad's comment was to have a PR to cover all those flags in a render_blocks filter that's run regardless of block type 👍
One thing I'm unclear on is: should this function render classNames, inline block CSS, and global styles/css variables? I'm not clear on the relationship between your standard inline block CSS, and the new global styles using variables. /cc @youknowriad
There was a problem hiding this comment.
Since the classes/styles for this one have already been manually set-up, I wouldn't be opposed to merging this and circling back to update it after we have enabled the proper support and updated the other FSE blocks on the task list.
There was a problem hiding this comment.
For reference, started work on the render function here https://github.com/WordPress/gutenberg/pull/23007/files#diff-1334f2cb73e38f2f89d2aaf763f07ed9R307
| // Need font size in number form for named presets to be used in contrastCheckers. | ||
| const { fontSizes } = useSelect( ( select ) => | ||
| select( 'core/block-editor' ).getSettings() | ||
| ); | ||
| const fontSizeIndex = useMemo( () => groupBy( fontSizes, 'slug' ), [ | ||
| fontSizes, | ||
| ] ); | ||
| const contrastCheckFontSize = useMemo( | ||
| () => | ||
| // Custom size if set. | ||
| attributes.style?.typography?.fontSize || | ||
| // Size of preset/named value if set. | ||
| fontSizeIndex[ attributes.fontSize ]?.[ 0 ].size || | ||
| DEFAULT_CONTRAST_CHECK_FONT_SIZE, | ||
| [ | ||
| attributes.style?.typography?.fontSize, | ||
| attributes.fontSize, | ||
| fontSizeIndex, | ||
| ] | ||
| ); |
There was a problem hiding this comment.
So we get the font size stuff out of the box with __experimentalFontSize? Yay! 🎉
There was a problem hiding this comment.
Yeah! Actually, a lot of that goo you highlighted I had to add when I added the __experimentalFontSize but was still using the HOC for colors and needed them to still 'play nice'. Now that we are using the flag for this color hook as well things work much better out of the box and all this gunk is no longer seems required.
There was a problem hiding this comment.
This is overall looking good to me! I wonder if we should follow Riad's suggestion before merging this?
Id like to at least better understand what he is suggesting. It could make more sense to do that in a separate PR but its definitely something I would like to see in general. These flags work really well for blocks that just use a save component (paragraph, heading, etc.), you don't have to touch anything! It would be nice to not have to build these classes and styles manually when php is required. |
Addison-Stavlo
changed the title
|
This is now updated for the changes made in #23007. Should be ready for a review again. |
| * @param array $attributes Navigation block attributes. | ||
| * @return array Font size CSS classes and inline styles. | ||
| */ | ||
| function post_author_build_css_font_sizes( $attributes ) { |
There was a problem hiding this comment.
I love how much code we're deleting here 💙
The byline and bio sizes both scale off the selected font size for the post author (0.5em and 0.7em respectively set up in a previous PR). I had originally set up attributes and controls to set each of the 3 sections font sizes individually in #22877 - but that was before converting to the __experimentalFontSize. It was recommended to set them based on the master size for now, but if we want to set up explicit control for them in the future we will need to update these sections to be child blocks using that fontSize flag. |
|
For some reason, it seems like the post author avatar stopped displaying in the editor after merging master to this PR: (with the avatar toggled on) Editor Front end I also found a weird bug:
This does not happen with color settings, just typography. It happens with either setting (line height or size) so long as it is the same one. If I go back to step 3 and modify the other typography setting, then I can save my changes. Here is a gif of steps 2 and 3:
|
|
Very cool. I love this approach. |
Hrm, I'm not able to repro this on its current commit or after merging master.
Interesting. Im finding this to be true for other blocks as well (such as Heading and Paragraph), but only in the Site Editor. 🤔 |
It's working for me now 🤷 It looks like it takes a sec for the image URL to load in, so maybe it just never loaded earlier.
Uh oh :( |
| placeholder={ __( 'Write byline …' ) } | ||
| value={ byline } | ||
| onChange={ ( value ) => | ||
| setAttributes( { byline: value } ) |
There was a problem hiding this comment.
I imagine this is unrelated to the PR, but it is really weird that the byline is not persisted across all instances of the same author!
There was a problem hiding this comment.
Yeah... it was set up as an attribute specific to the block for whatever reason. The bio on the other hand is per author.
Im not sure what needs to be done for some of the base styles for the block. But that does seem like it needs some love.
Ugg, I'm seeing this now too. It looks like this happened when I brought in the recent master. Running current version of master im finding this is is no longer present for other blocks that use the lineHeight such as Paragraph. Maybe some recent change/regression. @youknowriad perhaps have any ideas on what could have caused this to disappear? |
|
lineHeight is opt-in now instead of opt-out. That's probably the reason. |
|
you need |
|
This LGTM! I haven't approved the PR yet as I'd like to see the |
Done 😄 Thank you! |
Description
As a follow-up to #22877 this updates the Post Author block to use
__experimentalColorsupport for font colors, link colors, and background colors/gradients.How has this been tested?
Tested between post editor, site editor, and front-end on local docker environment.
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: