Skip to main content
Version: 3.x

Evaluating CBX — the technical facts

Version
3.x
Updated
View markdown

For the person deciding whether CBX fits their company's stack: what it is, what it runs on, how it integrates, where its boundaries are, and the things a technical evaluation should know before anyone builds a prototype. Everything here is covered in depth elsewhere in this documentation — this page is the map.

Evaluating how fast it moves, not just what it does? Latest features is the what's-new track — everything that landed since the 4.0 line opened, one article per surface, with every claim linked to the documentation behind it.

What it is​

CBX is a product configurator and e-commerce platform by Rovexo. A product is modeled as a tree — Product → Pages → Questions → Answers — with a rule engine (conditional show/hide/ require logic), a calculation engine (formula, matrix and code-based pricing, weights, recurring prices) and a commerce layer (cart, checkout, quotations, orders, customers). The same application core runs on four hosts:

On Joomla and WordPress, CBX is the full shop (its own product lists, cart, checkout, orders). On Magento 2 the division is deliberate: CBX is the configurator; Magento owns cart, checkout and orders — a configured item travels as a custom option on the Magento product. Details: the platform guides.

System requirements​

JoomlaWordPressMagento 2
Host versionJoomla 3.0 – 6.99WordPress ≥ 5.0Magento 2 (module via composer require rovexo/configbox-magento2)
PHP7.4 – 8.57.1 – 8.4 (8.0 excluded)per your Magento version
PHP extensionsgd, json, mbstring, mysqli, … (installer-enforced)gd, mbstring, mysqli, xml, zip, openssl, … (activation-checked)standard Magento stack
DatabaseMySQL (InnoDB, real foreign keys, utf8mb4)samesame
ionCube Loader (free)15+ on PHP 8.4, 14+ on 8.3, 13+ belowsamesame

About the ionCube Loader — smaller than it sounds​

Two facts put this row in proportion:

  • Only a minimal slice of the codebase is encoded: the five files of the pricing/rules/ calculation engine. Everything else — every controller, model, view, template, the frontend JavaScript, and the entire customization layer (overrides, custom properties, custom rule conditions and calc terms, boot hooks) — is plain, readable PHP. You customize and debug against open code; the encoded engine sits behind documented interfaces you never need to open.
  • The loader is a solved problem, not a project. It's a free, standard PHP extension that most shared-hosting panels (cPanel, Plesk) ship preinstalled or enable with one click; on your own servers it's a routine one-file extension install, and ioncube.com's wizard hands you the right build for any PHP. CBX's installers check for it and tell you plainly if it's missing — nothing fails silently.

Integration surfaces​

Four ways in, all first-class and all reading/writing through one shared service layer, so no surface can disagree with another:

  • REST API (/cb-api/v1/…) — resource CRUD over every entity the models describe, RFC 6750 bearer tokens with read/write scopes, OpenAPI 3.1 document served by the API itself, JSON Schema per entity, RFC 9457 problem+json errors. See the entity API and the API contract.
  • Runtime API — configure a product, drive a cart and check out without a browser (headless storefronts, mobile apps, agents): the runtime API.
  • MCP server — the same catalog CRUD exposed as tools for AI assistants (configbox:mcp): the MCP server.
  • CLI — migrations, cache, config, API tokens, type generation, task execution (configbox:* on Joomla, wp configbox … on WordPress): the CLI suite.
  • PHP events — if you're looking for "webhooks": CBX's hooks are in-process PHP events (onConfigBoxAddToCart, onConfigBoxSetStatus, …) you subscribe to with an observer class — events and observers. Outbound HTTP calls are yours to make from an observer.
  • Generated types — JSON Schemas, PHP record stubs and TypeScript types are generated from the same model metadata the API serves: type generation.

The five-minute API test​

On a dev install (Joomla shown; WordPress mirrors it with wp configbox):

# 1. Mint a read token
php cli/joomla.php configbox:token:mint --name=eval --scopes=read

# 2. First request
curl -H "Authorization: Bearer <token>" https://your-site.example/cb-api/v1/products

# 3. The API describes itself
curl -H "Authorization: Bearer <token>" https://your-site.example/cb-api/v1/openapi.json

Commerce scope​

  • Multilingual by design: every translatable field carries one value per active language (stored in CBX's own string store, not host language files); the admin shows one input per language; the API serves flat title_en_GB-style keys.
  • Multi-currency with a shipped currencies module; taxes with tax classes, per-country rates, EU VAT handling and B2B/B2C display modes — configured in the setup wizard and editable later.
  • Orders are frozen snapshots: at checkout the configuration, prices and tax rates are copied into dedicated order tables, so later catalog edits never rewrite history.
  • Quotations and saved carts alongside direct orders; payment methods/providers pluggable via payment connectors.

Operating it​

  • Updates are a package re-install on Joomla (no one-click updater in Joomla's Update screen — deliberate, see the platform guide) and standard plugin/composer flows elsewhere.
  • Schema migrations run themselves: versioned, idempotent scripts apply on boot and are driveable/inspectable from the CLI (configbox:migrate --status) — migrations.
  • 3.x → 4.0: version 4.0 renames the catalog vocabulary (elements/options → questions/ answers) with a fully automated data migration; the migration section documents every rename, and this documentation is published for both versions (see the version switcher above).

Licensing​

CBX is commercial software: a license key (entered in the setup wizard, editable later) activates an install, managed through the Rovexo Client Center. Editions and terms: configbox.at licensing. For pre-sales questions the www.configbox.at contact routes reach the team directly.

Where to go deeper​

The 60-second architecture read is the four ways in; the honest internals live under Developer Reference (the Kenedo framework, both engines, the HTTP API); building a first product is the Admin Guide's getting-started path.

Last updated on