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 and show me every write it recorded for
this job: the ability, the post, the acting user, and the time. 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.

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.