Skip to main content
Version: 4.0 preview

CBX — Features

Version
4.0 preview
Updated
View markdown

What CBX can do, at a glance. This track is the showcase: each section makes the case for one capability area the way you would to a prospect or a decision-maker — and then backs every claim with links into the documentation that describes it in full. If a claim here has no link, treat that as a bug in this track.

Audience: people evaluating CBX — shop owners, agencies, integrators scoping a project — and anyone who needs the "why", not yet the "how". For the how: the Admin Guide (running a store), functional/ (exhaustive behavior), technical/ (the code), and customization/ (extending it).

Already know CBX and want to know what changed? → Latest features — what has landed since the 4.0 line opened, area by area: configurator & storefront · the admin · the HTTP API · the CLI · the MCP server · the AI assistant · payments & commerce · catalog operations · platform & extensibility. (For the CBX 2/3 → CBX 4 upgrade story instead, see migration-to-cb4/.)

A real product configurator, not a form builder​

Customers compose products step by step — pages, questions, answers — with a live price at every click, conditional show/hide logic, quantity and text inputs, image uploads, and optional 2D/3D visualization (including ShapeDiver-backed parametric 3D). Configurations are first-class objects: they can be saved, re-edited from the cart, and they freeze into the order exactly as configured.

Pricing and logic without a developer​

Store admins author conditional rules ("show the motor question only for the cargo frame") and calculations (formula, code, or matrix — e.g. price by width × height lookup) in the admin UI. The rule and calculation engines evaluate live in the configurator and again server-side, so the price the customer sees is the price the order stores.

Commerce built in — or your platform's​

CBX ships a complete flow around the configurator: cart, checkout, customer accounts, quotations, invoices, order processing, transactional e-mails, taxes, shipping and payment methods (extensible PSP connectors). On Magento 2, CBX instead plugs its configurator into Magento's own cart/checkout/orders — you choose the commerce brain per platform.

One application, three host platforms​

The same CBX application runs inside Joomla, WordPress and Magento 2 — same admin screens, same data model, same release. Your team's platform choice doesn't fork the product, and a store can migrate hosts without rebuilding its catalog. A platform-abstraction layer (Kenedo) keeps behavior identical; each host gets a native integration (menus/SEF on Joomla, shortcodes and hidden post types on WordPress, catalog integration on Magento 2).

Multi-language, multi-currency, B2B-ready​

Every customer-facing text — product names, questions, answers, URL segments — is translatable in-place (flag icons next to each field), with per-language SEF URLs. Currencies, tax classes and geography-aware rates are built in. Customer groups are the B2B policy hub: per-group discounts and tax mode, whether a group sees prices at all, per-group shipping methods, and quotation (RFQ) workflows alongside direct orders.

Operations tooling that respects your deploy pipeline​

A full CLI suite ships on every platform (wp configbox …, php cli/joomla.php configbox:…, bin/magento configbox:…): cache clearing, deploy-gate migration status (non-zero exit while work is pending), guided recovery from failed migrations, settings read/write with UI-grade validation, and run-task to exercise any endpoint headlessly. Schema updates are versioned, idempotent scripts with an explicit freeze-on-failure design. There is even an MCP server, so an AI assistant can read your catalog through typed tools.

Move a product between installs, logic and all​

A configured product is not one record — it is pages, questions, answers, detail panes, the rules wired through all of it, every calculation any of it uses, and the images hanging off any of those. Product transfer packages the whole graph as a zip and imports it into another CBX install: build on staging and push to live, or lift a product from one client's site to another. References are re-aimed on arrival — a rule that named answer 412 on the source names the right answer here — while things that belong to the target, like tax classes and customer groups, are matched by name and never invented. The import is checked before anything is written: blockers stop it, warnings are shown for the operator to acknowledge, and a package can be imported either as fresh products or under the original IDs to overwrite what is there. Both halves have a command-line equivalent, so it drops into a deploy script.

Smaller things that make the admin's day easier​

Not headline capabilities — the everyday friction that gets filed down release by release.

  • Images straight into any rich-text field. Drag a photo onto a product description, paste one from the clipboard, or pick it in the editor's image dialog. It is stored where an extension update will not touch it, scaled down to a sensible web size, and converted to WebP — so a 6000-pixel camera original does not become a several-megabyte product page. Uploading the same picture twice reuses the first one rather than filling the disk with copies.

  • Editor image upload: what happens to the file and where it lands

The customization layer — extend it without forking it​

Agencies and in-house developers get a supported, upgrade-safe extension layer: override templates, add fields to stock models, write event observers, payment connectors, custom rule conditions, custom admin field types, frontend JS/CSS modules — and even site-specific CLI commands — all in one directory that updates never touch. This is the feature that keeps customized CBX stores updatable for years.

→ The customization layer, in full (this track's deep-dive section)

What has changed lately​

The sections above describe CBX as it stands. Latest features is the other cut of the same product: what has landed since the 4.0 line opened — across the storefront, the admin, the HTTP API, the CLI, the MCP server, the AI assistant, payments, catalog operations and the extension layer — one child article per area, same linking rule.

→ Latest features (this track's what's-new section)

Every capability above is documented in depth — start at the documentation index. Found a claim without a link, or a capability without a section? Extend this track; it is maintained with the product.

Last updated on