Repository navigation
UI: Add Avatar component #76836
Description
What problem does this address?
In building admin UIs, there is and will be a need to display user avatars, and we should expect this to be standardized and adopting design tokens.
Avatar and AvatarGroup components exist in the @wordpress/editor package as of #75652, which in turn built on #75595 and #75591. This is used today in the real-time collaborative editing feature.
Future use-cases could include current user indicators (e.g. sidebar mockups in #70913), user management screens, etc.
What is your proposed solution?
Add an Avatar component to @wordpress/ui.
Prior art in other design systems and component libraries:
- https://base-ui.com/react/components/avatar
- https://chakra-ui.com/docs/components/avatar
- https://coss.com/ui/docs/components/avatar
- https://shopify.dev/docs/api/shop-minis/components/primitives/avatar
- https://atlassian.design/components/avatar/examples
This should ideally be used in place of (or wrapped by) the existing implementation in @wordpress/editor and should support existing behaviors. This doesn't necessarily mean it should follow the exact API as the existing component, but it should be possible to implement all of what already exists today (including through custom extension).
The scope of this issue doesn't necessarily include AvatarGroup. It's not clear to me there's a demonstrated wide use-case for this, and it could continue to exist as a component specific to the @wordpress/editor package.
I'm adding "Needs Design" label, since while this already exists in the UI today, we don't have any standardized design specs around this, and it doesn't exist in the Figma library.
Activity
aduth commentedon Mar 30, 2026
Copying some implementation notes shared by @ciampo in #75591 (comment) :
simison commentedon Apr 1, 2026
What I'd expect is that there is an Avatar component in
@wordpress/ui, and a separateGravatarcomponent alongside HoverCards in the Gravatar packages. I'd expect these Gravatar + Avatar components to work really well together in the WP world for plugins to build things upon them, and profiles to look consistent across WP and plugins. The Gravatar component could even be already registered and shipped with WP.In fact, the existing Commenting settings are so tied to Gravatar that going directly to Gravatar support might even make sense:
If the user chooses one of the default avatars, they should likely expect all interfaces at least in WP to follow along.
We've done a couple of Gravatar components at a8c around a few projects; these might work as inspiration:
aduth commentedon Apr 2, 2026
Yeah, I agree the component in
@wordpress/uishould be pretty low-level and support (but not bake-in) use-cases for higher-level abstractions like Gravatar or HoverCards components.Another high-level component within the Gutenberg context might end up being one that wires up the
Avatarcomponent using the user object (specificallyavatar_urls, usingget_avatar_url), which in turn would likely be sourced from Gravatar, but not inherently tied.Lift Gravatar component into @automattic/jetpack-components
aduth commentedon Oct 14, 2026
@ciampo With #84145 having been merged (🎉), should we consider this issue complete? Was there a reason you chose to not use the "Closes" auto-closing language in your pull request?
ciampo commentedon Oct 14, 2026
We can close.
The component will receive substantial improvements in #84653 and will need to expose additional first-party support for assigning a color to different users when collaborating, but those can be considered follow-ups