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

[Presskopp]

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.

[lukasbesch]

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.

[jdeep]

I would like to spent some time looking for a good approach for this. I checked this and can argue that sending an ajax request for every image is not performant.

A simple solution would be to gather the selected attachment IDs from the Backbone selection collection on the frontend and send them to a new bulk delete AJAX endpoint. To prevent server timeouts on large deletions, we could chunk the requests in reasonable sizes. This approach should reduce the network overhead. We can always optimise how the backend deletes the data (through cron jobs or immediate deletes).

Fixes: #54016

Current implementation of bulk attachment deletion in media (grid view) initiates an AJAX request per attachment. This patch implements a new AJAX action for bulk post deletion and rewrites the logic for bulk deletion in frontend.

Trac ticket: https://core.trac.wordpress.org/ticket/54016

## Use of AI Tools
AI assistance: Yes
Tool(s): GitHub Copilot, Claude
Model(s): Opus 4.6
Used for: Researching on batch processing, finding out edge cases in implementation and code suggestions.

Currently, in the draft patch, I am seeing significant performance improvements when delete actions are batched. Here are the profiling results comparing trunk to this patch:

Action: Deleting 100 attachments in bulk from Media in 3G throttling

I will have to test it a bit more to make sure there are no edge cases with different file types and file sizes.

# Current implementation:
​https://github.com/user-attachments/assets/fe1f8f3c-fd8e-4a96-8b3e-2778cc118881

# Batched actions
​https://github.com/user-attachments/assets/a3f39c4f-7a08-46da-889b-735402cfd913

[darshitrajyaguru97]

I was able to reproduce the issue locally and can confirm the performance concern when performing bulk deletion in the Media Library grid view.

Testing details:

• WordPress: 7.0 RC2
• Environment: local + medium dataset (~500 images)
• Browser: Chrome

Observations:

• Bulk delete in grid view triggers multiple sequential AJAX requests (one per attachment).
• UI updates after each deletion, which significantly increases total processing time.
• On larger datasets, this results in noticeable delay and increased server load.

Comparison:

• List view bulk delete appears more efficient since it processes via bulk action rather than per-item requests.

Suggestions:

• Introducing batched deletion (single request with multiple IDs) could improve performance.
• Alternatively, a hybrid approach:
  • Step 1: Mark items with a temporary status (e.g. deleting)
  • Step 2: Process deletion asynchronously in chunks (similar to background processing used elsewhere in core)

Additional note:

It may also be worth reviewing whether _thumbnail_id and related postmeta cleanup can be optimized or deferred to reduce query overhead during deletion.

Happy to help test any patches if this moves forward.