Troubleshooting

The preview says nothing matches, and I know it should

Check the status filter first. Element statuses are not universal — live is entry-only, categories and assets have enabled/disabled, users have their own five. An element query asked for a status its type does not have returns nothing at all rather than erroring. Nuke only offers each scope the statuses its type actually has, so this usually only bites a target built from the console or from saved element IDs.

Second: the search filter only matches what the search index knows about. On a site that has never been reindexed, or where indexing has been failing quietly, that is a different set from what exists. Drop the search term and see if the count changes.

Third: dates. -2 years and 2020-01-01 both work; anything neither Craft’s date helper nor PHP’s DateTime can read is reported as an error rather than treated as “no filter”, so check for a red message rather than assuming the filter was ignored.

The strike deleted more than the preview said

Open the run and look at Against the preview, which shows the difference. Then, in order of likelihood:

  • The strike was queued. A background strike previews again when the job runs, which may be minutes later. Content saved in between is matched by the new preview and not by the one you read.
  • Something was saved between previewing and firing. The control panel re-previews server-side at fire time for exactly this reason, but the number you were looking at is the one from before.
  • Drafts and revisions. The headline “removed” figure is elements plus drafts plus revisions. If you were reading the element count alone, the total will look much larger.

A structure came out rearranged

Working as designed, by Craft. Deleting a structure entry promotes its children to where the parent was rather than deleting them — the preview’s “descendants moved up” count is the warning. See what actually goes.

To delete a subtree, target the descendants too: tick the section and leave the level filters off, or use an explicit element ID list.

“This matches N elements, over the ceiling”

The default ceiling is 10,000. Either the target is broader than you meant — check the sources, and remember that no boxes ticked means all of them — or the run really is that big, in which case raise maxElementsPerStrike, or add --limit / Stop after and work through it in chunks.

“The backup failed, so nothing was deleted”

Craft’s backup shells out to mysqldump or pg_dump. On a host where those are missing, or where proc_open is disabled, it cannot run. Check storage/logs/nuke.log for the underlying message.

Either fix the dump command — Craft’s own db/backup command will fail in the same way, which is a quicker way to test it — or turn the backup off for that run and rely on your host’s snapshots. The preview will warn you every time that no backup is being taken.

The delete button will not enable

The typed phrase must match exactly, including case. It is the handle, not the name: caseStudies, not Case Studies. With several sources selected, or none, there is no single handle and the phrase falls back to the scope (entries). The label above the field always says what to type.

The scheduled sweep stopped running

In order:

  1. Is the edition still Pro? Scheduling is gated.
  2. Does the crontab have --dry-run=0? This is the common one. nuke/sweep/due previews by default like every other console command, and a dry run leaves no ledger row — so it will keep saying “due” forever and never actually sweep.
  3. Run it by hand and read the output. It will say either “Not due, next: …” or run.
  4. On the web trigger, remember it only fires on control panel page requests. A site nobody has logged into for a fortnight has not swept for a fortnight.

A sweeper says “not applicable on this site”

It has nothing to work on — no volumes for the asset tasks, a table your database driver does not have. It is skipped rather than failed, and skipping is not scored against anything.

The unreferenced-assets task found nothing, or found too much

It checks two things: rows in relations, and reference tags in element content. It cannot see an asset referenced only by a URL typed into raw HTML, hard-coded in a Twig template, or stored by a third-party plugin in its own tables.

“Found nothing” usually means every asset is genuinely related to something. “Found too much” usually means the site references images from templates — in which case leave the task on report only and treat its output as a list to review, which is what the default is for.

The sweep is slow

Two tasks read a lot: unreferenced assets makes one pass over every element’s content, and stale search index rows scans a table that is often the largest in the database. Run the sweep in the background from the control panel, or from cron, rather than in a page request. Narrow it with --only if you want a fast pass more often and the expensive tasks weekly.

Where to look when nothing else helps

storage/logs/nuke.log. It records every strike’s target and size before it starts, its outcome afterwards, every individual failure, and every sweep — and it survives the database it was deleting from.