Block Library: enhance the author block

[draganescu]

Description

Closes #19696

Aside from the implementation here and the details in the review, the follwing things are still pending:

• always use the display name
• add font size to the inspector
• add link option in inspector

Things to explore, possibly outside this PR based on feedback:

• it is not obvious that changing the author in the block updates the post
• inline changing of the author
• is byline really needed? It could be a paragraph before it.
• multiple authors in the block for one post

Screenshots

How has this been tested?

1. Enable the full site editing experiment
2. Create a single template for full site editing
3. Create a post
4. Add the author block
5. Preview the post

[draganescu]

@mapk this PR implements most (all?) of the functionality needed by the new author block, but It doesn't look best yet.

One thing though: I added an avatar size selector to the inspector. Using block styles to play with the avatar size, like in the mock-up, would mean that we use the avatar as a background instead of an image, and I think it's not OK. The avatar's URL depends on both the author and the size, so we can't change that based on style (or can we?) 😁

[tellthemachines]

I'm having trouble testing this PR correctly. In the instructions, where do I "Create a single template for full site editing"? I tried to do so in Appearance > Templates, but can't find out how to apply the resulting template to a post.
If I skip that step, I am able to add a Post Author block to a regular post, but although it displays in the editor, on the front end "No matching template found" is rendered as the post title.

In the editor view, it would be good to have some padding on the left of the block content:

[mapk]

Thanks for wrangling this PR, @draganescu! After fiddling with the block a bit, here's some feedback.

1. The Avatar size is a bit out of context when I don't toggle "on" the avatar. Let's only show the avatar size if the avatar toggle is "on". Something like this:

2. I have my display name set as "Mapk" so when I toggle "on" the "Show display name" option, I expected to see that, but instead saw my first and last name. When I toggled "off" it showed my display name. This felt like a bug.

3. There is a lag when the page is loading. The block shows "Post Author Placeholder" instead of just showing the author's name.

4. The byline, when added, should align where the Author name was before.

I wonder if the byline should mimic the "citation" in the Quote block. So this way it's there ready for the user to type something, but when clicking away from the block, it disappears if nothing is present.

5. The vertical and horizontal spacing should all be equal in these areas.

Reducing the spacing to 10px helps add a consistent grid throughout. See below:

[mapk]

When thinking about the positioning of the byline, I think it might work better aligned with the other text. Maybe even styled to look like the Quote block's citation.

[draganescu]

Current state:

[shaunandrews]

The text alignment button in the toolbar doesn't seem to do anything, and I'm not sure it should even be there at all. Similar, while the color button does work, I wonder if its needed or required.

I've been trying to find a way to surface some of the options from the sidebar into the toolbar. I've ended up with this "Display" menu:

Its a little generic, but I think it helps "unhide" all these options which are currently in the sidebar.

Also, having the byline on it's own line seems a little much. Often, I'd expect this to literally just contain "Written by:" or similar language, and it could look strange to force two lines when a single line (byline + authorName) seems to work better.

[mapk]

I've been trying to find a way to surface some of the options from the sidebar into the toolbar. I've ended up with this "Display" menu:

I'm glad you're exploring ways to bring over these bits to the block. Looking at this, I wonder if we should just call it "Settings" instead of "Display"?

Does this open up the ability to add all settings to the block toolbar? The Accessibility Team, I think, would love that to happen. But before it does, I do struggle with clear rules for when a "Display" dropdown should be used over the Sidebar. Do you have an idea on how we might communicate the difference to developers?

Also, having the byline on it's own line seems a little much.

Your byline works beautifully.

[MichaelArestad]

This is a complex block for sure. I wonder if the avatar, byline, name, and bio should all be their own blocks inside the Author block. There is possibly even some merit in being able to add those blocks on their own to get really creative with layout and presentation of the author.

On the one hand, some things get simpler. To remove an avatar, just select it and delete it. To add it back, click the child block inserter. To edit a byline, just click into the field and start typing. To remove it, delete the content of the field. The responsibilities of the parent Author block would then be reduced to style variants and switching the author (maybe?).

Where it gets complicated is how you structure the child blocks. Do you have a very rigid format that prevents the user from moving blocks around? This would enable the styles to be predictable and will have the user relying more on the style variants provided by the theme (if any). If it isn't done with a rigid inflexible layout, will the user have to use things like columns to layout the content inside the Author block? That adds one more layer of complexity.

[mapk]

What about an actual icon in the toolbar that toggles the avatar?

I'm still iffy on how the avatar sizing might work though.

[shaunandrews]

I wonder if the avatar, byline, name, and bio should all be their own blocks inside the Author block.

I had this same thought early on, using child blocks to define all the elements. But then that would make laying out all the elements more difficult, requiring things like a Columns block to align the profile photo to the left of the name and bio. It still might be worth a exploration, though.

--

Here's another take on using toggle buttons in the toolbar for the profile photo and bio, with an "edit" pencil icon for changing the display name and author:

