TryMode gives you a safe way to try something on a WordPress site.

Start an experiment. Install a plugin, change settings, redesign a page, switch a theme. TryMode records the supported WordPress database changes as you make them. When you are done, it shows you exactly what changed and you choose: keep everything, or discard the changes it can genuinely put back.

TryMode is not a backup plugin, a reset plugin, a staging site or a migration tool. It is a short, bounded experiment with a review at the end.

What makes it different

Most tools sit at one of two extremes. Activity logs tell you what happened but cannot undo any of it. Backups can undo everything but tell you nothing about what changed, and restoring one throws away every other change made since.

TryMode sits in between. It records the previous value of each thing the first time that thing is touched inside an experiment, so it can attribute every change and put it back, without copying your whole database.

Honest about what it cannot do

This matters more than any feature. Every recorded change carries one of four states, with the evidence for it:

Safe to revert — the previous value was recorded and can be written back and verified.
Revert with caution — revert is implemented but has known side effects, which are spelled out.
Report only — detected and shown, never written back.
Cannot be undone — it already left this site.

TryMode will never claim to undo an email that has been sent, a payment taken through a gateway, a webhook that has been delivered, or a change made on a remote service. Those are recorded as warnings and shown to you before you choose, so that “discard” is never mistaken for “none of that happened”.

The button says “Discard supported changes”, not “Discard everything”, for the same reason.

What it can undo

Options created, changed or deleted through the options API
Posts, pages and other content created, edited or deleted — including post meta and taxonomy links
Post meta and term meta
Terms created, edited or deleted
Comments created, edited, moderated or deleted
Scheduled events added during an experiment

What it can undo, with side effects disclosed

Plugin activation and deactivation — reactivating re-runs the plugin’s activation routine
Theme switches — switching back re-runs theme setup
Deleted content — restored at its original ID only while that ID is still free
Removed scheduled events — a restored event whose time has passed runs on the next cron sweep
Values containing PHP objects — restorable only while the defining class is still loaded

What it only observes

User accounts, roles, capabilities and user meta
WooCommerce orders, payments and refunds
Custom database tables created, dropped or altered by other plugins
Files on disk, including plugin and theme installs, updates and deletions
The site address and other settings where a wrong value would lock you out
Values that looked like secrets, which are stored as a fingerprint and never in plain text
Rows written with direct SQL, which never reach a WordPress hook

Prevention, not just undo

An email that has reached a mail server is gone, and no plugin can bring it back. So TryMode stops it leaving instead.

While an experiment runs, outgoing email is held rather than sent. Keep the experiment and it goes out; discard it and nothing ever left the site. Outbound POST, PUT, PATCH and DELETE requests to other servers can be blocked and listed the same way, though that is off by default: on a live site it will make a payment callback or a CRM sync fail while the experiment runs. A blocked request is never replayed afterwards, because TryMode cannot know whether the call was safe to repeat. Reads are always left alone.

Email holding is the one side effect the plugin can genuinely prevent rather than report, so it is on by default. Request blocking is the same idea applied to a place where the remote end also has an opinion, so it is opt-in.

File restore

Switch it on and TryMode copies every watched file when an experiment starts, which is the only way it can put one back. A file added during the experiment is deleted, and a file changed or removed is written back from the copy.

It is off by default because it costs database space. The copies are kept in TryMode’s own table rather than written to disk: the files worth restoring are plugin and theme sources, which means executable PHP, and a plugin may not write that into the uploads directory. There is a per-file size limit and a storage budget per experiment, and anything past either is listed as detected-but-unrestorable rather than quietly skipped.

Protected tables

A plugin’s own tables are normally report-only, because the writes never reach a WordPress hook. Nominate a table and TryMode copies every row at the start and can put them back.

That is a snapshot restore, not a change-level revert, and the interface says so: the table is replaced with what it held when the experiment began, so a row written by anything else in the meantime goes too. Opt-in per table, capped by row count.

Unattended updates

