Developer getting started

2026-06-01 23:16:17

Where code lives and how requests flow.

Repository layout

Path	Contents
`public/`	Web root, `index.php`, uploads, static assets
`src/`	Application code (`App\` namespace)
`routes/`	Route groups included from bootstrap
`templates/`	Core admin and marketing Twig
`themes/`	Storefront themes
`plugins/`	Extensions
`database/migrations/`	Core schema SQL
`bin/cms.php`	CLI entry point

Request lifecycle

public/index.php loads Composer autoload and .env.
MySQL connection and settings bootstrap run.
Slim app is built; middleware registered.
Routes load in order: core → plugin public → plugin admin → content catch-alls.
Active plugins boot (PluginServiceProviderInterface::boot()).
Request dispatches to handler; Twig renders response.

Local development

composer install
composer plugin-deps:prod
composer migrate
composer serve
# Site at http://127.0.0.1:8080

Quality tools

composer test — PHPUnit and layout lint
composer phpstan — Static analysis
composer lint:twig-layouts — Storefront asset boundary checks

Documentation in repo

See docs/ for content types, plugins, themes, commerce, blueprints, config sync, and migrations. This Knowledge Base mirrors key topics for editorial teams.

Config sync (developers)

For environment promotion without full blueprints, use Tools → Config sync (/admin/tools/config-sync, requires manage_portability). Export named scope bundles (content types, menus, settings, roles, commerce rules), preview semantic diffs, and apply on staging. See the blueprints article for when to use blueprints vs config sync.