fix: ensure buttons pick up all colours, fonts sizes, font class styles by laurelfulford · Pull Request #2337 · Automattic/newspack-blocks

laurelfulford · 2026-05-04T20:20:51Z

All Submissions:

Have you followed the Newspack Contributing guideline?
Does your code follow the WordPress' coding standards and VIP Go coding standards?
Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

This PR originated as a way to fix an issue with the new font options coming in WP 7.0, but it also fixes a couple minor issues with button styles:

It makes sure the theme's baked-in font sizes work on the front-end
It makes sure WP 7.0's new font face option works on the checkout button block
It adds a has-background CSS class when custom background colours are applied, not just colours from the default palette; ditto has-text-color.
It cleans up some extra spacing getting added in between CSS classes

Edited to add:

This PR updates block_classes() in includes/class-newspack-blocks.php, which is shared by all server-rendered blocks. The new array_filter() on the return value also affects:

homepage-articles (Content Loop)
carousel (Content Carousel)
author-profile (and the author-profile-card template)

Closes NEWS-1754

How to test the changes in this Pull Request:

Test on a site running the latest WP 7.0 RC.
Under Appearance > Fonts, click Install Fonts, allow Google Fonts, pick at least one font and install a variant by checking at least one weight/style, and clicking 'Install':

Create a new post or page, and add a few different checkout button blocks. Make sure to include:

A block using colours from the theme (background and text)
A block using custom colours
A block using font sizes from the theme (like 'Large')
A block using a custom font size
In the 'Typography' panel, click the ... menu and select 'Font', then use it to change the font-family on one of the buttons.

Publish and view on the front end and note what's not working -- it should be the baked in font sizes, and font family. If you view source, you'll also see some funky styles (like background-color: primary)
Apply this PR.
Refresh the front end and confirm the block styles are all being picked up - the only one that should be a mismatch with the editor is the padding, but this is due to missing editor styles from the theme; that'll be fixed in a separate PR (here).
Ensure that blocks with custom background and text colours have the has-background and has-text-color classes, respectively.

Other information:

Have you added an explanation of what your changes do and why you'd like us to include them?
Have you written new tests for your changes, as applicable?
Have you successfully ran tests with your changes locally?

…e used

Copilot

Pull request overview

This PR updates the server-side rendering for the Checkout Button block so front-end output better matches editor-applied typography and color styles (notably for WP 7.0 font options and custom colors), and tidies class-string output by filtering empty class tokens.

Changes:

Add missing typography-related classes (has-*-font-size, has-*-font-family) to the rendered checkout button element.
Ensure has-background / has-text-color classes are applied when colors come from custom values in style, not only from theme palette slugs.
Filter out empty class entries when building class strings to avoid extra spacing.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
`src/blocks/checkout-button/view.php`	Adjusts how button classes/styles are generated so preset/custom colors and typography are reflected on the front-end.
`includes/class-newspack-blocks.php`	Filters empty class tokens in `block_classes()` to reduce stray whitespace in class attributes.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

chickenn00dle

Tested locally and the changes look good — approving. A few non-blocking suggestions inline, plus two out-of-diff observations below.

src/blocks/checkout-button/view.php:171 — pre-existing leading space in ' has-custom-width …' produces double-spaces in the imploded class list (array_filter drops empties but doesn't trim). Since this PR cleans up extra spacing between CSS classes, it'd be worth fixing here too.

src/blocks/checkout-button/view.php:99-104 — $button_classes / $button_styles are interpolated via %1$s / %2$s without an outer esc_attr(). Individual segments are escaped before imploding, so values are safe today, but a defense-in-depth esc_attr() at the sprintf site (or moving escaping into block_classes() itself) would prevent future contributors from missing it.

chickenn00dle · 2026-05-12T21:11:10Z

 		}

-		return implode( ' ', $classes );
+		return implode( ' ', array_filter( $classes ) );


Non-blocking: array_filter() here is cross-cutting — all callers of block_classes() (carousel, author-profile, homepage-articles, author-profile-card template) get this empty-string trim, not just checkout-button. Worth a one-line PR-description callout for reviewers of those other blocks.

Also: bare array_filter() strips all falsy values, so a legitimate '0' class would be dropped. None of the current callers can produce '0', but array_filter( $classes, 'strlen' ) would be more explicit about intent.

God call, @chickenn00dle! I've added strlen in e24b44c, and updated the PR description to mention the other blocks that will be affected.

chickenn00dle · 2026-05-12T21:11:10Z

+			$background_color ? 'has-' . esc_attr( $background_color ) . '-background-color' : '',
+			$gradient ? 'has-' . esc_attr( $gradient ) . '-gradient-background' : '',
+			$font_size ? 'has-' . esc_attr( $font_size ) . '-font-size' : '',
+			$font_family ? 'has-' . esc_attr( $font_family ) . '-font-family' : '',


Non-blocking: font-family / font-size slugs go directly into class names via esc_attr(). If a theme ever ships a slug with uppercase or unusual characters (e.g. Inter), the emitted has-Inter-font-family won't match what core writes (has-inter-font-family). In practice the editor lowercases slugs, but sanitize_html_class() is one extra line and would harden it.

