Skip to main content
Version: 4.0 preview

Latest features: platform and extensibility

Version
4.0 preview
Updated
View markdown

The part that decides whether a customized store is still updatable in three years. Two threads here: the core got harder to get wrong (generated types, prepared statements, exceptions instead of silent false), and the customization layer got more places to hook into without forking anything.

Back to Latest features


One application, three hosts — still true, and now proven per surface

The same CBX runs inside Joomla, WordPress and Magento 2: same admin screens, same data model, same release. What is new is how far that parity is carried — the CLI suite is the same suite on all three, the MCP server runs on all three, and the platform guides say where each host genuinely differs rather than leaving it to be discovered.

Records and schemas that cannot drift from the models

CBX generates, from each model's property definitions, a PHP record class and a JSON schema per entity — in a single pass, so the two cannot disagree — plus TypeScript types. That is what gives an editor autocompletion on a record that is otherwise a plain stdClass, and what lets the OpenAPI document and the MCP tool schemas describe the real fields rather than a hand-maintained approximation of them.

configbox:generate-types --check fails on drift, so CI can hold the line.

Prepared statements

KenedoDatabase gained a real mysqli prepared-statement path with named or positional placeholders and IN-list expansion. It is the sanctioned path for new queries; the historic string-built queries stay as they are, because half-converting a query is worse than either end state.

Refusals became exceptions

CBX used to report a refusal by returning false and parking a sentence in setError(). That protocol is retired in favour of exceptions — which matters to customization code specifically: a custom property type or model that still returns false keeps working, but one that throws nothing and reports nothing will silently accept bad data. Read the first section of the guide if you maintain anything in the customization layer.

The customization layer, extended

This is the feature that keeps customized CBX stores updatable for years: one directory that updates never touch. What it can now hold:

ExtendGuide
Templates, views, controllers, modelsviews & templates · controllers & models
Fields on stock modelsextending stock models · custom properties
A new kind of questioncustom question types · and making them legible to AI
A new rule conditioncustom rule conditions
A new calculation building blockcustom calc term types
A payment providerpayment connectors
Site-specific CLI commandscustom CLI commands
The admin's on-screen helphelp customization
Behaviour at defined pointsevents & observers · system overrides & boot hooks
Frontend JS/CSSassets & AMD
Wordinglanguage overrides

Customizations get their own migration track

A customization can ship versioned, idempotent update scripts of its own, applied on the same freeze-on-failure terms as the core track — and configbox:migrate --status and configbox:migrate:unblock both understand the distinction.

A heads-up for anyone with admin-UI customizations

The upcoming major release modernizes the admin form and list markup, CSS and JavaScript, and deliberately introduces breaking changes to the admin HTML structure and class names. There is a guide that says exactly what changed and how to amend custom CSS, custom admin JS and overridden backend templates. Read it before that release, not after.

For anyone automating CBX

Views announce their own readiness (view-init-done, and the cbViewInitialized event) at the point their handlers exist, not when the markup appeared — which removes a whole family of intermittent failures from browser automation. The marker was renamed from view-processed on 2026-08-16 because the old name invited exactly the wrong reading.

The framework itself


Back to Latest features · the Features track