It’s easy to make changes to a page and later realize the previous version was actually better. Version history is a crucial part of any CMS.
Both WordPress and SiteAdmin allow saving previous versions and enabling users to go back. However, the systems differ in how they use history and what constitutes a version.
WordPress saves content revisions
WordPress has a well-established revision system where previous versions of content can be saved. Revisions are available for both pages and posts.
This allows users to revert and compare previous changes or restore an older version if something goes wrong.
WordPress also includes auto-saving, meaning a current version can be saved even if you haven’t performed a standard manual publication.
The number of saved revisions can be influenced by WordPress configuration and various solutions used on the website.
SiteAdmin offers page version history
In SiteAdmin, version history is available for Pages. Every time a page is saved, a new version is created.
You can then open the page’s history, go back, and view previous versions to restore an older state.
This applies even if you’ve made significant changes to the page’s structure. When the page’s own HTML and CSS are part of the page, these are also saved alongside the version.
More than just text is saved
A key aspect of SiteAdmin’s revision system is that a page version isn’t just about the text on the page.
If the page includes its own HTML and CSS in the page’s custom code field, it is included when the version is saved. This allows you to revert to an older version of the page even after major layout or code changes.
However, if CSS is stored in a separate custom code block, that CSS is not part of the page’s revision in the same way, as it is handled separately from the page itself.
It’s important to distinguish between code that belongs directly to the page and code that is stored as a separate custom function.
Auto-saving in SiteAdmin
SiteAdmin also includes auto-saving. During editing, the current page can be automatically saved, ensuring there’s a newer version available if something goes wrong.
The auto-saving occurs at most once every five minutes, meaning the system doesn’t create a new history entry for every small change you make in the editor.
A manual save, however, creates a new version.
Restoring an older version
The version history isn’t just an archive; you can select an older version and restore the page to its previous state.
A key detail is that the restoration itself also saves as a new version.
If, for example, you want to revert from version 35 to version 20, a new version is created when you restore. The previous history doesn’t disappear just because you revert.
This allows you to test an older version without losing the existing history.
Up to 200 versions per page
SiteAdmin saves up to 200 versions per page, and the history has no time-based expiration.
When a page reaches 200 versions and a new version is saved, the oldest versions are removed. The history continues to roll forward instead of stopping.
Deleted versions cannot be restored.
In the editor, the 50 most recent saved versions of the remaining history are displayed.
WordPress or SiteAdmin?
| Aspect | WordPress | SiteAdmin |
|---|---|---|
| Revisions | Yes, for pages and posts | Yes, for pages |
| Manual saving | Revision can be created | New version saved |
| Auto-saving | Yes | Yes, at most every five minutes |
| Restoration | Yes | Yes |
| Restoration creates a new version | History can continue to be used | Yes |
| Page HTML/CSS | Depends on content and code structure | Page’s own HTML/CSS follows the version |
| Number of saved versions | Depends on configuration | Up to 200 per page |
| History time limit | Depends on configuration and storage | No time limit within saved versions |
Two Different Strengths
WordPress has the advantage of a well-established revision system that covers both pages and posts and has been around for a long time.
SiteAdmin has focused on making version history a clear part of the page editor. For each page, you can go back through saved versions and restore an older version without leaving the editor.
For those working extensively with page structure and code, it’s also beneficial that the page’s own HTML and CSS are included in the version history.
It’s important to note, however, that a separate custom code block is handled separately from the page’s version history.
Revisions ultimately serve the same purpose in both systems: enabling changes without fear of losing what worked before. The difference lies mainly in how comprehensive the systems are and how deeply version history is integrated into each CMS.