Latest features: the configurator and the storefront
- Version
- 4.0 preview
- Updated
What a shopper meets has changed the most. The configurator kept its shape — pages, questions, answers, a live price — and gained a conversation partner, an honest client state, a headless twin, and a set of small corrections in the places where a store actually loses an order: the address step, the delivery selection, the moment a select claims a value nobody chose.
An assistant sits beside the configurator
A visitor configuring a product gets a floating chat panel. It knows the product — structure, answers, prices, descriptions, detail panes — talks in the visitor's language, and acts: it makes selections, explains why an option is unavailable, runs what-ifs, scrolls the page to the question it is talking about, and puts the finished configuration in the cart.
The design decision that makes it safe is worth stating: the assistant is a second client of the same runtime API the page itself uses, executed in the visitor's own request and session. There is one configuration state, one validation path, one refresh mechanism — so the assistant can never do anything the visitor could not do themselves, and there is no admin surface behind any of its tools.
The client state became a store
The configurator page's client state used to be a write-once jQuery blob on #configurator-data that
drifted out of sync with the server the moment anything interacted. It is now a small Redux-style
store — a single immutable state tree with dispatch / getState / subscribe, normalised
questions by id, a per-question selection map, and one action that folds each server response in
atomically. The classic accessors still work as thin shims over it, so existing customizations are
unaffected.
Questions that can describe themselves
CBX ships twelve question types. What is new is that a custom type no longer has to be a black box to everything except its own template: a type can now state what a selection means, what it accepts, and what SKU it stands for — which is what lets the chat advisor, the runtime API and any headless client operate it as fluently as a stock type instead of guessing at its payload shape.
- Question types the AI understands and controls
- Adding a question type — including
getSku($selection), the override that makes a type ordered rather than merely configured, so the order line freezes the part number the selection stands for
A product can be configured without a browser
Everything the configurator page does is reachable with an HTTP client and a cookie jar: fetch the configuration, set a selection, preview one without committing it, ask why a question is unavailable, add the result to the cart. Nothing needs HTML parsing. This is what the assistant runs on, and it is equally the surface for a headless storefront, a mobile app or an integration test.
The address step tells the truth
The country → state → county pickers rebuild each other as the visitor chooses. That rebuild used to drop the "please choose" placeholder, which silently made whichever state sorted first the select's value while the widget on screen displayed something else — a wrong address that looked like a chosen one. The cascade now keeps an explicit placeholder with its localized label through every rebuild.
Checkout, all the way to the thank-you page
The classic checkout takes money through the payment subsystem: a ledger, an explicit state machine, and settlement by return, webhook or poll. The journey through to the thank-you page — including what a customer sees while a payment is still pending — is covered end to end.
Prices only where they belong
Whether a visitor sees prices at all is a customer-group policy, not a template choice — a B2B group can be set to request a quote instead of seeing figures. That policy holds on every surface, including the headless ones.
Quotes, saved carts, and editing a configuration again
A configuration is a first-class object, not a form submission: it can be saved, reopened from the cart and re-edited, quoted rather than ordered, and it freezes into the order exactly as configured.
- Quotations and saved carts
- What end-customers can do, as user stories
- Editing a product from the storefront
A view that says when it is ready
Small, but it removes a whole family of intermittent failures from anyone automating the storefront or
the admin. Every CBX view now marks itself view-init-done (and fires cbViewInitialized) at the
point its handlers actually exist — not when the markup appeared. The old marker was called
view-processed, a name that invited exactly the wrong reading, and was renamed on 2026-08-16.
Images in any rich-text field
Drag, paste or pick a photo in any CBX rich-text editor and it is stored, downscaled and converted to WebP for you. The Features track's own bullet describes what happens to the file; the implementation is in Editor image upload.
Next: the admin · the HTTP API · back to Latest features