[Mamaduka]

What?

Closes #9009
Closes #10791

Removes the column count slider and the warning notice shown above six columns from the Columns block settings. Columns are now added and removed with the standard insert and delete actions.

Why?

The slider was a second path to a structural edit that block insertion already owns. It carried its own width redistribution code to repair state the normal insert path never creates. No other block shipped a control like this, so the change is contained to Columns.

Testing Instructions

1. Open a post or page.
2. Insert a Columns block and choose the 50 / 50 layout. Add a paragraph in each column.
3. Select the first column. In the block toolbar, press the plus button next to the "Columns" parent button. A new empty column is inserted after the first one, and the two existing columns keep their content.
4. Select the Columns block and open block settings. Only "Stack on mobile" is listed.
5. Select a column and delete it from the Options menu. The remaining columns keep their content.
6. Add templateLock: "all" to the Columns block via the code editor, reload, and select a column. The plus button is not rendered.

Testing Instructions for Keyboard

Same.

Use of AI Tools

Assisted by Claude.

[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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @GhostPirateBob, @eddhurst, @msdesign21, @aamills, @sitetherapy, @burnuser, @realworldev, @andrewstaffell, @NicoHood, @webfolkcreative, @mizukimadness.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: GhostPirateBob, eddhurst, msdesign21, aamills, sitetherapy, burnuser, realworldev, andrewstaffell, NicoHood, webfolkcreative, mizukimadness.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: bfintal <bfintal@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: strarsis <strarsis@git.wordpress.org>
Co-authored-by: draganescu <andraganescu@git.wordpress.org>
Co-authored-by: melchoyce <melchoyce@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: SteveRyan-ASU <tfserwin@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: florianbrinkmann <florianbrinkmann@git.wordpress.org>
Co-authored-by: hacknug <hack_nug@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>
Co-authored-by: amjadr360 <amjadr360@git.wordpress.org>

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

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: -621 B (-0.01%)

Total Size: 8.22 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-library/index.min.js	365 kB	-621 B (-0.17%)

_{ea88a08 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	7cbe247	trunk	% Change
timeToFirstByte	54.85 ms +3.83% -1.55%	55.95 ms +5.18% -2.95%	-1.97%
largestContentfulPaint	88 ms +6.82% -0%	88 ms +15.91% -0%	0%
lcpMinusTtfb	33.9 ms +4.42% -3.54%	33.7 ms +31.31% -7.72%	0.59%
wpBeforeTemplate	27.75 ms +1.37% -1.87%	27.75 ms +7.64% -1.77%	0%
wpTemplate	23.72 ms +2.66% -2.45%	23.79 ms +6.68% -3.03%	-0.29%
wpTotal	51.44 ms +3.89% -1.85%	52.36 ms +5.21% -2.94%	-1.76%
wpMemoryUsage	7.61 MB +0% -0%	7.57 MB +0% -0%	0.51%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	7cbe247	trunk	% Change
timeToFirstByte	43.35 ms +5.77% -3.69%	46.65 ms +4.18% -1.71%	-7.07%
largestContentfulPaint	92 ms +4.35% -4.35%	100 ms +4% -2%	-8%
lcpMinusTtfb	46.95 ms +8.84% -0.96%	53.4 ms +1.69% -4.4%	-12.08%
wpBeforeTemplate	26.12 ms +7.47% -1.72%	26.04 ms +1.54% -1.92%	0.31%
wpTemplate	13.4 ms +6.87% -1.49%	17.65 ms +2.1% -1.98%	-24.08%
wpTotal	40.65 ms +5.63% -3.86%	43.69 ms +4.44% -1.97%	-6.96%
wpMemoryUsage	6.09 MB +0% -0%	6.19 MB +0% -0%	-1.64%
wpDbQueries	10 +0% -0%	14 +0% -0%	-28.57%

media-processing

Metric	7cbe247	trunk	% Change
mediaProcessingJpeg	394.68 ms +1.48% -0.23%	395.45 ms +1.52% -0.05%	-0.19%
mediaProcessingAvif	6036.92 ms +0.13% -0.19%	6042.08 ms +0.1% -0.17%	-0.09%
mediaProcessingJpegToAvif	4166.25 ms +0.48% -0.15%	4178.13 ms +0.22% -0.11%	-0.28%

media-upload

Metric	7cbe247	trunk	% Change
jpegUploadProcessing	1412.48 ms +36.28% -1.27%	1435.34 ms +1.72% -1.31%	-1.59%
pngUploadProcessing	177.17 ms +21.14% -1.95%	225.78 ms +10.32% -21.65%	-21.53%
largeJpegUploadProcessing	1412.58 ms +0.63% -0.95%	1406.29 ms +0.46% -0.47%	0.45%
multipleImageUploadProcessing	1564.5 ms +2.52% -1.03%	1591.27 ms +0.01% -0.3%	-1.68%

post-editor

Metric	7cbe247	trunk	% Change
serverResponse	486.39 ms +3.3% -0.71%	506.22 ms +0.63% -6.61%	-3.92%
firstPaint	227.72 ms +25.95% -21.48%	221.98 ms +10.38% -12.26%	2.59%
domContentLoaded	1107.63 ms +3.9% -1.2%	1099.55 ms +0.81% -1.01%	0.73%
loaded	1108.94 ms +3.9% -1.19%	1100.91 ms +0.82% -1.01%	0.73%
firstContentfulPaint	451 ms +2.18% -1.75%	444.31 ms +5.52% -1.89%	1.51%
firstBlock	3362.8 ms +1.45% -1.44%	3333.68 ms +0.61% -0.68%	0.87%
type	18.87 ms +11.55% -7.42%	20.07 ms +9.92% -0.75%	-5.98%
typeWithoutInspector	18.57 ms +10.5% -3.5%	19.11 ms +2.2% -1.31%	-2.83%
typeWithTopToolbar	25.67 ms +3.66% -2.65%	24.62 ms +4.96% -5.12%	4.26%
typeContainer	10.63 ms +6.96% -6.96%	9.5 ms +11.58% -12.32%	11.89%
focus	88.02 ms +3.31% -11.77%	75.1 ms +4.53% -6.5%	17.2%
firstFocus	246.54 ms +0% -0%	218.16 ms +0% -0%	13.01%
selectAll	558.11 ms +4.45% -2.41%	573.95 ms +1.25% -5.25%	-2.76%
listViewOpen	62.87 ms +8.26% -2.04%	66.72 ms +2.29% -6.04%	-5.77%
inserterOpen	23.17 ms +6.95% -2.59%	25.31 ms +8.3% -7.31%	-8.46%
inserterHover	2.24 ms +29.02% -8.93%	2.21 ms +14.48% -8.6%	1.36%
inserterSearch	8.37 ms +8.48% -8.6%	8.23 ms +7.41% -9.6%	1.7%
loadPatterns	652.16 ms +2.39% -5.08%	634.91 ms +4.26% -7.7%	2.72%
wpTotal	476.07 ms +3.56% -0.72%	496.01 ms +0.72% -6.78%	-4.02%
wpMemoryUsage	13.14 MB +0% -0%	13.11 MB +0% -0%	0.28%
wpDbQueries	54 +0% -1.85%	54 +0% -1.85%	0%

site-editor

Metric	7cbe247	trunk	% Change
serverResponse	480.89 ms +7.06% -4.21%	504.6 ms +4.88% -5.66%	-4.7%
firstPaint	262.66 ms +11.2% -18.76%	236.6 ms +14.52% -4.26%	11.01%
domContentLoaded	1163.65 ms +2.19% -1.31%	1143.88 ms +0.99% -1.78%	1.73%
loaded	1165.05 ms +2.17% -1.31%	1145.09 ms +1% -1.77%	1.74%
firstContentfulPaint	468.92 ms +1.25% -1.76%	450.59 ms +2.59% -4.39%	4.07%
firstBlock	4196.02 ms +0.77% -0.41%	4157.3 ms +0.52% -0.61%	0.93%
type	18.58 ms +7.32% -4.14%	18.43 ms +4.34% -3.58%	0.81%
navigate	110.19 ms +2.75% -1.41%	115.99 ms +7.47% -2.77%	-5%
loadPatterns	1287.33 ms +2.86% -2.81%	1373.72 ms +14.24% -6.1%	-6.29%
loadPages	1061.9 ms +2.42% -1.13%	1064.58 ms +3.99% -1.15%	-0.25%
wpTotal	470.81 ms +7.27% -4.16%	494.86 ms +4.91% -5.83%	-4.86%
wpMemoryUsage	12.11 MB +0% -0%	12.09 MB +0% -0%	0.13%
wpDbQueries	43 +2.33% -0%	43.5 +1.15% -1.15%	-1.15%

_{ea88a08 Run}

[jasmussen]

Thanks for the ping and the work! I'm curious what others feel based on this.

The motivation certainly seems valid, but if I'm fully understanding the nuance, I'm wondering also if it's the right approach. From my POV, the slider is an extremely ergonomic way to add or remove columns, and it's not clear to me that it's "destructive" as far as the content goes. Undo still works, even revision history does. The risk by removing these tools is that we are patching over a more foundational issue: if people don't understand how undo works or that it exists, is there an aspect we are missing? Are entries not added correctly, does the shortcut not work consistently? Is the revision history button too hidden, is the revision interface itself too hard to work with? On my mind also since @talldan is working on a new Table block that will also require the ability to both add and remove columns and rows. Not fully the same as far as having column sliders (though perhaps it should be?)—but probably the same as far as questions around "destructive edits".

[Mamaduka]

I think the Columns and Table blocks are outliers here. They follow different patterns than the other parent blocks, though I don't think that can be avoided for the Table block.

The column count control is inconsistent with other block add/remove methods:

• It limits columns to 6, even though you can still insert more using appenders.
• Allows rapid removal of blocks, when usually block deletion is an explicit action.

I don't think undo is the main problem here. The #9009 is an old issue, and history handling has improved a lot in the last 8 years.

[t-hamano]

Personally, I think we can move forward with this PR and see what kind of feedback we get from users, as it does not introduce any breaking changes. This slider might be a relic from a time when core blocks and the UI were still underdeveloped.

If anything, what I'm dissatisfied with is the placeholder. I've never used any variations other than 100 and 50/50 😅

It would be great if we could enter the number of columns directly in the placeholder. That way, the column count slider would feel even less necessary.

[talldan]

On my mind also since @talldan is working on a new Table block that will also require the ability to both add and remove columns and rows. Not fully the same as far as having column sliders (though perhaps it should be?)—but probably the same as far as questions around "destructive edits".

For the table block it's probably a more obvious action. The user selects particular columns or rows to delete them. There's not really a slider on the parent that controls the column/row count (that's only in the placeholder). The same is true with the block today in trunk. The only thing that came up in the POC PR is if a user selects partially selects multiple rows and then deletes the entire rows that might need to be clearer.

edit: In terms of adding sliders on the parent table block, I'm not sure personally. I don't think that's a common pattern with tables. A lot of the time, users also don't only want to remove from or add to the end, especially if they've already entered data.

[Mamaduka]

Should we land this? To me, it seems there's no strong argument against removing the control.

[t-hamano]

I think we can ship this. Let's see what users think during the 7.2 beta phase.