Versioning and history
How autosave, version history, and rollbacks work across Basker content
Basker keeps a version history of most content. As you edit, Basker saves your work automatically and keeps older versions. You can see what changed, compare points in time, and roll back if you need to.
What is versioned
Almost everything you edit in Basker is versioned. Pages, events, posts, people, venues, announcements, and most other content types track their full history. Some operational records (like media files or settings) keep a simpler audit trail rather than full version history.
If you can save a record as a draft and publish it, it is versioned.
Autosave
Basker saves your work as you go, so you do not need to manually save in the middle of an edit. Basker keeps edits as draft content, separate from the published version on the live site, until you publish the change.
Autosave runs continuously while you have a record open, roughly every second after you stop typing. Rather than creating a new version on every keystroke, autosave keeps a single rolling draft and updates it in place. This keeps your history readable instead of filling it with hundreds of small entries.
When your browser closes or you navigate away mid-edit, Basker preserves your in-progress work as the latest draft. Open the record again and you will resume from where you left off.
Drafts are per-record, not per-tab
Autosave saves the draft of the record, not of a particular browser tab. Every tab, session, or device that opens the same record is editing the same underlying draft. This matters when a record is open in more than one place at once. See Editing the same record in two places.
Viewing version history
Each record has a Version history option that lists past versions in reverse chronological order, newest first. Each entry shows:
- When the version was saved.
- Whether it was a draft, an autosave, or a publish.
Click a version to view its content as it stood at that point.
Who changed it?
The version history shows when and what, but not who. To find out which user made a change, and exactly what action they took, use Site activity, the site-wide audit log. Filter it by the record (the resource) to see who created, updated, or published it, and when.
Comparing versions
Open two versions side by side to compare them. Basker highlights the differences, so you can see exactly what changed, for example between last week's published version and the current draft.
Comparing is the safest way to understand a confusing change before you act on it. If a field looks wrong, compare the current draft against an earlier version to see precisely what was added or removed, and when.
Rolling back
To roll back to an earlier version, open the version you want to restore and choose Restore this version. Basker creates a new draft from the older version's content. Review the draft, then publish it normally to make the rollback live.
Rollbacks never overwrite history. The version you restored from stays in the record's timeline. Basker adds the new draft on top. This way, you can always see when a rollback happened, and you can step forward again if you change your mind.
Restoring an older version replaces your current content
Restore takes the record back to how it looked at the version you picked. Restoring does not bring forward newer edits, including custom attributes you added since that version. Basker does not delete these edits from history. You can still find them in the version list. They will not appear in the live or draft content until you restore them. Before you restore, pick the right version deliberately.
What a "stale version" is
A stale version is an older snapshot of a record that no longer reflects the most recent work. Every entry in the version history is a point in time. Once you have made newer edits, the earlier entries are stale by definition.
Stale versions are normal and harmless on their own. They are just history. They cause problems only when an older snapshot ends up replacing newer content. That can happen two ways:
- Restoring the wrong version. Restoring a version from before your latest edits creates a draft that is missing everything you added since, including custom attributes you entered afterward. The newer values are still in history, but they are no longer in the working draft.
- An older edit session overwriting a newer one. If the same record is open in two tabs or sessions, the one with older content can save over the newer content. This is an edit collision, covered next.
Editing the same record in two places
The draft belongs to the record, not to a tab. Opening the same record in two browser tabs, two windows, two devices, or two logins means two editors are pointed at the same draft.
Picture this sequence:
You open an event in Tab A in the morning. You add several custom attributes. Autosave stores them in the draft.
Earlier, you left the same event open in Tab B. You loaded Tab B before you added those attributes in Tab A. Tab B still shows the older content.
You make a small change in Tab B, or Tab B autosaves on its own. Tab B saves the content it is holding. This is the older version, without the new attributes.
The draft now reflects Tab B's stale content. The attributes you added in Tab A are gone from the working draft, though they remain in the version history.
No one deleted the attributes on purpose. An older tab simply held an outdated copy of the record and saved it over the newer one. To anyone looking the next day, the custom attributes appear to have "disappeared overnight." In fact, that older tab saved a stale draft on top of them. The content is still recoverable from the version history.
Why autosave makes this easy to miss
On content types with autosave, such as events, pages, and posts, a forgotten tab can save its stale copy without you clicking anything. Basker does not always warn you when this happens. To avoid this, do not keep the same record open in more than one place at once.
Avoiding unexpected overwrites
A few habits prevent almost every accidental overwrite of custom attributes and other edits:
- Edit a record in one place at a time. Close other tabs, windows, and devices showing the same record before you start. If you have had a record open for a while, reload it before you edit, so you work from the latest draft.
- Do not leave records open overnight. A tab left open with stale content is the most common cause of a "disappearing edits" surprise. Close it, or reload it, before you make further changes.
- Restore deliberately. Before you choose Restore this version, open the version and check its date and contents. Ideally, compare it against the current draft first. Restore the version that contains the work you want to keep, not simply the most recent-looking one.
- Check the version history if content looks wrong. If a field or custom attribute seems to have vanished, do not re-enter it from scratch. Open the version history and find the version that still has it. Restore that version. Your work is almost certainly still there.
- Use Site activity to investigate. When you need to understand who changed something and when, Site activity is the audit trail that ties actions to users.
Your edits are rarely truly lost
Because rollbacks and edit collisions never erase history, content that "disappears" is almost always still in the version list. Restoring the version that still contains it brings the content back.