Try: Add the block alignment control to inspector, hide on text blocks.

[jasmussen]

What?

Alternative to #83945. Based on discussion there, and in Slack.

What this PR does:

• Adds a block alignment option, not shown by default, to the "Layout" toolspanel.
• Shows the Layout toolspanel for any block that is able to have block alignments.
• Removes the alignment dropdown from text blocks, inc. Paragraph and Quote.

Why?

There's a long story to this. It starts with the suggestion that the block toolbar is a curation mechanism, a place where the most important actions are contextually available, right there. But while also deliberately omitting others, that are perhaps not as important to a particular flow. Making a full-wide paragraph, for example, can be argued as needing to be possible, but it is also easy to argue that it should not be a primary or common interaction.

The inspector on the other hand is a good home for more advanced interactions, and is therefore a good home for it. The Layout panel already features justification options. It's a way to make the actions available, while managing their footprint and curation.

And in fact in developing this PR it became clear that managing that footprint is even more important. Consider the screenshot above, it shows a wide paragraph inside a Group. But the paragraph is not wide, it's bounded by the limited width of the group. There's no visual indication that anything is wide, so it's arguably misleading. And yet it's accurate: if you expanded the width of the group, the paragraph would expand with it, until reaching its bounded width. So it's intended, and immensely confusing.

That same confusion is documented in wp.com support sessions too, issues that I've previously tried to fix in these PRs:

• Hide alignment control when nothing available. #83265
• Block alignment: Explain when the template is what limits a block's w… #82675
• Editor: Describe the post title in the sidebar instead of "No block selected" #82673
• Add/block width constraint notice #82607

#79285 is related.

All of those are meant to mitigate confusion around someone setting a block to being wide or fullwide, and not seeing any result at all.

Testing Instructions

• Add a Paragraph. Its toolbar has no block alignment control, only text alignment.
• Open the block inspector, Layout panel, ⋮ menu, and enable Alignment. Set Wide width. The paragraph goes wide.
• Add a Group. Its toolbar still has the alignment control, and its Layout panel offers Alignment as well.
• Nest a Paragraph in an unaligned Group and set it to Wide. Nothing visible changes — the Group caps it. Set the Group to Wide and the Paragraph expands.

Use of AI Tools

Opus 5, and my bot has a couple of notes it would like to surface as open questions:

• The support name. alignToolbar follows alignWide. The alternative is growing align into an object ({ wide: true, full: true, toolbar: false }), consistent with how color and typography grew, but a larger public API change.
• Where the text line falls. Comments Title and Query Total are included as text; Post Content is excluded as a container despite having a text-alignment control.
• Add/block width constraint notice #82607 and Block alignment: Explain when the template is what limits a block's w… #82675 now depend on this. Both put their width-constraint explanation inside the toolbar alignment dropdown, which these fourteen blocks no longer have. The affordance needs porting into the inspector select, or text blocks lose the explanation where it is most needed.

[github-actions]

🤖 PR meta 🤖

🎉 Props

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: jasmussen <joen@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

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

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: +478 B (+0.01%)

Total Size: 8.25 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	516 kB	+369 B (+0.07%)
build/scripts/block-library/index.min.js	366 kB	+68 B (+0.02%)
build/styles/block-editor/style-rtl.css	20.4 kB	+16 B (+0.08%)
build/styles/block-editor/style-rtl.min.css	17.2 kB	+5 B (+0.03%)
build/styles/block-editor/style.css	20.5 kB	+15 B (+0.07%)
build/styles/block-editor/style.min.css	17.2 kB	+5 B (+0.03%)

