Every time you save a field group, Field Forge automatically creates a revision — a snapshot of the field group’s complete state at that moment. This gives you a full history of changes and the ability to restore any previous version with one click. Think of it as an “undo” button that works across days, weeks, or even months.
Revisions protect you from accidental deletions, unintended changes, and misconfigurations. They are available on both the free and PRO plans.
Why Revisions Matter in Practice
Field group changes can have a significant impact on your site. Consider these scenarios:
- A new team member opens a field group “just to look at it,” accidentally deletes two fields, and clicks Save
- You reorganize 10 fields into a new tab layout, but the new layout confuses your editors and they want the old arrangement back
- You change a field from Text to Number, not realizing it causes existing text values to disappear from the frontend
- You update conditional logic rules and accidentally hide fields that editors need to see
Without revisions, recovering from any of these situations requires recreating the field group from memory or restoring a full site backup. With revisions, you click one button and the problem is solved in seconds.
Viewing Revision History
- Go to Field Forge > Field Groups and click on the field group you want to review
- In the field group editor, look for the Revisions button (near the top of the screen or in the sidebar, depending on your layout)
- Click Revisions to open the revision history panel
- The panel displays all saved revisions in a chronological list, newest first
- Each revision entry shows:
– User who made the change (the WordPress account name). Revisions created outside an admin session display a context-aware label instead — WP-CLI for command-line scripts, System cron for scheduled jobs, REST API for service-account requests, CLI script for ad-hoc PHP-CLI runs, or System as a generic fallback. This replaces the literal “Unknown” placeholder used in earlier versions and matches what the WordPress activity log shows for similar non-interactive events.
– Summary of what changed — fields added, removed, renamed, reordered, or settings modified
- Scroll through the list to find the revision you are interested in
[Screenshot: the Revisions panel showing a list of 8 revisions with dates, usernames, and change summaries like “Added 2 fields: Author Bio, Author Photo” and “Removed field: Legacy Description”]
Comparing Two Versions Side by Side
To understand exactly what changed between any two versions:
- In the Revisions panel, select the two revisions you want to compare (click each one, or use the comparison interface)
- A side-by-side (or inline) diff view appears showing the differences:
– Red highlighting — fields or settings that were removed in the newer version
– Yellow highlighting — fields or settings that were modified
- Review the diff to understand the full scope of changes
- Pay attention to field type changes (e.g., Text to Number) and deleted fields — these are the changes most likely to affect your site
- Use this comparison to decide whether to roll back or keep the current version
Rolling Back to a Previous Version
If you need to restore an earlier version of a field group:
- In the Revisions panel, find the version you want to restore
- Click Restore on that revision
- Field Forge automatically saves your current version as a new revision first (a safety backup — so you never lose the current state, even when rolling back)
- The selected revision is then restored as the active version
- All fields, settings, layout, conditional logic, and location rules return to exactly how they were at that point in time
- Go to the frontend and verify that the affected pages look correct
Practical Recovery Scenarios
| What Went Wrong | How to Fix It |
|---|---|
| Someone accidentally deleted a field | Open revisions, find the last version that had the field, click Restore |
| A field type was changed and data looks wrong on the frontend | Roll back to the version before the field type change |
| You reorganized fields and editors find the new layout confusing | Restore the previous layout — the old arrangement comes back exactly |
| You want to see how the field group looked three months ago | Browse revisions by date to find the version from that time period |
| A new team member made unintended changes | Compare their version with the previous one to see what changed, then restore if needed |
| You rolled back but realized the rollback was a mistake | The pre-rollback state was saved as its own revision — restore that one to undo the undo |
How Many Revisions Are Stored
- Field Forge keeps up to 50 revisions per field group
- When the 50th revision is saved, the oldest revision is automatically removed to make room
- Revisions are stored in the database and have negligible impact on site performance
- Revisions track field definitions (the structure and settings of the field group), not the content data that editors enter on individual posts
What Revisions Do and Do Not Track
| Tracked (Field Group Structure) | Not Tracked (Post Content) |
|---|---|
| Which fields exist in the group | The text an editor typed into a field on a specific post |
| Field types, labels, names, and settings | The image an editor uploaded on a specific post |
| Location rules | Which posts have been published or updated |
| Conditional logic | Changes to post content in the block editor |
| Field order and wrapper widths | Media Library uploads |
| Tab, Accordion, and Message layout fields | User account changes |
> Good to know: Revisions are available on both the free and PRO plans. Even if you are the only person managing your site, revisions protect you from your own mistakes. It is dramatically faster to click Restore than to try to remember and recreate a field configuration from memory.
> Tip: Before making major changes to a field group (like reorganizing all fields, splitting into tabs, or changing field types), make a mental note of the current revision number or date. If anything goes wrong, you know exactly which revision to roll back to. The automatic safety backup when restoring means you can always undo a rollback, too — you cannot make things worse by trying.
—