WordPress installs automatic updates when nobody is watching. TryMode can wrap that run in an experiment, load a few pages of your choosing afterwards, and email you what it found.

If the pages fail, nothing is undone: you get an email and the experiment waits for you. You can arm automatic revert instead, but it is deliberately a separate switch, because a failed health check is evidence rather than permission.

Page comparison

Loads a handful of pages before and after an experiment and shows what changed in the output. Forty reverted options tell you nothing about whether the homepage still looks right.

It compares rendered content, not pixels — a screenshot diff needs a headless browser, which a plugin cannot assume exists. Nonces, cache-busting query strings and generated IDs are ignored so they do not show up as false differences.

Approvals

Optional. Keeping or discarding an experiment opens a request that a second administrator has to sign off, and the person who asked cannot approve their own. The sign-off lands on the experiment timeline.

Checkpoints

Mark a checkpoint partway through an experiment and you can come back to that exact point instead of unwinding everything.

A checkpoint is not a bookmark in a list of changes. An object touched both before and after the mark still carries the experiment’s original value as its baseline, so “undo everything after the mark” would overshoot it. Marking a checkpoint therefore reads the current state of everything the experiment has touched so far and stores that as a second baseline. Anything TryMode cannot capture a baseline for is counted and shown, because those objects will go back further than the mark.

Selective keep and discard

Changes are grouped into units that have to move together, and you choose units rather than individual changes. Ticking a unit that depends on another pulls that one in automatically: a comment comes back with its post, term meta with its term, a theme setting with its theme. Reverting half of a pair would leave the database inconsistent, so TryMode does not offer it.

Update in TryMode

Every available plugin and theme update gets an “Update in TryMode” button. It starts an experiment, runs the normal WordPress updater, and drops you on the review screen. Core updates are deliberately not offered: they run database migrations that TryMode records but never rewrites, so a “reverted” core update would only be partial.

WP-CLI

wp trymode status
wp trymode start --name="WooCommerce update"
wp trymode checkpoint --name="Before the theme switch"
wp trymode changes
wp trymode finish
wp trymode discard --yes
wp trymode discard --checkpoint=3 --yes
wp trymode resume

This is also the escape hatch. If an experiment breaks wp-admin, the button is unreachable but the journal, the plan and the recorded baselines are all still in the database, and every one of them can be driven from the shell.

When something breaks

If a fatal error happens while an experiment is recording, TryMode notes it in the timeline and the warnings, and — if the site drops into recovery mode — shows you how to revert, from the admin or from the command line. It never reverts on its own: an automatic revert triggered by a fatal error would be the plugin making the biggest decision on the site at the moment it understands least.

File changes

Optional, off by default. TryMode can compare a list of files at the start and end of an experiment and report what was added, changed or removed in your plugins, themes or uploads. Detection only. Putting a file back means having kept a copy of it, which is a separate problem with its own storage and failure modes, so TryMode reports file changes and points you at a backup rather than pretending it can undo them.

Built for trust

Journalled revert. Every operation is written down before it is attempted. If the browser closes or the request times out, TryMode offers to resume from exactly where it stopped.
Verification. After a revert, TryMode reads the database back and compares it against the recorded baseline, then reports how much was restored, what failed and what needs a human.
Conflict detection. If something changed a value again after the experiment ended, TryMode does not overwrite it. It reports the conflict, and offers a separate, explicitly confirmed “overwrite anyway” if you decide the recorded value should win.
Field-level diffs. Changes show what actually moved: a line diff for post content, a key-by-key comparison for settings arrays, rather than two walls of serialized text.
Exportable reports. Any experiment can be exported as JSON or CSV, with every change keeping its reversibility status and its reason.
Secret redaction. Passwords, API keys, tokens and licence keys are replaced by a one-way fingerprint at the moment they would be recorded — which also means TryMode says plainly that it cannot restore them.
No telemetry. TryMode makes no outbound requests of its own, ever.

Performance

When no experiment is running, TryMode registers no hooks at all. The entire cost is one already-cached option read.