What actually goes

Deleting an element in Craft does more, and less, than most people expect. None of this is Nuke’s behaviour — it is Craft’s, and it is why the preview is worth reading.

The trash, and gone

A soft delete sets dateDeleted and leaves everything in place. The element vanishes from the front end and from element queries, and stays restorable until Craft’s softDeleteDuration elapses and garbage collection hard-deletes it. This is Nuke’s default because it is a free safety net.

A permanent delete removes the row and lets the foreign keys cascade. There is no undo except the backup. It needs the separate nuke:hardDelete permission.

Drafts and revisions

They go with the element either way. A permanent delete cascades through drafts.canonicalId and revisions.canonicalId, which in turn cascade the draft and revision elements rows. A soft delete soft-deletes them alongside, so restoring the element restores its history too.

So “also remove drafts and revisions permanently” is not about whether they go — it is about the soft case. With it on, the history is removed outright while the elements themselves stay in the trash. That reclaims the rows now rather than at trash expiry, and it is the one option in Nuke that makes a recoverable strike partly unrecoverable: restore the entry afterwards and it comes back with nothing to revert to. Off by default for that reason.

Because of the cascade, a purge has to happen before the canonical element is deleted. Nuke does it in that order; a purge that ran afterwards would truthfully report deleting nothing.

Relations

This one is worth knowing regardless of whether you use Nuke.

Craft has no foreign key on relations.targetId. It cascades sourceId, sourceSiteId and fieldId, but nothing on the target side. So permanently deleting an element takes the relations it pointed out of and leaves every relation pointing at it behind, dangling at an ID that no longer exists.

Craft’s garbage collector sweeps those up under “deleting orphaned relations”, which is why the problem is invisible on a busy site and accumulates on a quiet one. Nuke clears them itself on every permanent delete, whatever the settings say, because they are wrong by definition.

For a soft delete it is a real choice, which is what the delete relations switch is for. Trashed elements already drop out of relation fields on the front end, so keeping the rows changes nothing a visitor sees — what it changes is whether restoring the elements restores the relationships. Off by default; worth turning on when a section is being decommissioned rather than tidied.

Structure children are promoted, not deleted

The one that surprises everybody. Elements::deleteElement() walks the structure node’s children and calls insertBefore() on each one — moving it up to sit where the parent was — and only then deletes the now-childless node.

So deleting a top-level page does not delete its subtree. It promotes the whole subtree to the top level, where it sits in your navigation looking like a mistake somebody made by dragging.

Nuke counts the descendants that survive this way — descendants the target matched anyway are excluded, since those are being deleted rather than promoted — and warns in words. It is almost never what the operator pictured, and it is invisible until afterwards.

Assets reach outside the database

A soft-deleted asset keeps its file on the volume; the disk space is not reclaimed until the trash expires. A permanently deleted one has its file removed, and a remote volume has no trash of its own, so that is final.

The asset scope says which of the two you are about to do, every time.

Users cascade further than you think

Deleting a user reaches into authorship, addresses, session rows and permission assignments. Craft’s own user delete offers to reassign that user’s content to somebody else; a bulk strike cannot ask that question once per user, so content is not reassigned.

That is why user strikes are off until switched on, admin-only even then, and why your own account is excluded from every one of them — deleting the account performing the run logs it out mid-request, which aborts the request doing the deleting and leaves the ledger with no ending.

Nested elements

Matrix entries and other nested elements are deleted with their owners by Craft, and Nuke’s trash sweeper deliberately leaves them alone: Craft only hard-deletes a nested element once it has checked that no surviving revision still depends on it, and that check is subtle enough that duplicating it would be a good way to corrupt revision history. They are handed to Craft’s own collector instead, and counted separately in the report so the number is not a mystery.