Latest features: the admin
- Version
- 4.0 preview
- Updated
The back office got a lot of small repairs and a few whole new screens. Most of what follows is the kind of thing nobody puts on a feature list and everybody notices on day two: a form that saves the same way everywhere, a refusal that explains itself, help that is already on the screen, a backend that is readable at 11pm.
Dark mode, and one button family
The CBX backend follows the host admin's light / dark / auto preference — menus, forms, lists, the
calculation and rule editors, the dropdowns. Nothing to configure inside CBX; it reads the admin
template's own choice, and on hosts whose template does not announce it, the resolved scheme is stamped
on each view so prefers-color-scheme still works.
- What operators see
- Host-adaptation stylesheets — how CBX blends into three different admin chromes
- The
data-bs-themestamp, and where it is and is not emitted
The help is on the screen, and it is yours to change
Every backend list and form carries a short note in a help drawer, written from the shipping Admin Guide rather than maintained separately. On a customized install that would be worse than nothing — so the notes are extensible: append to any screen's note, add your own articles in a Customizations section, or shadow a shipped article entirely, all from the upgrade-safe customization layer.
One way to save, and refusals that say why
Every base admin task — store, delete, copy, publish, reorder — now authorizes, delegates to the model,
purges the cache and answers with one typed JSON envelope. The ajax* variants that existed only to
force the JSON branch are deprecated aliases; no task renders a list any more. The practical effect is
that a refusal carries its reason: deleting a record something else still points at returns
409 RECORD_IN_USE with the model's own "linked with these records" explanation, instead of a
silent failure or a generic error.
New screens
API tokens
Minting, listing and revoking the bearer tokens that authenticate the HTTP API is an admin screen, with per-token scopes and expiry — you do not need shell access to give an integration a key, and you do not need to hand out a superuser account either.
Product transfer
Export a product — its pages, questions, answers, detail panes, rules, calculations and images — as a package, and import it into another install. The screen validates a package before anything is written: blockers stop the import, warnings are shown for the operator to acknowledge.
- Admin Guide: move products between sites
- The package format, both import modes, and what is validated
The payment ledger
A filterable list of every payment (state, provider, test mode, date, order number), each row opening a detail view with the full event timeline, the provider's references, and the actions an operator actually needs: mark settled, mark failed, add a note, check with the provider. A refused transition shows its reason rather than dressing up as success. Alongside it: a payment-methods form that leads with the provider and swaps its configuration fields live, and a recent-events view for when a webhook misbehaves.
- Admin surfaces, and how provider secrets are stored
- Admin Guide: track payments · set up payment methods · choose a provider
The assistant's journal and its reports
If the store runs the AI assistant, the admin gets the record of it: every conversation with its turns, the model's stated reasons, every selection it attempted and every one the guards refused — plus a wishlist of what visitors asked for and the assistant could not do, and an insights report over the whole corpus.
- Read the conversation journal
- Run the insights report
- Work the wishlist · send recommendations to your team
Deleting a product is a first-class operation
A product is a graph, so deleting one is too. The admin deletes the product and its pages, questions, answers, detail panes, examples, its own calculations and their translations and files — behind a typed confirmation, and refused outright if anything outside the product still needs one of those records. A calculation that belongs to no product, or is used by another one, is left alone. Products referenced by past orders should be retired rather than deleted, and the guide says so.
- Admin Guide: copy and retire products
- What travels on a copy, and what a child list can opt out of
- The same operation as a tool:
cbx_delete_product_deep
Setup, health and the recurring jobs
- Run the setup wizard — store identity, country and tax mode, base currency, licence.
- The dashboard is a health check — the first place to look, including whether the database is on the charset CBX expects.
- Schedule the recurring scripts — the jobs that want a cron entry, now that several of them exist (see the CLI).
Authoring rules and prices
The rule editor validates a rule when it is saved, rather than letting a broken condition sit in the catalog until a customer meets it; calculations come in three forms (formula, code expression, matrix lookup) and each has a guide with worked examples.
- Build a rule · rule recipes · control what happens on change
- Build a calculation · price with a matrix · write a code expression · recurring pricing
Next: the HTTP API · the CLI · back to Latest features