Trash (Soft Delete & Restore)

Deleting content in a Webcloud7 site does not remove it immediately. Instead, the object is moved into a per-site trash container, from where it can be restored or — later — permanently removed. This soft-delete behavior protects editors from accidental data loss.

Overview

The trash replaces the normal Plone delete operation. When an editor deletes content:

  • The object (and its whole sub-tree) is moved into the site’s trash container (cms_trash_container) rather than being destroyed.

  • The trashed object is marked so it no longer appears in normal listings, navigation, search results, or relations, and direct access to it is blocked.

  • A trash record is stored on the object capturing its original id, its original parent path, the deletion time, and the user who deleted it.

A trashed object can be restored back to its original location, provided that location still exists and the user has permission to add content there. Restoring reverses the soft delete: the object is moved back, unmarked, and made visible again.

Note

Very large sub-trees cannot be trashed. If a deletion would move more than 500 catalogued items at once, the operation is refused. Such content has to be removed in smaller parts.

Deleting content

Deletion uses the standard content delete operation; no special endpoint is needed. Because the delete is intercepted, the object lands in the trash instead of being destroyed. The standard Plone REST delete therefore acts as a move to trash:

DELETE /Plone/my-page HTTP/1.1
Host: localhost:8080
Accept: application/json

After this call, /Plone/my-page is no longer reachable and the object lives in the trash container.

Note

Working copies and their baselines cannot be trashed while a staging relationship exists between them (see Staging (Working Copies)). Deleting them is rejected until the working copy has been applied or discarded.

How trashed content appears

Trashed objects are deliberately hidden from public and editorial consumption:

  • They do not appear in catalog/search results or navigation.

  • They are filtered out of relation listings, so references pointing at trashed content are not surfaced.

  • Direct traversal to a trashed object is blocked.

In short, from a normal content-consumption standpoint a trashed object behaves as if it had been deleted. It only remains reachable through the trash listing, which is restricted to editors with the Restore trashed content permission.

Each trashed item retains its trash record, which is what the trash listing uses to show when it was deleted, by whom, and whether it can still be restored.

Restoring content

A trashed object exposes a restore action. Posting to it moves the object back to its original parent (reusing its original id where possible), removes the trashed marking from the object and its whole sub-tree, and makes it visible again.

POST /Plone/cms_trash_container/<trashed-id>/restore HTTP/1.1
Host: localhost:8080

On success the request redirects to the restored object’s URL.

Restoring requires:

  • the Restore trashed content permission, and

  • that the original parent location still exists and is not itself trashed, and

  • permission to add content in that original parent (restoring is treated like adding new content there).

If any of these conditions fail, the object is reported as not restorable and the restore request returns 400 Bad Request.

Permanent deletion

Trash is meant to be temporary. Items can leave the trash permanently in two ways:

  • Manual deletion from the trash — an editor with delete rights can permanently remove a single item, or empty the whole trash, from the trash view.

  • Scheduled cleanup — the empty-trash console script permanently removes trashed items older than a configurable retention period. This is the recommended way to keep the trash from growing without bound. See Empty Trash for usage, scheduling, and logging details.

Both paths bypass the trash and delete the content for good; restoration is no longer possible afterwards.