Quick answer
To undo a file replacement safely, put back the copy of the original that was made for that specific replacement — and put back anything else the replacement changed along with it.
The copy has to have been made before the overwrite, not after.
And undoing one file is far better than restoring your whole site when only one document is wrong.
What undo has to put back
Depending on what was replaced:
- the original file itself
- whatever was pointing at it, if that changed
- the state of that row in the batch
- any related details the replacement updated.
Putting back only the file can leave things inconsistent if something else changed too.
The order that makes it possible
- find the original
- copy it somewhere safe
- record where that copy went
- confirm it really saved
- overwrite.
Every one of those has to happen before the write. A backup taken afterwards is not a backup.
Undoing one file versus restoring the site
Undo one file is right for a wrong PDF, a wrong image, a file that went to the wrong page, or one row of a batch that went wrong.
Restore the whole site is right for broad corruption, a database failure, or an infrastructure problem. Undo does not replace your normal backups and is not trying to.
Undo is not version history
Undo is there for mistakes.
It is not a legal archive, not a public version history, and not long-term document retention. If you need any of those, you need them set up deliberately.
Example
A 150-file batch finishes cleanly. A week later a department says file 82 was the wrong revision.
Undo puts back file 82. The other 149 are untouched, and nobody has to think about them.
After undoing, check
- the public URL
- the content of the file itself
- the cache
- the record of what happened.
If the file changed again after the batch
This one catches people out.
Say the plugin replaced a PDF, and later somebody changed that same document by hand.
Undoing the original replacement should not quietly wipe out that later change. A careful implementation notices that what is there now is not what it replaced, and says so rather than restoring blindly.
How long backups are kept
Replacement backups take up disk space, so they do not live forever by default.
Check what the retention is on your install rather than assuming undo will still be available months later — and if a document genuinely needs keeping, keep it on purpose rather than relying on a recovery backup.
When undo itself fails
If restoring fails, the item must not be marked as restored. The backup stays where it is, the reason is recorded, and you get a way to recover it by hand.
The worst possible outcome is a green tick while the public file is still the wrong one.
Undo is destructive too
Undoing is another write, and it deserves the same care as the replacement: confirm what you are restoring, check the current state, confirm the backup exists, record what happened.
It should not be a shortcut that quietly copies files around with nothing written down.
Undo and caching
Restoring the original file does not mean people immediately see it.
The URL has not changed, so whatever cached the replacement will happily keep serving it. Do the same cache checks you would after a replacement.
What the record should show
Afterwards you should be able to see that the replacement happened, that undo was requested, whether it completed or failed, when each of those happened, and which document it was.
That way support can follow the sequence without anyone reading raw log files.
FAQ
Can I undo one item from a batch?
Yes — that is the whole point of it.
Do I still need site backups?
Yes. Undo covers replacements the plugin made. It does not cover everything else that can go wrong.
Is undoing the same as deleting a file that was newly added?
No. A file that was added rather than replaced has no original to restore, so removing it is a different action and should be treated as one.
Summary
Safe undo depends on four things: the backup existing before the write, the plugin knowing exactly where that backup is, being able to restore one file rather than all of them, and checking afterwards that the public URL really shows the original.
Related: Large-batch safety · Replacement checklist · Shared-file safety