_{e32fb79 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	9e2ee9b	trunk	% Change
timeToFirstByte	61.25 ms +9.8% -1.88%	56.35 ms +8.52% -1.69%	8.7%
largestContentfulPaint	104 ms +0% -7.69%	96 ms +6.25% -4.17%	8.33%
lcpMinusTtfb	37.35 ms +10.04% -5.62%	36.5 ms +22.6% -7.4%	2.33%
wpBeforeTemplate	30.29 ms +18.85% -3.7%	27.89 ms +12.62% -1.36%	8.61%
wpTemplate	26.48 ms +2.98% -2.91%	24.55 ms +3.3% -1.71%	7.86%
wpTotal	57.35 ms +9.4% -2.37%	52.62 ms +8.89% -1.69%	8.99%
wpMemoryUsage	7.62 MB +0% -0%	7.59 MB +0% -0%	0.47%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	9e2ee9b	trunk	% Change
timeToFirstByte	47.4 ms +6.33% -1.69%	47.45 ms +3.9% -2%	-0.11%
largestContentfulPaint	104 ms +0% -3.85%	102 ms +3.92% -1.96%	1.96%
lcpMinusTtfb	54.05 ms +4.53% -1.3%	53.65 ms +4.57% -0.93%	0.75%
wpBeforeTemplate	26.12 ms +7.35% -1.99%	26.15 ms +3.14% -2.1%	-0.11%
wpTemplate	17.78 ms +3.88% -1.46%	17.84 ms +1.51% -0.67%	-0.34%
wpTotal	44.51 ms +5.93% -2.22%	44.12 ms +4.69% -1.84%	0.88%
wpMemoryUsage	6.25 MB +0% -0%	6.20 MB +0% -0%	0.72%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	9e2ee9b	trunk	% Change
mediaProcessingJpeg	396.5 ms +1.22% -0.46%	398.61 ms +1.7% -0.79%	-0.53%
mediaProcessingAvif	6058.89 ms +0.22% -0.07%	6039.77 ms +0.5% -0.04%	0.32%
mediaProcessingJpegToAvif	4181.84 ms +0.03% -0.14%	4184.25 ms +0.23% -0.37%	-0.06%

media-upload

Metric	9e2ee9b	trunk	% Change
jpegUploadProcessing	1428.03 ms +36.98% -1.44%	1431.17 ms +0.9% -0.68%	-0.22%
pngUploadProcessing	193.05 ms +15.13% -5.92%	197.32 ms +3.66% -2.03%	-2.16%
largeJpegUploadProcessing	1406.26 ms +0.19% -0.23%	1417.21 ms +0.87% -0.53%	-0.77%
multipleImageUploadProcessing	1567.38 ms +1.17% -0.82%	1584.12 ms +10.96% -1.21%	-1.06%

post-editor

Metric	9e2ee9b	trunk	% Change
serverResponse	328.13 ms +4.53% -1.52%	346.17 ms +2.87% -7.52%	-5.21%
firstPaint	176.75 ms +8.51% -21.19%	207.04 ms +9.76% -8.82%	-14.63%
domContentLoaded	847.52 ms +2.12% -0.68%	894 ms +0.77% -2.14%	-5.2%
loaded	848.89 ms +2.07% -0.72%	895.26 ms +0.75% -2.16%	-5.18%
firstContentfulPaint	367.14 ms +2.67% -3.04%	383.42 ms +1.91% -4.98%	-4.25%
firstBlock	2455.33 ms +1.74% -0.72%	2591.94 ms +0.37% -0.47%	-5.27%
type	16 ms +5.06% -3.06%	16.71 ms +7.96% -5.15%	-4.25%
typeWithoutInspector	15.47 ms +5.62% -4.85%	16.15 ms +7.37% -3.47%	-4.21%
typeWithTopToolbar	19.57 ms +2.91% -0.97%	20.66 ms +4.74% -6.87%	-5.28%
typeContainer	7.36 ms +5.43% -6.66%	7.52 ms +11.97% -10.51%	-2.13%
focus	63.62 ms +6.1% -5.19%	66.09 ms +1.66% -7.17%	-3.74%
firstFocus	149.29 ms +0% -0%	197.43 ms +0% -0%	-24.38%
selectAll	429.22 ms +10.82% -3.55%	400.8 ms +5.54% -1.66%	7.09%
listViewOpen	50.55 ms +6.82% -12.88%	49.3 ms +10.85% -4.36%	2.54%
inserterOpen	20.3 ms +4.98% -11.38%	19.21 ms +18.79% -6.77%	5.67%
inserterHover	2.09 ms +5.26% -10.05%	2.31 ms +11.69% -13.42%	-9.52%
inserterSearch	7.37 ms +5.43% -7.6%	7.28 ms +14.01% -7.14%	1.24%
loadPatterns	565.94 ms +5.27% -4.3%	526.66 ms +4.75% -2.53%	7.46%
wpTotal	318.04 ms +4.68% -1.11%	337.19 ms +2.63% -7.78%	-5.68%
wpMemoryUsage	13.17 MB +0% -0%	13.13 MB +0% -0%	0.29%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	9e2ee9b	trunk	% Change
serverResponse	517.48 ms +5.15% -3.98%	501.8 ms +5.1% -5.34%	3.12%
firstPaint	266.46 ms +22.55% -10.88%	243.23 ms +5.48% -5.16%	9.55%
domContentLoaded	1190.49 ms +1.85% -1.16%	1166.64 ms +0.81% -0.45%	2.04%
loaded	1191.99 ms +1.84% -1.17%	1167.97 ms +0.83% -0.47%	2.06%
firstContentfulPaint	470.34 ms +3.95% -2.75%	472.56 ms +1.64% -1.5%	-0.47%
firstBlock	4353.27 ms +0.31% -1.5%	4267.2 ms +0.87% -1.14%	2.02%
type	19.42 ms +5.92% -2.32%	17.87 ms +16.28% -2.18%	8.67%
navigate	120.8 ms +14.05% -5.31%	123.97 ms +4.35% -6.33%	-2.56%
loadPatterns	1376.34 ms +1.95% -2.17%	1347.06 ms +12.9% -1.35%	2.17%
loadPages	1067.6 ms +1.58% -0.7%	1061.31 ms +3.97% -0.38%	0.59%
wpTotal	507.86 ms +5.19% -4.16%	492.2 ms +5.09% -5.5%	3.18%
wpMemoryUsage	12.15 MB +0% -0%	12.11 MB +0% -0%	0.34%
wpDbQueries	43 +2.33% -0%	43.5 +1.15% -1.15%	-1.15%

_{e32fb79 Run}

🏁 Flaky tests

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.

should select an inline image by clicking it @WebKit @Firefox in /test/e2e/specs/editor/various/adding-inline-tokens.spec.js, passed after 1 failed attempt.

Error: apiRequestContext.fetch: socket hang up
Call log:
  - → POST http://localhost:8889/wp-json/wp/v2/media
    - user-agent: Playwright/1.63.0 (x64; ubuntu 24.04) node/24.18 CI/1
    - accept: */*
    - accept-encoding: gzip,deflate,br
    - X-WP-Nonce: 8790eea018
    - content-type: multipart/form-data; boundary=----WebKitFormBoundarynjDdmtt13NN9XHfU
    - content-length: 284
    - cookie: wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_23778236db82f19306f247e20a353a99=admin%7C1791026186%7Ci0srlGwC39VLW7nuGTlqhsDbosOQks4K06ano65fLoC%7C8e7347fb6062e00ba0cee3f9a6085746c427d957eac1e48743825c2777228281; wp-settings-time-1=1790853462

    at RequestUtils.rest (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/rest.ts:112:39)
    at RequestUtils.uploadMedia (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/media.ts:51:30)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/adding-inline-tokens.spec.js:82:50

_{e32fb79 Run}

[youknowriad]

What if we just show the inspector for all blocks and no block toolbar for all blocks to avoid the extra flag and the differentiation between text blocks or not? Maybe the consistency can help the users no?

[jasmussen]

You mean removing the block alignment from all blocks? If yes, then I'm very hesitant. Block toolbar curation also suggests making images wide and full-wide is a common use case.

I wonder on the justification tools angle if there's something in the layout property on the parent we can use? Probably not since we're mixing flow here.

[youknowriad]

If block alignment is important and we want to keep in the toolbar, maybe we need to rethink the toolbar. I don't think targeting specific blocks solve anything personally when it comes to block size, other blocks will also have the same issues.

[jasmussen]

Based on the feedback, closing this one alongside #83945. Thanks all, for looking.