Running a strike
A strike is a bulk deletion you have read first. This page is what happens between choosing a target and the content being gone.
The blast radius
Every change to the form on Nuke → Strike re-runs the preview. It reports:
| Count | What it means |
|---|---|
| Elements | Canonical elements the target matches. Each is counted once however many sites it exists in. |
| Drafts | Drafts belonging to those elements. They travel with the element either way. |
| Revisions | Revisions belonging to them. Usually the largest number on the screen. |
| Relations | Rows in the relations table pointing at, and out of, the matched elements. |
| Files / bytes | For an asset target, the count and total size on the volumes. |
| Descendants moved up | Structure children that survive and get re-parented. See what actually goes. |
| Left referencing | Surviving elements that hold a relation to something in the strike. The most important number on the screen. |
Below the numbers: a sample of what matched, and a list of the referencing elements ordered by how many relations each one loses, both linking straight into the control panel so you can go and look.
Why the preview can be trusted
The preview does not build its own query. It calls the same method the execution calls, gets back the same array of element IDs, and counts that. Everything else — the drafts, the relations, the descendants, the collateral — is a query against that exact list of IDs.
The list is materialised rather than streamed. Ten thousand integers is a rounding error in memory terms, and holding them turns three correlated subqueries against a moving target into three ordinary queries against a fixed one.
Arming it
By default the delete button is disabled until you type the handle of the source you are targeting — news to delete the News section. The phrase is checked again on the server before anything happens, so a browser extension helpfully filling the field in does not count.
When more than one source is named, or none, there is no single handle to type and the phrase falls back to the scope (entries). You can change the phrase, or turn confirmation off entirely, in settings.
What happens when you fire
- The preview runs again, server-side. The form may have been open for an hour. If the target no longer passes validation — a protected scope, a Single, a user strike on a site that has them switched off — nothing happens.
- The backup is taken, if requested, into
storage/backupswith a name likenuke-run-42-2026-08-17-093000.sql. A failure here stops the run. - Drafts and revisions are purged, if you asked for that, while the canonical elements still exist — the foreign keys mean that once the element is gone there is nothing left to count.
- Elements are deleted in batches of 100 by default, each batch its own transaction.
- Relations are cleared where appropriate.
- Craft’s garbage collector runs, unless you turned that off.
Batching, and failing part-way
A run is deliberately not one transaction. Each batch commits on its own, so a failure two thirds of the way through leaves two thirds deleted and a run record that says so. The alternative — one transaction big enough to time out, roll back, and leave nobody sure what happened — is worse in every way that matters.
Deletion goes through Craft’s Elements::deleteElement() rather than a bulk DELETE. That is slower, and it is what fires beforeDelete/afterDelete, invalidates caches, unhooks structure nodes and lets every other installed plugin clean up after itself. Bulk SQL would be faster and would leave the site subtly broken.
If more than fifty deletions fail and failures outnumber successes, the run stops early and says so. A run where nearly everything is failing has a systemic problem, and grinding through the remaining forty thousand to report the same error forty thousand times helps nobody.
Running in the background
Switch on Run in the background and the strike is pushed onto the queue instead of running in the request. Recommended for anything large — a web request has a time limit and the queue does not. The run appears in the ledger the moment the job starts, with a progress bar.
A queued strike is previewed again when the job runs, so a target that has become invalid in the meantime still does not fire.
Undoing one
A soft delete — the default — puts elements in Craft’s trash, where they stay recoverable until softDeleteDuration elapses. That is the real safety net and it costs nothing to keep.
Beyond that: the backup. The run record holds its path and tells you whether the file is still on disk. Restoring it is php craft db/restore <path>, and it restores the whole database, so it is a real decision rather than an undo button.