Zignites Sentinel

Updating plugins on a production site is a small gamble taken repeatedly. Most updates are fine. Occasionally one takes the site down, and the recovery options are all worse than they should be: restore a full backup and lose whatever happened in the database since, or start manually reinstalling old versions over FTP while the site is down.

Full backup plugins solve disaster recovery. They are not built for the specific, frequent, narrow operation of “I am about to update six plugins and I want a way back if one of them breaks the code layer.” Sentinel is built for exactly that operation and nothing else.

The workflow is four steps: create a checkpoint before you update, validate it, restore it if an update breaks the code layer, and roll back the restore if the restore itself was wrong. Validation is the step most tools skip, and a checkpoint you have not verified is a checkpoint you are guessing about — finding out it was incomplete during an outage is the worst possible time.

Checkpoint packages, exports, staging files and restore backups are written under uploads/zignites-sentinel/. Because that path sits inside a publicly served directory on most hosts, Sentinel writes index.php guards, .htaccess deny rules for Apache and web.config deny rules for IIS.

It also does something unusual and worth calling out: the Dashboard runs an artifact exposure probe. It writes a temporary token file and tries to fetch it, then reports whether the artifact path appears blocked, publicly readable or inconclusive. Inconclusive results need checking at the host, Nginx, CDN or object storage layer. Most plugins that write to uploads simply assume their deny rules worked. This one checks and tells you when it cannot be sure.

Treat the artifacts as sensitive. A checkpoint contains your plugin and theme source, which can include configuration files, licence keys and API tokens.

Two reliability controls are built in. A shared operation lock covers checkpoint, package, staging, restore, rollback and cleanup so overlapping heavy operations cannot collide. And before checkpoint or restore work begins, Sentinel estimates the disk space required for packages, staging, live backups and rollback payloads, and blocks the operation if free space is below a safe threshold — rather than filling the disk halfway through a restore. Cleanup runs on a scheduled maintenance task and preserves active resume checkpoints.

Sentinel is not a replacement for your backup tool, and the two are answering different questions.

A backup answers “how do I get the whole site back to how it was on Tuesday.” It is the right tool after data loss, a compromise, or a failure whose cause you do not yet understand. It is also a heavy operation: you restore everything, including database rows written since the backup, which on a site taking orders or comments means losing real activity.

Sentinel answers a narrower question: “an update I just ran broke the code, how do I undo exactly that.” Because it only touches the active theme and plugins, restoring does not roll your database back, so nothing that happened since the checkpoint is lost. Orders placed five minutes ago are still there. That is precisely why it is limited to the code layer — the limitation is what makes it safe to use on a live site mid-afternoon.

In practice the sequence is: nightly backups running as usual, and a Sentinel checkpoint taken immediately before any batch of plugin or theme updates. If an update breaks a template or throws a fatal, restore the checkpoint and you are back in a minute with no data loss. If something worse has happened — the database is wrong, orders are corrupted, the site is infected — that is the backup's job, and Sentinel will not pretend otherwise.

The validation step is worth taking seriously rather than clicking past. A checkpoint that was never verified is an assumption, and outages are a bad moment to discover a bad assumption. Validating takes seconds and is the difference between having a rollback path and believing you have one.