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: RoyHridoy <[email protected]>
Co-authored-by: aduth <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: jasmussen <[email protected]>

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

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @RoyHridoy! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

This is a good fix, but let's test the Guide instances in the Editor too. When the default admin theme is selected I suspect the close button will become invisible on hover due to the color of the illustrations used there? We should fix any issues there before merging I think.

I don't love the proliferation of the style override, but at least the component is fixed. I'll defer to others on whether this trade-off is worth it.

I don't love the proliferation of the style override, but at least the component is fixed. I'll defer to others on whether this trade-off is worth it.

Thanks for the feedback! I totally understand the concern about adding more style overrides. Ideally, I’d avoid both overrides and duplicated styles.

While working on this, I noticed that there’s already some CSS duplication in the following files:

packages/editor/src/components/global-styles-sidebar/style.scss
packages/edit-post/src/components/welcome-guide/style.scss
packages/edit-widgets/src/components/welcome-guide/style.scss
packages/edit-site/src/components/welcome-guide/style.scss

Applying this scoped override felt like the most consistent and least disruptive approach for now.

I’m definitely open to learning about alternative solutions if there’s a cleaner way to handle this, just felt other options might require more effort for a small fix like this.

As best I can tell, this covers existing usage so there shouldn't be any regressions. I think we may still want some hover effect for the default component, but it doesn't impact current usage.

So it looks good to me 👍 But I'm curious for feedback on the idea of color mixing or default hover effects.

Nice idea! Felt excited to do this experiment. Here is the result for various (color-mix) hover state -

30% white with currentColor

WelCome Guide 30% White currentColor	Only Guide 30% White currentColor

50% white with currentColor

WelCome Guide 50% White currentColor	Only Guide 50% White currentColor

Only CurrentColor

My Observation

• currentColor may be not same always with the background (like white background or current welcome-guide (light blue))
• So, depending on the use case, the end users may need to override the default hover effect.
• As Close Button is a Button Type by default, it gets some hover style. (Removing hover from Guide doesn't create problems)
• Provided Solution didn't create any problem for the existing implementation, and Guide also gets the default style.
• Keep the close button to the outside (top right) of the modal can be another approach, but maybe it doesn't align with the current design system.

Thanks for exploring those options @RoyHridoy ! Just to clarify, is your suggestion to proceed with these changes as-is and not introduce the color mixing? I agree that some of those combinations aren't great, stemming from the currentColor value. We could maybe revisit each use-case separately. The current changes seem like a safe way to prevent regressions while addressing the underlying cause.

It also might be worthwhile to note this fix in the components changelog (per the optional, failing build), though not strictly necessary.

Just to clarify, is your suggestion to proceed with these changes as-is and not introduce the color mixing?

Right! The intention is to move forward with these changes as-is. Adding color mixing introduced edge cases and inconsistent hover colors, so addressing each consumer individually later is a safer strategy. The current solution keeps Guide generic and prevents the regression.

I’d also include the changelog update. Appreciate the review!

The failure looks like a TypeScript memory issue, not related to my changes. A re-run should fix it.

Sounds good 👍 I also see some similar discussion in #73219 to this effect of follow-up with revisiting guides.

Let's get this fix merged in the meantime 🚀 Congrats on your first contribution!