Snapshot revisions before a bulk edit

A find-and-replace across a batch of posts is the kind of change that is quick to run and slow to unpick if it catches something it should not. The confidence to run it at all comes from two things: knowing you can put any single post back exactly, and being able to prove afterward precisely what was touched.

This recipe builds both in before it changes anything. It records a per-post rollback point, makes the change in batches you approve, and then reads the plugin’s own audit log so you can see every write it made.

I need to change [our old company name] to [the new one] across [the posts in
the "News" category], and I want a clean rollback plan before we touch a thing.

Go read-first. Pull the posts in [News] that mention [the old name] and show me
the list. For each one, list its revisions and record the current latest
revision ID, that is our rollback point per post. Then show me a
before-and-after for a small sample of the exact replacement so I can see it is
a clean swap and not catching words it should not.

I approve before any write. After I say go, make the change in small batches,
one post at a time within each batch, and show me each batch before it saves.
Every edit saves a fresh revision on its own, so combined with the IDs you
recorded, each post has an exact point to return to.

When the run is done, read the activity log newest first, 200 rows a page,
until created_at (UTC) is older than when we started, and show me every write
it recorded for this job: the ability, the post, the acting user, and the time.
The read has no date filter, so stop paging at the start of the run. If any
post looks wrong, I will hand its recorded revision ID to the
restore-a-revision recipe and roll just that one back.

Why this is safe to run

The whole setup is reads. Finding the posts, listing each one’s revisions, and previewing the replacement on a sample all write nothing, so you approve the exact change and you hold a recorded rollback point for every post before a single edit runs.

The change itself goes out in small batches you see first, and it only edits post bodies, never status. WordPress saves a fresh revision on every update, so each post has both its recorded starting point and a clean history, and rolling one back is a handoff to the restore-a-revision recipe, whose restore is itself reversible. When the run is done, the activity log gives you the receipt: every write, the post it hit, who the agent acted as, and when. The write abilities stay off until you enable them, every call is checked against the capability of the user you bound the agent to, and reading the log needs the manage-options capability.

For a receipt you can keep, open the Activity Log tab afterward, set the From date to today, filter by the tool you used, and Export CSV. The tab shows the connection, the source IP and the duration of each call, which the agent’s read does not return.

Already connected? You do not have to paste this. Ask your agent for the “snapshot revisions before a bulk edit” recipe, or just describe the sweeping change you are nervous about, and it runs the same read-first, fully logged flow on your own site.