ConfigBox / Kenedo — platform foundations
Audience: developers & AI agents · Scope: how the ConfigBox / Kenedo platform the site is built on works — a map to the foundational reference docs · Last reviewed: 2026-07-11
TL;DR — The Beta-Calco site is a Joomla site whose business logic lives in the ConfigBox product configurator, itself built on the Kenedo MVC framework. This folder is the platform reference: how the codebase is laid out and changed safely, how to run it locally, how DB migrations work, and how to give a page a clean URL. The feature docs (Quote Follow-Up, Pipedrive) all build on top of these.
The docs
| Doc | What it covers |
|---|---|
| architecture.md | How the codebase is laid out and the rules for changing it safely — core vs. the customization overlay, the request lifecycle, the override mechanisms, and naming conventions. Start here. |
| migrations.md | Changing the DB schema/data safely — the numbered, idempotent custom migrations and the KenedoDatabase API. |
| sef-links.md | Giving a custom ConfigBox page a clean SEF URL — link generation, the controller router hooks, and the menu item. Also the /cb-api/… XHR endpoint (a system-plugin frontname; a documented core exception). |
| environment.md | Running and inspecting the site locally — the DDEV stack, the database & credentials, SEF settings, and the deploy / live-sync tools. |
| worktrees.md | How we work day to day: one isolated site per branch — each worktree gets its own DDEV project, database, HTTPS host and copy of the runtime data, so testing and data changes can't reach the main checkout. |
The one rule that prevents breakage (see architecture.md): only edit Beta-Calco code under
docroot/components/com_configbox/data/customization/. Everything else — Joomla core, the Kenedo framework, vendored libs — is third-party and overwritten on update; change core behaviour through the override mechanisms, never by editing core.