Batch editing

[bastianallgeier]

Changelog

Features

• New option for pages and files sections, to delete multiple files or pages at once https://kirby.nolt.io/38

Enhancements

• New Kirby\Cms\Pages::delete(array $ids) and Kirby\Cms\Files::delete(array $ids) methods to handle batch delete for multiple files in a collection.
• New batch mixin for model sections (pages & files), which introduces the batch option and a computed property to check for supported layouts.
• New selectable property for the <k-item> and <k-items> components. When set to true, the items show checkboxes and emit an select event, when the checkbox is clicked.
• The files and pages sections introduce new delete API endpoints. Those endpoints can take a set of page or file ids and will delete each one. Errors will be caught and sent back in the details array of the final thrown exception.

Breaking changes

• none

Docs

• New batch option for pages and files sections

projects: 
  type: pages
  batch: true

Ready?

• In-code documentation (wherever needed)
• Unit tests for fixed bug/feature
• Tests and CI checks all pass

For review team

• Add lab and/or sandbox examples (wherever helpful)
• Add changes & docs to release notes draft in Notion

[distantnative]

Todo: Turn into i18n string.

[distantnative]

Todo: Making this depend on the event (and more specifically a checkbox event) that many layers up from the actual input seems not ideal to me. Can this just accept the item as parameter and decide what to do based on whether the item is already in the selected array or not?

[distantnative]

Discussion: I of course understand why it is implemented like this currently, but for a core method in this class, it seems a bit unusual to swallow the actual exceptions and just throw this vague one. Not sure there is a better way.

[afbora]

I just wondering if it wouldn't be better if batch mode was enabled by default. I don't think it would be considered a breaking change to enable this feature. After all, it's a nice and useful feature.

[afbora]

Getting Not all pages could be deleted dialog error when I select a non-deletable pages. I have to reload the page after the error to see remains.

Ideal solution: shouldn't be able to select non-deletable models.

[afbora]

When batch is active, the status icon is still clickable. If you click the status icon, both the status dialog opens and batch selection works. A user may accidentally delete the model while trying to change the status while batch mode is active.

Ideal solutions:

1. When the status icon is clicked, the status dialog should not open/work.
2. If the status icon should work when batch mode is active, it should not trigger the batch mode checkbox.

[bastianallgeier]

@afbora that's wrong. Reloading should not be necessary. Already blocking the checkbox would be ideal indeed, but also a lot harder to implement. That's why I went for a simpler first solution that just skips the ones that cannot be deleted during the request.

[afbora]

@bastianallgeier I've tested again and page is not reloading after the error.

[bastianallgeier]

I've added table selection and it's working great

CleanShot.2024-12-10.at.12.19.59.mp4

[afbora]

@bastianallgeier Is it testable for bug-fixes?

[bastianallgeier]

@afbora no, I still need to look into the exception issue.

[bastianallgeier]

@afbora I've fixed it now and it's working fine for me.

[afbora]

@bastianallgeier Deletion doesn't work with paginated sections.

pages:
  type: pages
  batch: true
  limit: 2

[pReya]

I've added table selection and it's working great
CleanShot.2024-12-10.at.12.19.59.mp4

Sorry for a slightly Off Topic remark: But I see you're touching the "ID" column of table views and conditionally using them as a checkbox for multi-select. I know of multiple projects that are hiding the ID column (because it's the only way to get rid of this column as it's not configurable). Is there any way to hide the column and still be able to use this new multi-select possibility?

[bastianallgeier]

@afbora can you give more context. What happens in that case?

[bastianallgeier]

@pReya if the id column is disabled, it should still be visible when the select mode is on.

[pReya]

@pReya if the id column is disabled, it should still be visible when the select mode is on.

AFAIK the ID column can't be disabled. It needs to be hidden via CSS (see linked forum post). So what I'm trying to say is: While you're working on this – is there any chance, you can allow disabling/hiding it while still allowing multi-select? See also https://kirby.nolt.io/460

