Make WordPress Core

Opened 3 years ago

Last modified 11 months ago

#54016 new enhancement

Media Library: Bulk delete elements in grid view takes very long

Reported by: presskopp's profile Presskopp Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: performance Cc:


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.

2 years ago

#3 @Presskopp
14 months ago

  • Focuses performance added

#4 @lukasbesch
11 months ago

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:

  1. A request with all attachment IDs that should be deleted is sent.
  2. These attachments get the post status deleting. They do not appear in the media view anymore or at least cannot be selected. The filename is still blocked for new uploads.
  3. A scheduled job picks up these attachments and deletes them (one by one or in chunks, oldest first?) and all relations like _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.

I did not think about the optional media trash properly yet. If it is enabled, step 2 is probably not necessary. And step 3 depends on if the relations are also cleared on trashing the media (I believe they do but am not sure).

Last edited 11 months ago by lukasbesch (previous) (diff)
Note: See TracTickets for help on using tickets.