Skip to main content
Nothing an experience does reaches shoppers until you publish it. Building happens in a workspace; versions are how work leaves it, and publishing is how one version becomes the live one.

​
Versions

A version is an immutable snapshot of the experience as it was built at that moment. Saving one never overwrites an earlier version - it adds v2, v3, v4, each recorded with who saved it and when. That gives you three things the workspace alone can’t:
  • A stable thing to share. A version renders the same for everyone, whether or not the workspace is awake.
  • A safety net. Every earlier version stays available and publishable.
  • A record. Who saved what, and which version went live when.
Saving requires the workspace to be running - a version is a snapshot of the current build, so there has to be a build to snapshot.

​
Saving

Two buttons, one difference.

Save version

Saves the current build as a new version. Nothing goes live - use it to bank a good state before trying something risky, or to hand a version to a colleague for review.

Save & publish

Saves the current build as a new version and makes it the live one.
To publish a version you saved earlier - or roll back to an older one - pick it in the version picker and choose Publish. The picker marks the version that’s currently live.

​
The version picker

The picker above the canvas controls what you’re looking at: Switching between versions swaps the fragment on the canvas in place - the shop page around it doesn’t reload.

​
Rolling back

Rollback is publishing an older version. Pick it, publish it, and the live pointer moves - the experience isn’t rebuilt, re-validated, or re-rendered, so there’s no chance of the rollback producing something different from what that version originally was. This also means rollback is instant, and reversible in exactly the same way: publish the newer version again to move back.

​
Restoring a version’s code

Rollback moves what shoppers see. To move what you’re building on instead, open the version menu and pick Restore vN’s code, where N is the live version. Your workspace goes back to that version’s code, and any unsaved changes in it are replaced - which is why it asks first. A restore doesn’t create a version and doesn’t change which one is live. It’s for abandoning a line of work, not for changing the storefront.

​
Unpublished changes

An experience card shows Unpublished changes when its latest saved version isn’t the live one. That’s the normal state while work is in progress - it’s a reminder, not a problem. When the live version is the newest one, the card shows Live · v{n} instead.

​
Where a published version goes live

Publishing marks a version as the live one for that experience. What happens next depends on how the experience is bound.
Publishing writes the version’s rendered content into the Shopware CMS slot the experience was created from. The next storefront request renders it - no cache warm-up, no deploy, no Shopware plugin update. Shoppers see it in the storefront’s current language; if the version wasn’t built in that language, they see its primary language instead.The success toast links straight to both sides: Open Layout goes to the Shopping Experience layout in your Shopware admin, Open Storefront goes to the live page.See Frontic Experiences in Shopware for the full round trip.

​
When the Shopware sync fails

Pushing to Shopware is best-effort on purpose: a Shopware outage must not block a publish. If the slot update fails, the version still goes live in Frontic and you get told exactly that - the toast reads “v3 is live, but updating the Shopware slot failed”, and the experience card flags that the live version isn’t synced to the slot. Publish again once Shopware is reachable, and the slot catches up.

​
Sharing a preview

The share button copies a link to a saved version - the one on screen, or the latest save when you’re watching the live preview. Anyone with the link can open it - your team, or a client you build for - which makes it the thing to send for a sign-off. Links expire after a while, so send a fresh one if a sign-off drags on. A link is always pinned to a saved version, so the recipient sees exactly that version even if you keep building. If nothing has been saved yet, Share asks you to save a version first.

​
Stepping through versions

A shared preview with multiple versions shows a Versions control in its toolbar. Visitors can step through them in place, one at a time from the first to the latest, or press play to travel through them automatically - a quick way to show your team how a page got where it is.

​
Who can publish

Only an experience’s owner can publish it. Everyone else on the team can open it, share it and follow along, but making a version live is the owner’s call. The same applies to restoring a version’s code, since it replaces the owner’s workspace.

​
Publishing is not a release

Experiences sit outside Release Control. Publishing one doesn’t create a release, doesn’t wait for a release, and isn’t promoted from develop to public - it goes live when you press the button. That’s deliberate: the reason a campaign page can ship on a Tuesday afternoon is that it isn’t coupled to your backend’s release cadence. The flip side is that an experience isn’t rolled back by rolling back a release - roll it back by publishing an earlier version of the experience itself. Backend changes an experience depends on - a new Detail Block or Search Listing feeding it data - do still flow through releases in the normal way.

Building an experience

The canvas, stages, and Designer settings.

Shopware connector

Creating experiences from Shopware and publishing back into a CMS slot.

Experience Designer

What experiences are and how to create one.

Release Control

How backend changes ship - a separate flow from experience publishing.