[afbora]

@bastianallgeier Nothing happened. Just getting Not all pages could be deleted error and no pages are deleted. Even if they are deletable pages.

[nilshoerrmann]

Two questions regarding the selection layout:

1. Looking at the cards layout, I was wondering if using colours to highlight the selection would be a good idea. E. g. adding a blue outline or even changing the card colour (thinking of how selections work in Finder or Explorer). Right now, because the checkboxes are not that visually attached to the cards, it's hard to see the current selection easily. The checkbox' active state seen in the screenshot makes this very clear: it looks like the checkbox is active, not the card – but the user is interacting with the full card and not this single checkbox.
2. And regarding the table layout – I'm sure I already reported that a few years ago – I am always wondering: Why are interactions like dragging and now selecting attached to the first cell? Having the action inside a cell makes it look like a data entry actually. But again, we are interacting with the entire row and for the list layout the drag icon is visually prefixing the item already, hovering on the grey background. It would be great to have a consistent behaviour across layout variants here in my eyes.

A quick visualisation:

I'm really fond of the introduction of batch editing. But I'd personally prefer a bolder design for destructive interactions like this to clearify the impact of the action. That's why I'd like to suggest the inverted colours here.

[distantnative]

@nilshoerrmann if you have some good tips how to implement drag handles outside of a <table> element, please let us know. We tried #4386 but so far without success.

[nilshoerrmann]

@distantnative I would put the handle inside the first cell (which ever that is in the current table) and move it outside using translate. I haven't tested this right now but I think I have done that this way before.

[nilshoerrmann]

I've just tried in the lab, quickly altering the CSS:

The only problem might be that you have to remove the overflow handling:

Not sure why it's there to be honest. So that would be interesting to know, if that really has to stay.

[nilshoerrmann]

Oh, the overflow: hidden is for text shortening with an ellipsis of course (sorry, I didn't notice before because we usually remove that behaviour with custom CSS). In that case an additional wrapper would be needed inside the cell or it would be possible to to create an "invisible" cell at the start of the table (zero width, no background and borders) to place the drag handle inside and allow overflow for that cell specifically.

[nilshoerrmann]

By the way, I've read in the linked issue about the issues with hover interactions: as long as you don't remove the handle from the content flow with display: none this works perfectly. Setting opacity: 0 by default, switching to opacity: 1 on row hover makes this visually consistent with the list layouts.

[nilshoerrmann]

@distantnative If you apply the following CSS to https://lab.getkirby.com/public/lab/components/items/4_table the drag handle will be outside of the table with sorting functionality intact, showing on hover:

.k-table .k-table-index-column {
  /* ↑ this would need a dedicated first column with a different name, e. g. .k-table-sorting-column */
  overflow: auto;
  position: relative;
  width: 0;
  padding: 0;
}

.k-table .k-table-index-column .k-sort-handle {
  /* display: none; ← remove this */
  position: absolute;
  translate: -2rem;
  left: 0;
  top: 0;
  opacity: 0;
  width: 2rem;
}

.k-table thead th:first-child {
  position: initial;
}

.k-table .k-table-index {
  display: none; /* ← this removes the index number which would have to move to the second column instead */
}

.k-table .k-table-sortable-row:hover .k-sort-handle {
  opacity: 1;
}

In this case the first index column will be visually hidden. So it's a proof of concept that this works with a "ghost" column. Tested in Firefox and Safari.

There is a display error with images inside the table when sorting (outline cut off by image) but that's unrelated to the above styles.

[johannahoerrmann]

Another issue I see with placing the select in the ID cell (and thus hiding the number) is – numbers are very useful to see during batch edit if they are something editors actually work with. The number is the clearest and easiest indicator for specific rows, so I do see the use case of eg. jotting down or agreeing on numbers of the items to delete (or otherwise edit, once that's possible). Pretty much the exact opposite use case of what @pReya wrote, but the same issue (showing select in the space reserved for numbers).