Opened 3 years ago
Last modified 14 months ago
#54016 new enhancement
Media Library: Bulk delete elements in grid view takes very long
Reported by: | Presskopp | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Media | Keywords: | |
Focuses: | performance | Cc: |
Description
When bulk deleting images in media grid view they will be deleted one by one counting down, refreshing the view (not reloading the page!) and this takes unnecessarily long. I wonder if this can be accelerated by first deleting all of them before the view gets refreshed for example.
Change History (4)
This ticket was mentioned in Slack in #core-media by presskopp. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
3 years ago
#4
@
14 months ago
Version 0, edited 14 months ago
by
(next)
Note: See
TracTickets for help on using
tickets.
One problem in the bulk deletion process is that for every single media item that is deleted, a request to admin-ajax is made. That can overload the server pretty quickly.
How about we bundle these request to single one with all the IDs?
If we do that, the single request would probably take longer and could timeout. To solve that problem, we could first mark all the items as "to be deleted" (using the post_status) and run a scheduled job to clean up everything in chunks again.
I am having this problem on a large site and found out that during the deletion, also the postmeta table is scanned for the _thumbnail_id and the corresponding entries are deleted. This is also slow on huge postmeta tables.
So I imagine the process like that:
deleting
. They do not appear in the media view anymore or at least cannot be selected. The filename is still blocked for new uploads._thumbnail_id
.… maybe this should be opt-in or a plugin? Because not everyone has large sites and a proper cronjob running, thus it would affect the (uncached) frontend in terms of performance.