Post excerpt block - add color, fontSize, lineHeight, and text alignment. #23945
Conversation
Addison-Stavlo
requested review from
ajitbohra,
Soean and
talldan
as code owners
Addison-Stavlo
requested review from
epiqueras,
noahtallen,
vindl,
ockham and
Copons
|
Size Change: -1.02 MB (88%) 🏆 Total Size: 1.15 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
For some reason, I'm not seeing the excerpt show up. I tried putting it in a singular template with a page selected. It also seems like alignment options don't show up in this case either...
But font size and color work!
By the way, I think the failing php test is due to phpcs issues in the PHP file
|
+1 for not being able to test this. I had the very same issue for Post Date in #23931, and solved it by explicitly using the E.g. // block.json
{ "context": [ "postType", "postId" ] }// edit.js
function Edit( { context: { postType, postId } ) {
const [ excerpt, setExcerpt ] = useEntityProp( 'postType', postType, 'excerpt', postId );
// ...
}For some reason, In #23931 this also had the advantage of simplifying the block, as it doesn't need the wrapping export anymore. Once the block manages to receive the post attributes from the context, the new changes work as expected! ✨ There are several unrelated issues (which being unrelated shouldn't block this PR):
Also, we could turn the block into a light wrapper block. |
|
I added post excerpt to the |
|
It looks like it is working for the homepage though!
|
| @@ -4,3 +4,7 @@ | |||
| line-height: inherit; | |||
| } | |||
| } | |||
|
|
|||
| .wp-block-post-excerpt.has-link-color a { | |||
| color: var(--wp--style--color--link) !important; | |||
There was a problem hiding this comment.
do we need !important ?
There was a problem hiding this comment.
Either that or more specificity. Since there are a handful of nested elements in this block theme supplied generic link style rules overwrite our link color selection when we also have a background color applied.
There was a problem hiding this comment.
Do you have an example of rule with higher-specificity and where does it come from? (Just to help with the reasoning)
There was a problem hiding this comment.
Sure thing (maybe there is a better way to deal with this), but currently I am testing the link colors with the Seedlet-Blocks theme (I can't seem to get the option to show up for 2020/2019-blocks). When a background is applied, the link color selection stops working because of this rule:
There was a problem hiding this comment.
For me, this is an area where the theme should adapt its styles. Ideally, with global styles (and the link color feature is part of global styles), the themes don't provide as much detailed CSS but it's more "managed".
There was a problem hiding this comment.
I was wondering about this as well - Theme styles being too restrictive vs. block styles not defining enough. Although, I was having trouble finding another theme where I could test link colors anymore (I remember previously testing them on one of the 2020/2019/blocks themes but they don't seem present anymore?).
Since link colors in simple blocks such as paragraphs work on Seedlet, I figured these more complex/nested element blocks should adapt their styles accordingly. After all has-background a does not seem like a very opinionated rule, and makes sense for a theme to supply a default style for links used in background areas. So perhaps blocks like this need some sort of rule to ensure that if a custom link color is applied at the block level, the nested elements are explicitly given a style rule to properly show that selection?
There was a problem hiding this comment.
I think this is a Seedlet theme bug, though.
That :not( .has-background-background-color ) increases the specificity enough to override the block's link color.
If you try to remove that :not(), you'll see that the block's rule doesn't need the !important anymore.
All the same, you could leave the :not() on the theme, and add another class to the block's rule to make the color work without !important, e.g.
.wp-block-post-author.has-link-color a,
.wp-block-post-author.has-link-color.has-background a {
color: var( --wp--style--color--link );
}AFAIK, this happens because :not( .class ) works as if it added a .NOT-class to the selected element.
So you'd have .wp-block-post-author.has-link-color (2 "classes" of specificity) selected by the editor styles, and something like .has-background.NOT-has-background-background-color (again, 2 classes of specificity) selected by the theme styles.
Since the theme styles are loaded after the editor's, given the same specificity, they prevail.
I'm not entirely sure of the purpose of that :not( .has-background-background-color ) (defined here: editor, front end), by the way.
It basically forces a text color to all text blocks with a background, except those using the background palette color as background color.
I kinda suspect this selector could be revised in the theme, since there's already an override (editor, front end) for blocks with p as root element.
There was a problem hiding this comment.
Very well put, thanks @Copons! Updated 😄
|
I'm not sure how to test the experimental link color. 🤔 |
@noahtallen You need to highlight text for it to work (as its the standard richText tools). And this block is set up in a very odd way in that the preview of the post's content you pointed out is only a placeholder for the rich text excerpt field. So if you click on that text and start typing, it will start creating the custom excerpt to save for the post. This is the actual rich text that can have those styles applied. 🤷♀️
@Copons it should be available in seedlet blocks. The 'read more...' section is a link, but you could add a link to the custom excerpt through rich text to test as well:
|
|
Update - 404fe64 - I tried using the Warning component to add a custom message. Maybe this makes the most sense:
I also updated to prevent the error regardless of that early warning return. However, without returning the warning it would be in a state where the user can edit the excerpt text but nothing is dirtied and or savable as it has no corresponding entity to save against.
@noahtallen - Gotcha. I get this error when I add it to a template in general as postType and postId are undefined. We could return something like what you pointed out before - #23945 (review) - that was preventing us from seeing the error. Or change the text to say something like 'No post found.' ? Or is the error'd block better in this case because it is easy to tell that the block has encountered an error, as opposed to hiding it in some text that looks like a paragraph block?
vs
|
Ahh that makes sense. I think I expected it to just change the style of the whole thing. (probably an area for design to give feedback, along with how it edits the excerpt inline) |
I think in my brain, it makes the most sense to have it be a placeholder of some sort. Not sure what design would look like in that situation. But I think this would fit with any of the blocks that don't have context available (like post_content block without having a page selected as context). Instead of erroring or warning, i think it should show a placeholder thingy that helps people understand what it would look like when it has the right context. Since it's not really an actual "error" in that the block was inserted in a place where it is allowed to be |
I expected that the first time I tried the block too. Its definitely a bit funky feeling atm. |
|
This works well for me, but I'd rather have a different way to handle front end link colors that doesn't involve |
Addison-Stavlo
deleted the
update/post-excerpt-block-color-typrography-flags
branch
| @@ -2,6 +2,9 @@ | |||
| "name": "core/post-excerpt", | |||
| "category": "design", | |||
| "attributes": { | |||
| "align": { | |||
There was a problem hiding this comment.
In my opinion, this should most likely not be called align, but rather textAlign. I know align is how the Paragraph block does it, but this is confusing since there is also block alignment, which (if using the supports flag) uses align as its attribute name.
There was a problem hiding this comment.
Agreed, textAlign or alignText would be preferable (I was following the paragraph block's lead at first here). I saw the align support hook is for block alignment as well and noticed the confusion. I wonder how many other blocks have this conflicted naming convention, but we should start updating them.
There was a problem hiding this comment.
Or would it be better to similarly update the align hook to be blockAlign or something similar?
If this is more recent than some of the blocks that use align for textAlign, then less people should be effected by the change. That is, Im assuming if we updated the paragraph block's attr name then a user who updates their Gutenberg version will have whatever alignment settings they saved lost?
There was a problem hiding this comment.
Is there a compatibility layer for changing a block attribute name? I think there is something for updating a block to a newer version without loosing settings 🤔
There was a problem hiding this comment.
Is there a compatibility layer for changing a block attribute name? I think there is something for updating a block to a newer version without loosing settings 🤔
That would be good, at the very least for now I will update the FSE blocks that are using align for text alignment to use textAlign
There was a problem hiding this comment.
There is indeed a way to easily handle (what would otherwise be backward-incompatible) changes in block attribute schemas:
https://developer.wordpress.org/block-editor/developers/block-api/block-deprecation/
A lot of core blocks already make use this, storing their deprecated versions in a deprecated.js file.
There was a problem hiding this comment.
Updated for the FSE blocks specifically - #24077
Description
As part of #21087 to add feature parity to FSE blocks. This adds settings (and some necessary restructuring/styles to support) text alignment and the experimental flags for color, fontSize, and lineHeight.
How has this been tested?
Tested on local docker env.
Verify settings applied and saved in the editor for colors, font size, line height, and text alignment are appropriately reflected in the editor and on the front-end.
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: