Prevent deleting blocks entirely when removing columns

[amjadr360]

Describe the bug Whenever I change 3 columns into 2 the 3rd one gets eliminated along with its content. Instead 3rd column content should shift into next row. I can get my 3rd column's content by doing undo but it is not a good approach and even I do undo Columns option sate stay on 2 and when I hit update 3rd column content get deleted.

Screenshots Here screen record. https://drive.google.com/file/d/1gAxuRi7FPFMKWwoDtMYlkpQxXP2F1Gjm/view?usp=sharing

To Reproduce Steps to reproduce the behavior:

1. Go to 'edit post'
2. Add three columns and add content inside all of them.
3. Then change 3 columns to 2 columns
4. You will see 3rd columns will eliminate along with its content.

Expected behavior Instead got eliminated 3rd column content should shift into next row.

Desktop (please complete the following information):

• OS: [Windows]
• Browser [Chrome, safari]

Additional context Wordpress Version 4.9.8 Gutenberg Version 3.5.0

[GhostPirateBob]

Congratulations on open issue 1000! 🎉🎉🎉🎉

[eddhurst]

Quick note to say that I can replicate this, see gif.

Replicated on:

Desktop: OS: Mac Sierra 10.12.6 Browser: Chrome Version: 69.0.3497.100

Additional context Gutenberg 3.9

[bfintal]

An issue I see is if the expected behavior is to merge the disappearing column's contents with the last content is that all the content would pile up and make the UI a mess. Then ideally, if all the disappearing content gets piled up in the 2nd column, changing it back to 3 columns should also undo the piling up. This might complicate things.

I would like to suggest an alternative behavior: just make the disappearing column's content hidden but still there. In the scenario, when the column count is set from 3 to 2, the content of the 3rd column would just be hidden. Then when the column is brought back to 3, it would just be present again. It would be up to the user to move things around.

[youknowriad]

I think this needs to be improved design-wise. Ideally removing a column is an explicit action (clicking a "x" or something like that) instead of a range input.

[ghost]

Can I also add to this that the range input should be removed, as if it is set to 2, and I have content in both my columns, I can click on this input, and delete the value and then proceed to type a different number (3 for example).

The result I am left with, because I deleted the value of 2, is that ALL of my column content is deleted and lost.

[strarsis]

I have a similar issue: Example: There are 4 columns. The 3rd column may be completely empty. 'When now reducing the column count of the columns block, the 4th column should become the 3rd column. Instead, currently the 4th column is simply removed while retaining the 3rd empty column.

Additionally, a method for swapping or reordering the columns would be a nice addition.

[draganescu]

in support of @leecollings:

Describe the bug

When we alter the number of columns using the input instead of the slider the content is not saved.

To reproduce

Steps to reproduce the behavior:

• In a post or page
• Add a column block
• Write some text in both blocks -Select the columns block
• Modify the number of columns in the inspector by changing the number in the input, instead of the slider, e.g. instead of 2, delete 2 and write 3
• Content is gone.

Expected behavior

To behave like the slider:

• If I am adding columns the content remains
• If I am removing the content is deleted RTL
• If I add the same number the content is saved

[melchoyce]

I think part of the problem here is I expect the columns to act like a grid — if I have three columns of content and reduce that number to two, I expect that third column to drop down into a new row beneath the top-left column. If I then set my columns back up to three, I expect that dropped column to flow back up into the original row:

Edit: Maybe we just need a grid block?

[msdesign21]

Grid block sounds interesting!

[aamills]

I was able to replicate the disappearing content when reducing columns on WordPress 5.6 plain vanilla install with no plugins, on Chome Version 87.0.4280.141 (Official Build) (64-bit), and on the WordPress app, version alpha-266.

I think my mind expected it to work exactly as Mel described here. Would love to see that implemented!

[stokesman]

I've put together a PR (#34893) that should resolve this and it can be tested out at http://gutenberg.run/34893. I'd appreciate any feedback.

[sitetherapy]

This still exists and is exacerbated for Safari users by the Range Control bug https://github.com/WordPress/gutenberg/issues/32497 which makes it very easy to accidentally decrement the number of columns, losing data.

Expected behavior for me would be to preserve the content of the removed columns until save. If I save, it's not unreasonable to assume that I meant to also delete the contents of the removed column. Pre-save, though, I could have simply made a mistake.

@stokesman - i get "Invalid Pull Request" at http://gutenberg.run/34893.

[stokesman]

@sitetherapy, are you saying you are unable to restore the content by using undo? If that does work, I realize it's still far from ideal. Especially in combination with the bug from #32497.

