Jetpack button: fix width and alignment settings #41139

monsieur-z · 2025-01-16T20:45:23Z

Resolves #38779

Setting the width and alignment of a jetpack/button block doesn't work consistently, depending on how it is integrated with its parent block and whether we're in the editor or site frontend.

For instance, in a Form block, setting the button width to 50% in the editor shrinks it instead of making it half the container's width, which is what you'd expect from a user's perspective.

In a Mailchimp block, trying to align the button (to the right in the capture below) doesn't work.

The following blocks use the jetpack/button block and show one or both faulty behaviors we've highlighted:

Form
Premium Content
Mailchimp
Calendly
Eventbrite
Recipe
Recurring Payments/Payment Button

The AI Assistant might as well, though I haven't been able to experience it.

Proposed changes:

To address that, this PR does two things in the jetpack/button block:

It removes a class-less div from the markup generated by the block

This div prevents the flexbox layout applied to .block-editor-block-list__layout from working as intended.

It applies the selected width to .wp-block-button instead of .wp-block-button__link.

Indeed, this Gutenberg PR forces .wp-block-button__link to have a width of 100%, breaking the width settings behavior.

Furthermore, the PR also updates the blocks consuming jetpack/button so the width and alignment settings work as expected. Here are some caveats:

Setting the width or alignment of jetpack/button in the Recipe block doesn't work as one would expect, given the width is relative to the grid items of the block. Solving this should be part of a broader discussion.
Similarly, aligning the jetpack/button of a Form is confusing when it's not in its row. It deserves a separate discussion too.
The alignment of buttons in a similar row is not implemented (Premium Content and Recurring Payments blocks). Again, this should be a separate concern.

Other information:

Have you written new tests for your changes, if applicable?
Have you checked the E2E test CI results, and verified that your changes do not break them?
Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

n/a

Does this pull request change what data or activity we track or use?

No.

Testing instructions:

Do not checkout this branch just yet
Spin up a test Jetpack site
Create a new post
Add the following blocks:
- Form
- Premium Content
- Mailchimp
- Calendly
- Eventbrite
- Recurring Payments/Payment Button.
You'll need to connect various accounts. It's not worth adding the Recipe block (see caveat above)
For Calendly and Eventbrite, select the view that renders a submit button (in the sidebar)
Apply this PR
Refresh the post in the editor
Verify you're not seeing any block compatibility issues in the UI
Set a width on all submit buttons
Verify they're rendered with the proper width in both the editor and front end

Play with the buttons' alignment
Verify the alignment is correct in both the editor and front end, except for the Premium Content and Recurring blocks (see caveat above).
Verify this works with a simple site too

github-actions · 2025-01-16T20:46:11Z

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the fix/jetpack-button-styling branch.

To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/jetpack-button-styling

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

github-actions · 2025-01-16T20:46:27Z

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

✅ Include a description of your PR changes.
✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
✅ Add testing instructions.
✅ Specify whether this PR includes any changes to data or privacy.
✅ Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

Follow this PR Review Process:

Ensure all required checks appearing at the bottom of this PR are passing.
Choose a review path based on your changes:
- A. Team Review: add the "[Status] Needs Team Review" label
  - For most changes, including minor cross-team impacts.
  - Example: Updating a team-specific component or a small change to a shared library.
- B. Crew Review: add the "[Status] Needs Review" label
  - For significant changes to core functionality.
  - Example: Major updates to a shared library or complex features.
- C. Both: Start with Team, then request Crew
  - For complex changes or when you need extra confidence.
  - Example: Refactor affecting multiple systems.
Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

WordPress.com Simple releases happen semi-continuously (PCYsg-Jjm-p2).
WoA releases happen weekly.
Releases to self-hosted sites happen monthly. The next release is scheduled for February 4, 2025 (scheduled code freeze on February 4, 2025).

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

monsieur-z · 2025-01-17T20:46:18Z

projects/plugins/jetpack/extensions/blocks/button/edit.js

