Add welcome dashboard widget with adaptive layout and content

[retrofox]

What?

Adds a core/welcome dashboard widget that greets the user and surfaces a few entry points, adapting to both its tile size and the active theme.

• Size-adaptive layout — feature columns reflow with auto-fit; the banner compacts via container queries on narrow/short tiles; it switches to a side-by-side row on wide-and-short tiles (useResizeObserver); and drops to header-only below 120×120.
• Theme-adaptive content — reads is_block_theme via getCurrentTheme() from core-data. Block themes get the site editor + styles links; classic themes get the Customizer and a block-theme discovery link.
• Full-bleed presentation via the declarative presentation hint; the surface owns the chrome.
• Widget chrome gains vertical overflow so any widget scrolls when its content exceeds the tile.
• Seeds the widget into the default dashboard layout and ships a per-widget package.json.

Still a basic implementation: the version string is static for now, and a general mechanism for passing server-provided data to widgets is left as a follow-up.

Why?

The dashboard needs a welcoming entry point, and the widget framework needs a concrete example exercising resize, presentation, theme-aware content, and chrome scrolling end to end.

How?

• widgets/welcome/ — render.tsx composes a Banner and FeatureHighlight cards inside a size-container Stack root, and reads getCurrentTheme()?.is_block_theme to branch columns 2 and 3.
• Colors use the interactive-neutral-strong token pair; layout adapts via auto-fit, container queries, and an observer-driven row/tiny switch.
• widget-chrome.module.css — overflow-y: auto on the content.
• default-layout-seed.php — seeds the widget at full width.

Testing

1. Enable the dashboard widgets experiment and open the dashboard.
2. Resize the welcome tile: wide + short → row; narrow → single column; below ~120×120 → header only.
3. Switch between a block theme and a classic theme: columns 2 and 3 change (Customizer + block-theme discovery on classic).
4. Add a tall widget and confirm it scrolls within the tile.

Follow-ups

• General channel for server-provided data to widgets (the version string is hardcoded for now).
• Dismissal action for the banner (surface/chrome concern).

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: retrofox <[email protected]>
Co-authored-by: simison <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[simison]

Would clearly make sense to use clsx here, but can't because we don't have the package.json for each widget? 🤔

It might make sense to try to add it here as a test.

[retrofox]

Yes, makes sense to me. Or maybe creating a packages.json for all widget types

[retrofox]

I'm researching this issue, but I think it deserves a separate PR.

[retrofox]

#78463

[simison]

Instead of CSS positioning, let's try how Card.FullBleed would work here now?

It's what I'd expect consumers to try and what we should make work easily (if it doesn't already).

We can't really do this Card rendering Stack trick:

gutenberg/packages/ui/src/card/stories/index.story.tsx

Lines 136 to 147 in 87e0a9b

	<Card.Content render={ <Stack direction="column" gap="lg" /> }>
	<Card.FullBleed>
	<div
	style={ {
	height: 160,
	background:
	'linear-gradient(135deg, #667eea 0%, #764ba2 100%)',
	} }
	/>
	</Card.FullBleed>
	<Text>Content below the full-bleed area.</Text>
	</Card.Content>

...so applying FullBleed on whole thing and then adding padding back might be another way? 🤔

[retrofox]

Stepping back, the real thing to guarantee here is design coherence: the padding the widget puts around its inner content should match what the chrome (Card.Content) applies.
Card.FullBleed would get us there, but by coupling the widget render to the surface's chrome system.

To me, the way that keeps the two independent is orthogonal: both sides resolve the same DS token (--wpds-dimension-padding-*) rather than one reaching into the other. The token is the shared coordination point, not a direct dependency.

Today, that coherence is by convention: the widget happens to pick the same token Card.Content does.

The missing piece to make it robust is a shared default, a semantic token that both the Chrome and the widget layout resolve from, so the value stays in sync from a single source instead of being matched by hand.

[simison]

Looking good! Let's get it in.

I think it would still make sense to add in this PR (and fine in follow-up too) a conditional content based on block theme or not, just like the original widget does as well.

Example here that worked well.

Another thing is the "dismissal" button for the header, which can now be hooked into actually removing the banner from the dashboard.

(example here)

[github-actions]

Flaky tests detected in 3845d69.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26177260217
📝 Reported issues:

• [Flaky Test] As a user I expect my navigation to use the colors I selected for it #65427 in /test/e2e/specs/editor/blocks/navigation-colors.spec.js
• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js

[retrofox]

Looking good! Let's get it in.

I think it would still make sense to add in this PR (and fine in follow-up too) a conditional content based on block theme or not, just like the original widget does as well.

Done in the latest push. The content is now theme-aware: it reads is_block_theme via getCurrentTheme() from core-data, so block themes keep the site editor + styles links while classic themes get the Customizer and a block-theme discovery link.

[retrofox]

Another thing is the "dismissal" button for the header, which can now be hooked into actually removing the banner from the dashboard.

This is a major one, similar to the presentation widget property. We need to define a proper mechanism to maintain the contract between the abstractions without coupling them, while still connecting the pieces so that it works.

Having a dismiss button in the widget content (render) sounds reasonable to me.

Working on it on a follow-up.