In practice the editor lowercases slugs...

It looks like it does in some cases, but not for dynamic blocks (like the Core search block, or this one): if you make one of the colour slugs capitalized in the theme.json, it will come out that way in the front-end and not match the CSS class.

Ditto weird characters -- like *. Core doesn't remove them from dynamic Core block classes, even if it does remove them from the classes generated for CSS (they get replaced with a -).

Based on this, this block acts like a dynamic block in Core, so I'm going to leave this as is for now. It doesn't sound like theme authors are running into this issue with wacky slug choices 🙂

Thanks for flagging this though, @chickenn00dle! It was kind of cool to see how this stuff is being handled under the hood!

chickenn00dle · 2026-05-12T21:11:10Z

+			$gradient ? 'has-' . esc_attr( $gradient ) . '-gradient-background' : '',
+			$font_size ? 'has-' . esc_attr( $font_size ) . '-font-size' : '',
+			$font_family ? 'has-' . esc_attr( $font_family ) . '-font-family' : '',
 			$text_align ? 'has-text-align-' . esc_attr( $text_align ) : '',


Non-blocking: no has-custom-font-family companion. A style.typography.fontSize (custom) path gets has-custom-font-size further down (~line 170), but a style.typography.fontFamily (custom) path has no parallel hook. wp_style_engine_get_styles still injects the inline CSS, but the asymmetry means themes have nothing to target for custom font-families. Consider parity.

Thanks @chickenn00dle! I'm going to hold off on this one as well for now:

Unlike options like colours or font size, there is no free-form font family input. Any fonts registered through Appearance > Fonts or from a block theme's theme.json generate a CSS class that will be used to assign the fonts. There isn't actually a pathway to get the font assigned via a style attribute using this dropdown, which is how custom colours & fonts are applied, and why CSS classes for them have a bit more of a utility.

If it turns out there IS a use case for this, we can absolutely add it down the road, though!

adekbadek

Tested this on WP 7.0-RC3 with the block theme: added a page with checkout buttons covering theme palette colours, custom hex colours, theme font size, custom font size, the Cardo theme font family and a custom gradient. Front-end output is correct in every case now — the right has-{slug}-* classes, custom values still emitted inline by the style engine, and no more background-color: primary-style garbage or stray double-spaces in the class list. Nice fix.

One thing worth deciding on before merge (the textColor note inline). Not blocking.

One more out-of-diff observation: no render test for this block (cf. tests/test-donate-block.php for the donate block), and this is exactly the class/style serialization that's regressed a couple of times on this branch. A focused test — assert preset attrs produce the has-{slug}-* classes with no slug-as-value inline CSS, style.color.background/gradient trigger has-background, and Newspack_Blocks::block_classes() emits no leading/trailing/double spaces — would be cheap insurance.

adekbadek · 2026-05-12T21:34:19Z

 			$text_align ? 'has-text-align-' . esc_attr( $text_align ) : '',
 			isset( $style['border']['radius'] ) && $style['border']['radius'] === 0 ? 'no-border-radius' : '',
-			$button_color ? 'has-text-color has-' . esc_attr( $button_color ) . '-color' : '',
+			( $button_color || isset( $style['color']['text'] ) ) ? 'has-text-color' : '',


Suggestion: The render callback reads $attributes['backgroundColor'] (line 88) but never $attributes['textColor']. So a named preset text colour picked via the block's Text control lands in textColor (the slug) and is silently dropped on the front end — no has-text-color, no has-{slug}-color. The new ( $button_color || isset( $style['color']['text'] ) ) guard covers the custom-hex text colour, and $button_color covers a preset link colour stored under style.elements.link.color.text — but not the plain textColor attribute, which is what the block's own colour UI actually writes for a preset.

Confirmed at runtime: a button with textColor: "accent" on a light (base-2) background renders with the default white text — effectively invisible — while the editor renders it correctly (has-base-color/has-accent-color). So there's an editor↔front-end mismatch for the most common text-colour case.

This is pre-existing (trunk's view.php also doesn't read textColor), so the PR doesn't regress anything — but the PR title is "pick up all colours" and it's reworking exactly these lines, so it'd be the natural place to add $text_color = $attributes['textColor'] ?? '';, fold it into the has-text-color guard, and emit has-{slug}-color. Worth also reconsidering the style.elements.link.color.text branch: it only fires for the var:preset|color|{slug} form (a custom hex there is dropped), and elements.link is the core/button storage path — for this <button> block the colour UI writes to textColor / style.color.text, so that branch may be dead code.

Thanks @adekbadek!

I couldn't quite reproduce this problem on in RC 4 with the block theme, but the change makes sense from a code perspective (the attribute that's written is actually getting used) -- updated in a3cbd87.

With this fix, I got a little paranoid and kept style.elements.link.color.text as a fallback - I'm not sure if it was ever used and is dead, or is some old remnant of something that could show up in published blocks. After duking it out with Claude, we're both vaguely paranoid about it being used 😅 In my testing right now with the code as is, it gets populated with the same value as $attributes['textColor'] somehow -- when the code outputs CSS classes for both, you get two identical text colour classes, both with the classic and block theme.