Thanks for trying to test that PR and the heads up that it's no longer working. I guess with time PRs may become outdated and won't run on Gutenberg.run. I'd still like to revisit that PR but don't have much time lately.

[sitetherapy]

@stokesman - I can use the revisions to get back the content so undo might work (I'll try later) but for me the natural reaction was to increment the number of columns back to what it was.

My concern is two fold. One, that we have a bug that loses data and it's still open and two, while I can figure this out, I can't see asking a client to deal with this - "Oh yes, you lost data. Sorry about that. The block editor is kind of... not quite baked."

EDIT: Yes, Undo brings back the columns and their data, one undo per column deletion being needed, i.e. if you removed 2 columns, you need to choose Undo twice.

[stokesman]

@sitetherapy, thanks for confirming that undo works. As far as I can tell that's what has allowed this issue to languish. I've made PR #38840 for the (Safari) bug with the columns control so at least the potential to delete columns inadvertently can be lessened.

[sitetherapy]

The frustrating thing about this languishing is that, since Undo works, re-adding columns should also - the data is still there, just check for it when re-adding columns. It's completely natural to think "Oh dammit, I didnt mean to delete that column" and click to increment the column count back up, expecting the data to still be there. Hell, I did that and I'm technically savvy.

[burnuser]

As reported in https://github.com/WordPress/gutenberg/issues/47330 I suggest a very simple solution to reduce columns or make a complete undo of columns in a logical revert of Columns-creation from existing Blocks without any loss of content:

At start we have 4 regular blocks (could also be groups) in regular vertical layout: A B C D

Selecting them all and converting to a columns block results in new horizontal layout: A / B / C / D

Reducing our columns from 4 to 2 could - without any loss of content - result in a columns block and 2 regular blocks in vertical layout as before the creation of columns, by inserting the superfluous columns - from right to left, one by one - as regular content straight after the columns block: A / B C D

And a new command "Undo columns" extends this behaviour to the complete columns block and brings us - without any content change or tedious manual work - back to the start: A B C D

[annezazu]

Adding this to the Polish board as this definitely wears on the experience of those using the block editor, especially as layouts get more complex with the Site Editor. Marking as needs design for now as it doesn't quite seem as though we have a set determined way to move forward.

[richtabor]

Marking as needs design for now as it doesn't quite seem as though we have a set determined way to move forward.

Just noting that I'd prefer if the items in the Polish board are entirely actionable. Perhaps there shouldn't be "Needs design" issues at all to be honest. I don't think we have a clear way to handle this (although "Undo" does work here).

[richtabor]

Technically, would the solution be:

If I reduce the number of columns, the blocks within in the deleted columns are temporarily stored, to be restored if I increase the columns count again, in the same session?

[stokesman]

I’m thinking this is a design issue and wondering if removing the columns slider would be the best solution. All other blocks that I know of featuring a "Columns" slider use it to change layout whereas this actually removes/inserts blocks.

It may have had more value in the past as I'm not sure all ways to insert/delete columns existed when it was first implemented. As of now it’s redundant. To insert another column, there are in-between inserters, pressing Enter with a Column block selected, or the "Add After" menu option/keyboard shortcut. For removing them there is pressing Backspace/Delete keys and the "Delete" menu option/keyboard shortcut.

[sitetherapy]

REALLY? We have a bug that loses data, that is SIX years old and which has had some reasonable suggestions on fixes for at least the last two years and an open PR that's 3 years old... And it's OPEN?

Folks, this is why some of us are very leery about the Block Editor. I get that some design thought on both the technical and UX sides was needed but a bug that loses data going unaddressed like this does not inspire confidence.

[stokesman]

@sitetherapy: I agree but implore anyone interested in doing better than merely complaining about it. If you please, how do you feel about the latest suggestion I made of removing the columns slider? It would solve this issue with the least technical challenges but the question would be if the columns slider would be missed. To me, it doesn’t seem that convenient and that other ways of increasing or decreasing the number of columns are adequate.

[sitetherapy]

Your idea is fine. But given the lack of any movement for years…

I’m not complaining, really but there’s only so much people without commit access can do. At some point someone on the team needs to either assign this out and implement a fix or accept the PR linked above. That neither has been done in, literally, years for a bug that can cause data loss kind of amazes me.

Rick On Aug 21, 2024 at 11:48 AM -0700, Mitchell Austin @.***>, wrote:

@sitetherapy: I agree but implore anyone interested in doing better than merely complaining about it. If you please, how do you feel about the latest suggestion I made of removing the columns slider? It would solve this issue with the least technical challenges but the question would be if the columns slider would be missed. To me, it doesn’t seem that convenient and that other ways of increasing or decreasing the number of columns are adequate. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[stokesman]

there’s only so much people without commit access can do

Indeed, though commit access is a mere toothpick 😁. My intention was to point out that for feedback to be more valuable it should include suggestions or questions/critique of previous suggestions. That’s why I asked for your opinion on a specific and I appreciate your response.

---

If I reduce the number of columns, the blocks within in the deleted columns are temporarily stored, to be restored if I increase the columns count again, in the same session?

@richtabor, I think it’s still a UX snag when one decreases the columns and sees that content disappears. If that content is wanted, action is still needed to correct.

Your suggestion is like that previously shared by a couple folks (https://github.com/WordPress/gutenberg/issues/9009#issuecomment-498070095, https://github.com/WordPress/gutenberg/issues/9009#issuecomment-1400014901) and I think theirs may be better from a UX standpoint since the content won’t disappear. Maybe it is the best solution, but still perhaps with a little potential for confusion and technical challenge.

I do have an idea that I think combines well with yours. When content is removed, a notice of some sort could be added that offers a "Copy to clipboard" action and maybe "Undo" too. I did have a branch like that but on an old machine. There’s more design and technical work that goes along with it and given the lack priority this issue has had I'm not that confident pursuing it.

---

I’ve linked #64722 that removes the "Columns" slider and seems the simplest route to resolve this issue.

[annezazu]

@ellatrix as this might make for a good issue as part of the work you're doing with writing flow and polish: https://github.com/WordPress/gutenberg/issues/63255 I've definitely come across this personally and was frustrated by needing to use undo to get my content back when some of the time I was simply messing around to visually see how many columns I wanted.

[richtabor]

@richtabor, I think it’s still a UX snag when one decreases the columns and sees that content disappears. If that content is wanted, action is still needed to correct.

Yes, but you're right there manipulating the controls. If you increase the column count then you'll see your content back again. Let's start there, and then test to see if folks are not able to recover content. If so, we can consider a snackbar notice, but it could be more confusing drawing you attention elsewhere.

[stokesman]

I don’t think allowing deletion of content from this control is desirable in the first place. It seems more a bug to me especially with regards to how "Columns" sliders work on other blocks where it’s not possible to delete content. Even if considered a "feature", it’s half-baked because it doesn’t allow removing columns from the starting end.

I agree with Riad’s statement https://github.com/WordPress/gutenberg/issues/9009#issuecomment-461327160:

Ideally removing a column is an explicit action (clicking a "x" or something like that) instead of a range input.

Though with an exception that it’d be okay to remove columns that are empty or unlocked which is how #34893 works.

I do see how deleting multiple columns with content at once can be desirable but that’s already possible via multi-select. If that isn’t sufficient and there’s demand for such a control, it would have to be one that’s more capable than a slider and it’d neither be terrible simple to use nor to implement.

[richtabor]

I don’t think allowing deletion of content from this control is desirable in the first place. It seems more a bug to me especially with regards to how "Columns" sliders work on other blocks where it’s not possible to delete content. Even if considered a "feature", it’s half-baked because it doesn’t allow removing columns from the starting end.

There's certainly a case for deciding you want more or less columns than the first time you picked an integer value.

Ideally removing a column is an explicit action (clicking a "x" or something like that) instead of a range input.

I lean towards that complicating things. We already have "Delete" at the block level for removing blocks.

This concept is not about stopping you from deleting columns, but having an intuitive affordance for getting content back, should you have unintentionally deleted.

I don't want to complicate the problem to solve (if you remove a column, you can add it back using the same UI/X that you used to remove it), nor the expectation of the columns block (you can change the column count to whatever you'd like).

[stokesman]

There's certainly a case for deciding you want more or less columns than the first time you picked an integer value.

We’re agreed on that. My comment was apparently misunderstood.

Ideally removing a column is an explicit action (clicking a "x" or something like that) instead of a range input.

I lean towards that complicating things. We already have "Delete" at the block level for removing blocks.

I didn’t infer that Riad was suggesting the addition of another way to delete but pointing out how the slider can make for poor UX due to lack of explicitness.

I don't want to complicate the problem to solve (if you remove a column, you can add it back using the same UI/X that you used to remove it), nor the expectation of the columns block (you can change the column count to whatever you'd like).

I agree 100% given the context is a Columns block with empty columns. For a column with content, it seems safer to assume it is not be removed. Even if one expects the control to remove content-having columns, it can serve only in the specific case where the columns to be removed are the ones at the end. That feels like an incomplete affordance and of less value than having the control avoid deleting content and the potential bother of corrective action.

I appreciate your willingness to discuss this Rich and will strive to write clearly in hopes we can avoid any more misunderstanding. It’s fine too if we simply have different perspectives on what’s important. Perhaps we can get others to lend their thoughts.