I added a new interaction for changing the photo size, but it feels a little strange.

[mdrovdahl]

Perhaps this thread is not the best place to discuss...but, has any consideration been given to how this block might interplay with https://wordpress.org/plugins/co-authors-plus/?

[mapk]

@mdrovdahl, the co-authors option was explored in the issue. I think it's most likely a version 2 for this.

@shaunandrews, I like the further explorations there! I wonder if we need to worry about an avatar size right now. Can the theme handle that instead? I imagine the border-radius would come from the theme as well. Overall, the avatar size option isn't too bad. It borders on being an inner-block at that point, but very limited, which I think is good.

[draganescu]

@mapk @shaunandrews I wonder if we could iterate on this block in future PRs? For now the block has the required basic features and most of the interactions suggested here would use the incoming G2.

I can take these suggestions and make new issues out of them following this merge and move on with the current Inspector based interactions this PR implements.

[ockham]

Howdy @ockham I pushed a refactoring that removes all storage of author data from the block and leaves only the settings of the block. Also we use the entity save function (great idea! 🙇 ) to update the post when the author is changed (the post has to be saved).

Thanks a ton for making those changes!

Also I have updated the rendering of the block to not use attributes for author data but instead normal author meta WordPress functions.

👍

As for UI I say we merge it like this (UI-wise) and I am sure we can have a future iteration based on some design update. The date block is more fit to that in place style, this one not so (with all those settings). What do you think? We can always add a needs design feedback label, but I wish we could just merge the block since I am sure once used new ideas will appear.

Yeah, I definitely don't want to block this PR any further -- any refinements can be made in follow-up PRs.

I'll give it a last round of testing and will then approve!

[ockham]

Could do

Suggested change

	const avatarSizes = [];
	if ( authorDetails ) {
	forEach( authorDetails.avatar_urls, ( url, size ) => {
	avatarSizes.push( {
	value: size,
	label: `${ size } x ${ size }`,
	} );
	} );
	}
	let avatarSizes = [];
	if ( authorDetails ) {
	avatarSizes = Object.keys( authorDetails.avatar_urls ).map( ( size ) => ( {
	value: size,
	label: `${ size } x ${ size }`,
	} ) );
	}

-- I personally prefer .map over .forEach since it's a bit more obvious to see that we're mapping one set of values to another.

[aduth]

@ockham 's comment here was marked resolved, but I don't see there there were any revisions. I agree with the point to be using map here. Lodash's map can be slightly more expressive, at least since we're already using forEach from Lodash anyways:

const avatarSizes = map( authorDetails?.avatar_urls, ( url, size ) => ( {
	value: size,
	label: `${ size } x ${ size }`,
} );

[ockham]

Thanks, this is working nicely!

I left a few suggestions -- mostly syntactic sugar, none of them blocking.

Overall, this is good to merge! 🚢

[mapk]

Darn, I was hoping to catch this before merging. But I noticed the "byline" section is just too close to the Author's name.

Twenty Twenty

Twenty Nineteen

[aduth]

In testing #22114 and rebasing #21696, I'm a bit confused by this condition. A newly inserted Post Author block will have no attributes. But don't we still want to show something for the front-end rendering for a block in this default state?

[aduth]

It's also more obviously a problem in the Site Editor, where none of the Block Inspector fields appear to display for the block to be able to modify the attributes. Is this expected?

[draganescu]

This is interesting. I don't remember what was the cause of that condition and it does look weird to me as well, not rendering anything.

On the side of FSE however, that is more nuanced. What you see is a placeholder that exists only if there is no author to show. If there is no author to show, how should the inspector controls behave? Considering they're mostly styling controls ...

[aduth]

Is there a reason to assign this in code, rather than as the default value for the attribute?

[draganescu]

Good idea, it should be the default attr val.

[aduth]

Good idea, it should be the default attr val.

I looked at it briefly as part of #22359, and there was one potential "gotcha" which could explain why it was treated differently.

At this line of code, we'll only set a value if there's one from attributes, and not consider the default:

gutenberg/packages/block-library/src/post-author/edit.js

Line 139 in a105007

value={ attributes.avatarSize }

I can't say whether that was intentional, but I could see a case to avoid showing the default value as selected (i.e. instead, show nothing as selected until an explicit choice is made). This would behave a lot like the font size picker of Paragraph block, for example.

I still wish it were something we could do as a default attribute instead. Not only does it avoid duplication, it could probably avoid some bugs (e.g. the Post Author avatar currently won't show on the front-end if there is no size selected).

For me, it could be:

• Just show the selected value, even if it's the default
• Or, hide the value when it's the same as the default
  • Note: This should consider if the user makes an explicit choice which coincidentally is the same as the default. Technically, these are treated as roughly equivalent, though probably not as expected (Dynamic blocks: default values for attributes aren't converted into html comments #7342).
• Or, implement some way to differentiate whether an attribute value was actually sourced from the block's original markup, or if it was provided as a default.