Astricode Ops provides a reversible quarantine infrastructure for supported advanced operations.
The purpose is to create a safer boundary between inspection and permanent deletion.
How quarantine works
For options and metadata, Astricode Ops stores a small verifiable copy before removing supported data from its source location.
For complete plugin tables, it can use reversible table renaming inside the same database.
Operations preserve information such as:
- integrity hash;
- source context;
- operation context;
- status;
- creation time;
- expiration;
- restoration state.
Quarantine dashboard
The Reversible Quarantine section summarizes:
- availability;
- number of operations;
- stored items;
- protected storage;
- expired items.
The operations table can include:
- date;
- type;
- source;
- key;
- item count;
- quarantined count;
- restored count;
- protected size;
- expiration;
- available actions.
Restore
When restoration is supported and the destination conditions are valid, select Restore.
Astricode Ops verifies the quarantine record before attempting restoration.
Delete copy
For option and metadata quarantine records, Delete copy permanently removes the stored quarantine copy.
Use it only when you no longer need the rollback path.
Delete quarantined table
For a table held by reversible rename, Delete quarantined table is the permanent deletion step.
Do not use it until you are certain the original plugin table is no longer required.
Expiration and purge
Quarantine records can have a retention period. Expired quarantine items can be purged through the available purge action.
Retention gives you a review window; it should not be treated as a substitute for an independent site backup.
Quarantine is not universal undo
Standard cleanup actions such as deleting revisions, spam comments or orphaned usermeta are not automatically placed in this quarantine infrastructure.
Always check which operation you are using before assuming it is reversible.