@@ -90,6 +84,5 @@ export function ButtonEdit( props ) {
 }

 export default compose(
-	withColors( { backgroundColor: 'background-color' }, { textColor: 'color' } ),
-	applyFallbackStyles


applyFallbackStyles uses the withFallbackStyles high order component from @wordpress/components, which renders the unwanted extra div (at this line). The code suggests we could get rid of that extra div by specifying a node prop, but it's unclear to me what node we could pass at that stage.

In the following discussion, not using applyFallbackStyles was hinted by several persons: p1736773641027939/1736360651.812989-slack-C052XEUUBL4. I do think it's the way to go as well. As far as I can tell, what applyFallbackStyles does is make the default background and text colors available to ButtonEdit. Yet eventually, those two colors are passed to the ContrastChecker component, which doesn't render a warning when the contrast ratio is too low to be deemed accessible.

Yet eventually, those two colors are passed to the ContrastChecker component, which doesn't render a warning when the contrast ratio is too low to be deemed accessible.

It's because the applyFallbackStyles code is wrong. It checks the block's outer element for the background color, but it's actually applied to the inner element (what it calls the textNode).

That said, I think it's pretty trivial to rewrite withFallbackStyles/applyFallbackStyles in a more modern react way that won't result in an extra wrapper, so I agree with removing it, and I'd be happy to work on getting the contrast checker working again in a follow up PR.

Here's a small PR that addresses that - #41294.

I'll keep it as a draft until this or another fix for the styles is merged.

monsieur-z · 2025-01-17T20:50:11Z

projects/packages/forms/src/blocks/contact-form/editor.scss

@@ -52,6 +52,10 @@
 			flex: 0 0 100%;
 			margin: 0;

+			&.wp-block-jetpack-button {
+				flex-basis: auto;


Overwrite the 100% value. We want to be able to set the width through the button styling options in the editor.

monsieur-z · 2025-01-17T20:51:43Z

projects/plugins/jetpack/extensions/blocks/button/button.php

@@ -226,7 +220,7 @@ function get_button_wrapper_styles( $attributes ) {
 	$has_width = array_key_exists( 'width', $attributes );

 	if ( $has_width ) {
-		$styles[] = 'max-width: 100%';
+		$styles[] = sprintf( 'width: %s;', $attributes['width'] );


Apply the width to the root of the jetpack/button, instead of its __link element that's now 100% wide.

monsieur-z · 2025-01-17T20:54:13Z

projects/plugins/jetpack/extensions/blocks/button/edit.js


 	usePassthroughAttributes( { attributes, clientId, setAttributes } );
-	useWidth( { attributes, disableEffects: isWidthSetOnParentBlock, setAttributes } );


Calling this hook results in resetting the button width when it is aligned left or right. I don't get the rationale behind that decision. In the current UI, from a user standpoint, this doesn't seem like something we'd want.

I've been testing and I also couldn't see the use case that the hook caters to. I saw this was implemented in #25394 by @mmtr, maybe Miguel remembers.

If there's no apparent current use cases, I wonder if it can be removed completely from the codebase. It's also used by Payment Button, but that has no alignment tool on the toolbar, so perhaps it's not needed.

edit: it just occurred to me, a case where it might makes sense is when the button is 100% width and an alignment is set.

monsieur-z · 2025-01-17T20:54:49Z

projects/plugins/jetpack/extensions/blocks/button/edit.js

@@ -39,6 +34,7 @@ export function ButtonEdit( props ) {

 	const blockProps = useBlockProps( {
 		className: clsx( 'wp-block-button', className ),
+		style: { width },


Set the width to the root instead of the __link element.

monsieur-z · 2025-01-23T15:15:12Z

Thanks for the review @tellthemachines.

Regarding the submit button vertical alignment issue, I intended to see how we wanted to handle that issue. And it's already broken (differently) on trunk:

But yes, let's fix it now! I'll do it in a separate PR.

Why does the percentage toggle disappear when the block is aligned left or right? It's a bit disorienting. (To be clear this is on trunk, not specifically this PR)

Totally. I don't have an answer, though.

monsieur-z · 2025-01-23T15:35:37Z

Thanks @aaronrobertshaw.

I wonder if there's an opportunity to split it up into smaller atomic chunks

Initially, the plan was to fix jetpack/button but it required updating blocks that consume it too. I chose to do all the changes in the same PR to avoid further breakage. I'd like to keep this PR as is to expedite it. I'll be mindful of that in the future, though.

Looking at the code, I suggest looking at the changes in packages/forms first. The updates to blocks in the extensions folder ensure we can set the width and alignment of the submit button in the context of the block. Blocks are independent from each other.

The contact form button's full width issue prevents any alignment

I haven't been able to reproduce this. Are you testing the branch locally, or with a live test site?

Paid content's subscribe button alignment doesn't work in the editor or frontend
Payments button alignment isn't working in editor or frontend either.

These are the caveats I mentioned in the PR description. It's not implemented on trunk either at the moment, and I believe it deserves a broader discussion UX-wise. How do we handle cases with multiple buttons? Should we only be able to align the group? Or buttons individually?

lezama · 2025-01-23T18:24:54Z

Got this after loading this PR over an existing Contact Form. It could be my stack.

monsieur-z · 2025-01-24T14:57:33Z

Thanks for the feedback @lezama. I didn't see any errors in my compatibility testing but I'll give it another go to be sure. By any chance, would you know which branch you were running when you created the form?

lezama · 2025-01-24T15:00:59Z

I think I was running trunk, maybe from a couple of days ago, not sure 😅

talldan · 2025-01-28T06:34:21Z

Got this after loading this PR over an existing Contact Form. It could be my stack.

I'm also seeing this in my local docker env. It happens on trunk too for me. 🤔

It could also be my stack 😄

coder-karen

Thanks for working on this!

I gave this a test and noticed different results with different themes so decided to focus on one in particular as I was confused by the results. I wasn't sure if it was environment based as well but I'll share what I found below.

I created a test post with a contact form, Eventbrite, Mailchimp and Calendly block on it using Jurassic Ninja, locally, and on a Simple site. I used the Twenty Twenty theme.

Local development env, and Simple:
Before applying the PR, the buttons were left-aligned in the editor by default, after applying now they are centre aligned (unless alignment settings had been added, in which case those alignments were respected).

Here's an example of how this affected the Register button, with screenshot showing before and after:

Afer:

After, while the pre-existing widths have been respected, the display is different - for example the default with the Mailchimp button was full-width, now it's less than full-width.

Jurassic Ninja:

This is where I think there may have been some environmental differences or issues related to using the beta tester plugin. Before applying the changes, the width alignment settings all worked apart from the contact submit button (which I understand is expected). Left aligned by default.
After, alignment is unusual - it's central but off-centre depending on width in the editor, but still left aligned in preview.

Generally, should these differences be expected?

github-actions · 2025-01-29T23:12:50Z

Code Coverage Summary

Coverage changed in 3 files.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/jetpack/extensions/blocks/button/apply-fallback-styles.js	0/6 (0.00%)	-16.67%	1 💔
projects/plugins/jetpack/extensions/blocks/button/edit.js	8/9 (88.89%)	-2.02%	0 💚
projects/plugins/jetpack/extensions/blocks/button/button.php	0/116 (0.00%)	0.00%	-4 💚

Full summary · PHP report · JS report

monsieur-z · 2025-02-01T01:22:57Z

Thanks for the review @coder-karen. Good catch, the issues you mention seem to be related to older themes, which use the data-align attribute instead of the align* classes. All CSS changes were therefore not applied. The updates I made to the PR should fix that.

I also had to increase the CSS specificity of some Jetpack button selectors so the styles are applied as expected on older and newer themes. It feels sketchy but I see no other way around.

I've tested with the Twenty Twenty, Twenty Twenty-Four, and Twenty Twenty-Five themes. The former uses the float property to align buttons so the layout is easy to mess up. What other themes have you used for testing?

Setting the width should work on all buttons (except for the Recipe block, which I excluded from the testing instructions). Setting the alignment doesn't work for buttons in the same row: in our case the Payments Buttons and Paid Content blocks. But it doesn't seem it ever worked properly. I don't want to tackle all issues in this PR, so as long as it doesn't make any blocks worse, I'd say let's ship it.

The width/alignment should be the same in the editor and front end.

monsieur-z · 2025-02-01T01:29:00Z

@talldan and @lezama: I still haven't been able to reproduce the warning you're both seeing. Is there any other information you could think of that'd be relevant?

Locally, I tried adding a new Contact form to a post while on trunk, then checking out this branch and rebuilding the forms package. Reloading the post didn't trigger any warning. I also tried switching from the latest plugin stable version to this branch with a JN site. Same results.

talldan · 2025-02-03T01:01:40Z

I still haven't been able to reproduce the warning you're both seeing. Is there any other information you could think of that'd be relevant?

It seems to have gone away now after a clean and rebuild. Sorry, I should've posted an update here.

talldan

In general, this seems to be working much better than trunk, so I think I'd be inclined to merge it and if there are some small things that are still not working they can be fixed in follow up PRs. I went through the code pretty thoroughly and there are a lot of changes, but all explained fairly well.

There are still some oddities, but I think they're out of scope for this PR, and same behavior is mostly present in trunk:

Width control - it was mentioned by others, but the way the width split button disappears when a left/right alignment is set feels like a bug.
Payment Button(s) - The way Payment Button wraps Jetpack Button is quite confusing. The innermost Button has width and alignment options, but alignments don't work (in trunk or in this PR), and I don't see how they would given the Payment Button(s) blocks use a flex layout. Let me know if there's something I missed in my testing here.

coder-karen

Thanks for the follow-up! I did a little more testing and I imagine the main thing that might generate some support requests is the change to default behavior (for Mailchimp, Calendly, Eventbrite buttons, also Contact Us depending on theme), which in my testing again just now were full-width in the editor and front-end before and now are not. That's based on the themes I looked at anyway. The new default behavior makes sense given the changes in this PR, I can't imagine there's any way around this though.

I did notice that with Twenty Twenty the Register / Contact Us alignment issue I'd mentioned before is not an issue anymore - they're side by side in the editor - but in preview they're where they should be (one right aligned, the other the line below but left aligned). It seems like this could be theme specific though.

So I agree with the previous approval, it looks like any possible iterations could be followed up with separately.

github-actions bot added [Block] Button [Block] Contact Form Form block (also see Contact Form label) [Feature] Contact Form [Package] Forms [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Status] In Progress labels Jan 16, 2025

github-actions bot added the [Status] Needs Author Reply We would need you to make some changes or provide some more details about your PR. Thank you! label Jan 16, 2025

monsieur-z commented Jan 17, 2025

View reviewed changes

github-actions bot added [Block] Calendly [Block] Eventbrite [Block] Mailchimp [Block] Paid Content aka Premium Content [Block] Payments aka Unified Intro labels Jan 17, 2025

monsieur-z commented Jan 17, 2025

View reviewed changes

monsieur-z added the [Type] Bug When a feature is broken and / or not performing as intended label Jan 20, 2025

monsieur-z self-assigned this Jan 20, 2025

monsieur-z force-pushed the fix/jetpack-button-styling branch from 48fba64 to 27b3cb7 Compare January 21, 2025 20:24

monsieur-z marked this pull request as ready for review January 21, 2025 20:39

monsieur-z requested a review from a team January 21, 2025 20:39

monsieur-z added [Status] Needs Team Review and removed [Status] Needs Author Reply We would need you to make some changes or provide some more details about your PR. Thank you! [Status] In Progress labels Jan 21, 2025

talldan mentioned this pull request Jan 22, 2025

Fix Buttons inside Form blocks to not be full width on the front end #41236

Open

3 tasks

talldan requested review from tellthemachines and aaronrobertshaw January 22, 2025 08:44

edanzer mentioned this pull request Jan 23, 2025

Form: Fix form block alignment by removing contact form wrapping <div> element #41274

Merged

3 tasks

talldan mentioned this pull request Jan 24, 2025

Fix button block contrast checker #41294

Open

3 tasks

coder-karen reviewed Jan 29, 2025

View reviewed changes

monsieur-z added [Status] In Progress and removed [Status] Needs Team Review labels Jan 29, 2025

monsieur-z added 6 commits January 29, 2025 18:02

Jetpack button: fix width and alignment setting

f6b6a18

changelog

5ae4e2d

Update styles of components using jetpack/button

131e43c

Move align styles in mixin

e26c2e2

Add align support for older themes

d8e29f2

Add missing code after rebase

96f6304

monsieur-z force-pushed the fix/jetpack-button-styling branch from 27b3cb7 to 96f6304 Compare January 29, 2025 23:04

talldan mentioned this pull request Jan 30, 2025

Forms: Field styles broken in the editor e.g. width, gap spacing etc. #41414

Closed

monsieur-z added 2 commits January 31, 2025 12:51

Fix unmerged conflict

5f70361

Fix alignment for payment buttons

c4b781a

talldan approved these changes Feb 3, 2025

View reviewed changes

coder-karen approved these changes Feb 3, 2025

View reviewed changes

monsieur-z merged commit e658a26 into trunk Feb 4, 2025
63 of 64 checks passed

monsieur-z deleted the fix/jetpack-button-styling branch February 4, 2025 18:57

github-actions bot removed the [Status] In Progress label Feb 4, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Jetpack button: fix width and alignment settings #41139

Jetpack button: fix width and alignment settings #41139

monsieur-z commented Jan 16, 2025 •

edited by simison

Loading

github-actions bot commented Jan 16, 2025 •

edited

Loading

github-actions bot commented Jan 16, 2025 •

edited

Loading

monsieur-z Jan 17, 2025

talldan Jan 22, 2025 •

edited

Loading

talldan Jan 24, 2025

monsieur-z Jan 17, 2025

monsieur-z Jan 17, 2025

monsieur-z Jan 17, 2025

talldan Feb 3, 2025 •

edited

Loading

monsieur-z Jan 17, 2025

monsieur-z commented Jan 23, 2025

monsieur-z commented Jan 23, 2025

lezama commented Jan 23, 2025

monsieur-z commented Jan 24, 2025

lezama commented Jan 24, 2025

talldan commented Jan 28, 2025 •

edited

Loading

coder-karen left a comment

github-actions bot commented Jan 29, 2025 •

edited

Loading

monsieur-z commented Feb 1, 2025

monsieur-z commented Feb 1, 2025

talldan commented Feb 3, 2025

talldan left a comment

coder-karen left a comment


		usePassthroughAttributes( { attributes, clientId, setAttributes } );
		useWidth( { attributes, disableEffects: isWidthSetOnParentBlock, setAttributes } );

Jetpack button: fix width and alignment settings #41139

Jetpack button: fix width and alignment settings #41139

Conversation

monsieur-z commented Jan 16, 2025 • edited by simison Loading

Proposed changes:

Other information:

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

github-actions bot commented Jan 16, 2025 • edited Loading

github-actions bot commented Jan 16, 2025 • edited Loading

monsieur-z Jan 17, 2025

Choose a reason for hiding this comment

talldan Jan 22, 2025 • edited Loading

Choose a reason for hiding this comment

talldan Jan 24, 2025

Choose a reason for hiding this comment

monsieur-z Jan 17, 2025

Choose a reason for hiding this comment

monsieur-z Jan 17, 2025

Choose a reason for hiding this comment

monsieur-z Jan 17, 2025

Choose a reason for hiding this comment

talldan Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

monsieur-z Jan 17, 2025

Choose a reason for hiding this comment

monsieur-z commented Jan 23, 2025

monsieur-z commented Jan 23, 2025

lezama commented Jan 23, 2025

monsieur-z commented Jan 24, 2025

lezama commented Jan 24, 2025

talldan commented Jan 28, 2025 • edited Loading

coder-karen left a comment

Choose a reason for hiding this comment

github-actions bot commented Jan 29, 2025 • edited Loading

Code Coverage Summary

monsieur-z commented Feb 1, 2025

monsieur-z commented Feb 1, 2025

talldan commented Feb 3, 2025

talldan left a comment

Choose a reason for hiding this comment

coder-karen left a comment

Choose a reason for hiding this comment

monsieur-z commented Jan 16, 2025 •

edited by simison

Loading

github-actions bot commented Jan 16, 2025 •

edited

Loading

github-actions bot commented Jan 16, 2025 •

edited

Loading

talldan Jan 22, 2025 •

edited

Loading

talldan Feb 3, 2025 •

edited

Loading

talldan commented Jan 28, 2025 •

edited

Loading

github-actions bot commented Jan 29, 2025 •

edited

Loading