Changing How Long WordPress Keeps Trashed Items
Setting this to zero does not shorten the retention period. It removes the trash entirely, so Move to Trash becomes Delete Permanently and there is nothing to restore from.
Zero means off, not immediate. EMPTY_TRASH_DAYS sets how many days WordPress keeps a trashed item before deleting it for good. The default is 30. Setting it to 0 does not mean "empty the trash straight away" — it removes the trash from the workflow entirely, so deletion is permanent at the moment it is clicked, with no recovery.
The setting
define( 'EMPTY_TRASH_DAYS', 7 );
It goes in wp-config.php above the stop-editing comment. The value is in days and applies to everything that can be trashed: posts, pages, custom post types, media attachments and comments.
A shorter window is a reasonable choice on a busy site where the trash accumulates faster than anyone reviews it. Seven days still covers the realistic case, which is someone noticing within a working week that something was deleted by mistake.
What zero actually changes
With the trash disabled, the interface changes to match:
- The row action reads Delete Permanently instead of Move to Trash.
- There is no Trash view to visit, because nothing goes there.
- A deletion is a database removal with no intermediate state.
There is no undo. Recovery means restoring from a backup and reconciling everything that changed since it was taken, which is a substantially worse afternoon than clicking Restore. On a site with more than one editor, this is a setting that makes someone else's mistake unrecoverable, and that is worth considering before choosing it for tidiness.
The one setup where it is defensible is a site whose content is generated or deployed rather than authored — where the source of truth is elsewhere and the database is downstream, as in WordPress and Git.
Cron has to be running
Emptying the trash is a scheduled task, not something that happens the moment an item ages past the limit. WordPress checks its schedule on page loads and runs anything due.
Two situations stop it:
- A site with very little traffic, where page loads are rare enough that scheduled tasks fire late or not at all.
DISABLE_WP_CRONset to true without a real system schedule configured to replace it. This is a common optimisation, and forgetting the second half of it quietly stops every scheduled task on the site, not just this one. The trade-off is set out in disabling WP-Cron.
The symptom is a trash containing items far older than the retention period. That is not the constant failing; it is the scheduler never being asked.
What it does not clean up
Trash retention governs trashed items. It does not touch the things that actually make a WordPress database large:
| Accumulates | Governed by |
|---|---|
| Post revisions | WP_POST_REVISIONS |
| Expired transients | Their own expiry, cleaned on schedule |
| Spam comments | Spam retention, separate from trash |
| Orphaned meta | Nothing automatic |
A site whose database is heavy is usually carrying revisions rather than trash, which is the subject of WordPress post revisions. Shortening trash retention to fix database size solves a problem the site probably does not have, while shortening a safety window it does.
Media is the one to be careful with
A trashed attachment still has its file on disk, and permanent deletion removes it. If that image is referenced by an absolute URL inside another post's content, deleting the attachment breaks the image there, and nothing warns you — the reference lives in content, not in a relationship the database tracks.
That is the mechanism behind a good share of images not showing reports on sites that recently had a media clear-out. A longer retention window gives someone a chance to notice before the file is gone.
Verify the value is live
Trash a test post and check the Trash view shows it. Leave the value at something short, wait for the period to pass, load a few admin pages to give the scheduler a chance, and confirm the item is gone.
If it is still there well past the window, the scheduler is the thing to investigate rather than the constant. If the Trash link is missing from the post list entirely, the value is 0 and the trash is disabled — which is either what you intended or a number chosen under the wrong assumption about what zero means.
Frequently asked
- It disables the trash. Deleting a post removes it immediately with no intermediate state and no restore, and the button label changes to reflect that. It does not mean empty the trash after zero days.
- Because the cleanup runs on a scheduled task. If WP-Cron is disabled and nothing replaced it with a real system schedule, the task never fires and items sit in the trash indefinitely.
- Yes. The same retention governs trashed posts, pages, attachments and comments, so shortening it shortens the recovery window for all of them at once.