Versioning and history
How autosave, version history, and rollbacks work across Basker content
Basker keeps a version history of most content. As you edit, your work is saved automatically; older versions are retained so you can see what changed, compare points in time, and roll back if you need to.
What's 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's versioned.
Autosave
Basker saves your work as you go, so you don't need to manually save in the middle of an edit. Edits are kept as draft state, 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 brand-new version on every keystroke, autosave keeps a single rolling draft and updates it in place, so your history stays readable instead of filling up with hundreds of tiny entries.
When your browser closes or you navigate away mid-edit, your in-progress work is preserved as the latest draft. Open the record again and you'll 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. Differences are highlighted so you can see exactly what changed between, for example, 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, and the new draft is added on top — so you can always see when a rollback happened and 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. Any newer edits — including custom attributes you added since that version — are not carried forward into the restored draft. They aren't deleted from history (you can still find them in the version list), but they won't be in the live or draft content until you bring them back. Always pick the right version deliberately before restoring.
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've made newer edits, the earlier entries are stale by definition.
Stale versions are completely normal and harmless on their own — they're just history. They only cause problems 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's missing everything you added since — for example, custom attributes filled in afterwards. The newer values are still in history, but they're 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
Because 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 and add several custom attributes. Autosave stores them in the draft.
Earlier, you left the same event open in Tab B — loaded before you added those attributes, so Tab B still shows the older content.
You make any small change in Tab B (or it autosaves on its own). Tab B saves the content it is holding — 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. A second view simply held an older 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" — when in fact a stale draft was saved on top of them, and the good content is still recoverable from the version history.
Why autosave makes this easy to miss
On content types with autosave (events, pages, posts, and most others), a forgotten tab can save its stale copy without you clicking anything. Basker won't always interrupt you with a warning when this happens, so the safest habit is to avoid having 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've had a record open for a while, reload it before editing so you're working from the latest draft.
- Don't 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 making further changes.
- Restore deliberately. Before choosing 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, don't re-enter it from scratch. Open the version history, find the version that still has it, and restore that — 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 sitting in the version list. Restoring the version that still contains it brings it back.