Hope this is an okay compromise but we can revisit in a future PR if it seems safe to cut entirely!

…s, button text

laurelfulford · 2026-05-15T23:55:11Z

Thank you both for your reviews, @chickenn00dle and @adekbadek!

I ended up adding both out-of-diff requests, since I think they're solid additions to this PR:

The leading space on the has-custom-width CSS class was removed and class/text escaping was added in 9f78413.
I added some tests in 3cb95ce to cover the requested cases to avoid these issues getting reintroduced.

I'm going to go ahead and merge this but it'll go to alpha before getting released -- so if any of this sounds wrong or should be revisited, please let me know!

github-actions · 2026-05-15T23:55:43Z

Hey @laurelfulford, good job getting this PR merged! 🎉

Now, the needs-changelog label has been added to it.

Please check if this PR needs to be included in the "Upcoming Changes" and "Release Notes" doc. If it doesn't, simply remove the label.

If it does, please add an entry to our shared document, with screenshots and testing instructions if applicable, then remove the label.

Thank you! ❤️

## [4.26.4-alpha.1](v4.26.3...v4.26.4-alpha.1) (2026-05-21) ### Bug Fixes * ensure buttons pick up all colours, fonts sizes, font class styles ([#2337](#2337)) ([a1d8ae2](a1d8ae2)) * force alpha ([1adec2f](1adec2f))

github-actions · 2026-05-21T18:06:34Z

🎉 This PR is included in version 4.26.4-alpha.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

## [4.26.4-alpha.1](Automattic/newspack-blocks@v4.26.3...v4.26.4-alpha.1) (2026-05-21) ### Bug Fixes * ensure buttons pick up all colours, fonts sizes, font class styles ([#2337](Automattic/newspack-blocks#2337)) ([c13fc94](Automattic/newspack-blocks@c13fc94)) * force alpha ([ab52b60](Automattic/newspack-blocks@ab52b60)) (cherry picked from commit 845e98a4eec11c58f0502a8adc6794b889a0c965)

laurelfulford added 2 commits May 4, 2026 12:26

fix: ensure buttons pick up all colours, fonts sizes, font class styles

941e6f2

fix: ensure has-text-color class is added when custom text colours ar…

cff327c

…e used

laurelfulford requested a review from a team as a code owner May 4, 2026 20:20

laurelfulford added the [Status] Needs Review label May 4, 2026

laurelfulford requested a review from Copilot May 4, 2026 20:21

Copilot started reviewing on behalf of laurelfulford May 4, 2026 20:21 View session

Copilot AI reviewed May 4, 2026

View reviewed changes

Comment thread src/blocks/checkout-button/view.php

laurelfulford added 2 commits May 4, 2026 13:50

fix: remove unneeded inline colour declaration

a7a6249

Merge branch 'trunk' into fix/checkout-button-styles

7218739

chickenn00dle approved these changes May 12, 2026

View reviewed changes

github-actions Bot added [Status] Approved and removed [Status] Needs Review labels May 12, 2026

adekbadek approved these changes May 12, 2026

View reviewed changes

laurelfulford added 4 commits May 15, 2026 13:13

fix: remove CSS attribute spacing; add escaping to CSS classes, style…

9f78413

…s, button text

fix: add strlen to array_filter to avoid stripping falsy values

e24b44c

fix: read textColor attribute when rendering checkout button

a3cbd87

fix: add checkout button style tests

3cb95ce

laurelfulford merged commit a1d8ae2 into trunk May 15, 2026
7 checks passed

laurelfulford deleted the fix/checkout-button-styles branch May 15, 2026 23:55

github-actions Bot added the needs-changelog label May 15, 2026

laurelfulford removed the needs-changelog label May 21, 2026

Conversation

laurelfulford commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

All Submissions:

Changes proposed in this Pull Request:

How to test the changes in this Pull Request:

Other information:

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

chickenn00dle left a comment

Choose a reason for hiding this comment

Uh oh!

chickenn00dle May 12, 2026

Choose a reason for hiding this comment

Uh oh!

laurelfulford May 15, 2026

Choose a reason for hiding this comment

Uh oh!

chickenn00dle May 12, 2026

Choose a reason for hiding this comment

Uh oh!

laurelfulford May 15, 2026

Choose a reason for hiding this comment

Uh oh!

chickenn00dle May 12, 2026

Choose a reason for hiding this comment

Uh oh!

laurelfulford May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adekbadek left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adekbadek May 12, 2026

Choose a reason for hiding this comment

Uh oh!

laurelfulford May 15, 2026

Choose a reason for hiding this comment

Uh oh!

laurelfulford commented May 15, 2026

Uh oh!

Uh oh!

github-actions Bot commented May 15, 2026

Uh oh!

github-actions Bot commented May 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

laurelfulford commented May 4, 2026 •

edited

Loading

laurelfulford May 15, 2026 •

edited

Loading

adekbadek left a comment •

edited

Loading