omnisense/omnibase

Getting started

Requirements

What composer.json requires:

glitchr/backup-manager (the TimeMachine, the backups) is suggested, not required: see below.

The framework itself is not required by the core (since 4.0, see What the core requires): under Symfony it comes with omnibridge/symfony (FrameworkBundle, SecurityBundle, TwigBundle, DoctrineBundle, MonologBundle, Messenger, Form, 6.1 to 8). The sites run MySQL 8; the core's harness runs on SQLite. The commands doctrine:schema:charset and doctrine:array:upgrade, and the backups, are MySQL's.

Installation in a Symfony application

composer config allow-plugins.omnibridge/composer true
composer require omnisense/omnibase:5.x-dev omnibridge/symfony:1.x-dev omnibridge/doctrine:1.x-dev omnibridge/twig:1.x-dev

Since 5.0 the core is a library that requires neither Symfony's framework nor Doctrine nor Twig (What the core requires): omnibridge/symfony is the bundle and the framework, omnibridge/doctrine the persistence, omnibridge/twig Twig's helpers. A feature that needs a package the core only suggests (symfony/http-client, phpoffice/phpspreadsheet, web-auth/webauthn-lib, florianv/swap, league/flysystem-ftp, symfony/discord-notifier, the Twig extras) asks the application to require it. Upgrading from 4.x: UPGRADE-5.0.md.

omnibridge/composer is a Composer plugin (it applies the core's patch to symfony/process): Composer asks before it runs one, hence the first line. omnibridge/doctrine and omnibridge/twig are the application's to require since 5.0 (4.x required omnibridge/doctrine).

The backups (Backups, the timemachine:* commands) need glitchr/backup-manager, a suggestion of the core since 4.0: a site that backs up through the TimeMachine requires it at its root.

composer require glitchr/backup-manager:4.0.*-dev

Without it the TimeMachine and its commands are not registered, and base.time_machine is read by nothing.

Register the bundle in config/bundles.php, after the bundles it works with:

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Symfony\Bundle\TwigBundle\TwigBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
    Symfony\Bundle\SecurityBundle\SecurityBundle::class => ['all' => true],
    // ...
    // omnibase's bundle, omnibridge/symfony's since 5.0 (Base\BaseBundle in 4.x)
    Omnibridge\Symfony\Omnibase\BaseBundle::class => ['all' => true],
];

Give it its configuration, config/packages/base.yaml - the smallest one is in the Configuration reference - and import its routes (Routes and access). Then the schema and the front end:

php bin/console doctrine:migrations:migrate
npm install && npm run dev
php bin/console cache:clear

A new site is better started from an existing one: Scaffolding a site says what to copy and in which order to start it. The core's harness (The Docker harness) runs the core with every omnibase/* plugin, without a site.

Conventions

The Base\ namespace mirrors App\: a class in Base\Entity\User is aliased so the application can override it at App\Entity\User without the bundle knowing. This is deliberate and load-bearing — do not rename it. bin/console base:mapping lists the aliases (Console commands).

Scaffolding a site

A new omnibase site starts as a copy of an existing site (~/Sites/<site>), the reference application: Symfony 8, PHP 8.4, Docker, omnisense/omnibase 3.x with omnibase/admin, omnibase/marketplace and the omnibase/* bundles of its trade. This page is the exact list: what is copied and then adapted, and what is no longer copied because a package provides it.

What a new site copies

The project's frame (copied as is, then names and ports changed)

Never copied: .env.local and .htpasswd. Both are git-ignored and belong to one deployment: .env.local holds the other site's secrets (its Stripe and mail keys, its database password) and would point the new site at them; .htpasswd holds the other site's beta credentials. A copy made with cp -R or rsync takes them along with the rest: copy from git ls-files (or git archive HEAD | tar -x -C ../newsite), or exclude the two by name. The new site writes its own - .env.local by hand, .htpasswd with make htpasswd (the proxy mounts ./.htpasswd: without the file Docker creates a directory of that name, and the protected hosts cannot check a password).

symfony.lock comes with composer.json

symfony.lock is Flex's record of the recipes already applied, one entry per package. Without it Flex takes every package of the first composer install for a new one and plays every recipe again: it rewrites config/bundles.php, drops its default config/packages/*.yaml, config/routes/*.yaml, .env blocks, src/Kernel.php, public/index.php and bin/console over the files just copied from the reference site - the site then boots on Symfony's defaults instead of omnibase's configuration (or does not boot: two Doctrine configurations, a second security firewall).

So the copy takes symfony.lock (it is tracked: git ls-files and git archive include it). After the first install, git status must show no change under config/; a package added later is a composer require, whose recipe adds its entry to the lock - commit it with the rest.

A copy made without it is repaired before the first install: take the reference site's symfony.lock, remove the entries of the packages the new site does not require (or leave them: an entry without its package is ignored). If the recipes already ran, git checkout -- config/ .env src/Kernel.php public/index.php bin/console on a copy that was committed first, else copy those paths again.

Fonts: @fontsource 5.3 and its exports

The sites install their fonts from @fontsource/<font> (^5.2 in package.json) and import the files they use in assets/styles/app-async.scss:

@import "@fontsource/andika/latin-400.css";      // <subset>-<weight>[-italic].css
@import "@fontsource/andika/latin-700.css";

From 5.3.0 a fontsource package declares an exports map, and the bundler (webpack's resolver, which sass-loader and css-loader use) refuses every path the map does not list. What it lists, and so what still resolves by package name: the package itself (@fontsource/andika: index.css), the stylesheets at its root (/latin-400.css, /400.css, /latin.css...), the font files (/files/andika-latin-400-normal.woff2), and /scss (the metadata, from Sass only).

What no longer resolves by package name - "Package path ./scss/mixins is not exported from package …/@fontsource/andika" - is anything else inside the package, the Sass mixins first:

@use "@fontsource/andika/scss/mixins" as andika;                          // 5.3: refused
@use "../../node_modules/@fontsource/andika/scss/mixins.scss" as andika;  // by relative path: resolves

A relative path through node_modules is not a package request: the exports map does not apply to it, and it resolves whatever the version. Use it for the paths the map leaves out; keep the package name for the stylesheets above, which it lists. (Checked on 5.3.0 with webpack's enhanced-resolve 5.26, sass-loader 16 and css-loader 7 - the versions the sites build with.)

Docker networks: a subnet per site

Each site has two networks (extranet, intranet), and Docker gives each a subnet of its default address pools. With many sites up at once the pools run out and up fails on "could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network" (or "all predefined address pools have been fully subnetted"). A site therefore fixes its two subnets in docker-compose.override.yml, numbered after its ports so that no two sites share one:

# docker-compose.override.yml
networks:
  extranet:
    ipam:
      config:
        - subnet: ${NETWORK_EXTRANET_SUBNET:-10.110.126.0/24}   # HTTP port 8126: 126 and 127
  intranet:
    ipam:
      config:
        - subnet: ${NETWORK_INTRANET_SUBNET:-10.110.127.0/24}

NETWORK_EXTRANET_SUBNET and NETWORK_INTRANET_SUBNET (.env.local) move them on a host where those ranges are taken. A subnet changes only when its network is recreated: make down, then make up. See also Stopping a site.

Configuration (copied, then trimmed to the site's bundles)

config/bundles.php, config/services.yaml (its app.site.* parameters), config/routes.yaml (one import per bundle's client controllers), config/routes_paths.yaml (the localized paths), config/routes/* (base_admin.yaml is what routes the back office, its system pages included), and config/packages/*: base.yaml, admin.yaml, doctrine.yaml, security.yaml, framework.yaml, cache.yaml (its cache.redis pool), marketplace.yaml and omnitrade.yaml for a shop, consent.yaml, one file per bundle, and the rest as they are.

The site's own code (copied as a model, rewritten)

A shop's User is its merchant

omnibase/marketplace's products, stores and orders are related to "whoever sells", Base\Marketplace\Model\MerchantInterface, which Doctrine binds to a class of the application. A site that installs the marketplace declares both; without them Doctrine cannot map those entities (the target entity Base\Marketplace\Model\MerchantInterface is not found) and no migration can be generated:

// src/Entity/User.php
use Base\Marketplace\Model\MerchantInterface;

class User extends \Base\Entity\User implements MerchantInterface
{
    #[ORM\Column(length: 255, nullable: true)]
    protected ?string $companyName = null;

    public function getCompanyName(): ?string { return $this->companyName; }   // the interface's one method
}

# config/packages/doctrine.yaml
doctrine:
    orm:
        resolve_target_entities:
            Base\Marketplace\Model\MerchantInterface: App\Entity\User

A shop with a merchant class of its own (App\Entity\User\Merchant, a subclass of User) names that class instead. A site without the marketplace needs neither.

Glitch Art's signature: mirror: true on the left

The footer's credit is @Base/partials/_credits.html.twig, black or white only (Front end). Its detail line opens towards the inside of the page: by default on the left of the signature, for a signature set on the right of its footer. A site that sets the signature on the left passes mirror: true, or the detail opens outwards, over the page's margin:

{% include '@Base/partials/_credits.html.twig' with {mirror: true} %}                  {# signature on the left #}
{% include '@Base/partials/_credits.html.twig' with {color: 'white', outline: true} %}  {# on the right, on a photo #}

Secrets {#secrets}

bin/console secrets:set, secrets:generate-keys and secrets:remove write under config/secrets/<env>/. The web container cannot: it mounts the project read-only (.:/srv/app:ro; only var/, vendor/ and public/ are writable), and the command fails on "Unable to create the secrets directory (/srv/app/config/secrets/dev)" - a make shortcut that runs in <app>-web-1 fails the same way.

Run them where the project is writable: the one-shot composer service of docker-compose.setup.yml, which mounts .:/srv/app:rw and reads the same .env and .env.local:

# the key pair of an environment (once per environment; see Sealed fields)
docker compose -f docker-compose.yml -f docker-compose.setup.yml run --rm --entrypoint "" composer \
    php bin/console secrets:generate-keys

# a secret, read from standard input so that it stays out of the shell's history
printf %s "$STRIPE_SECRET" | docker compose -f docker-compose.yml -f docker-compose.setup.yml run --rm -T --entrypoint "" composer \
    php bin/console secrets:set STRIPE_API_KEY -

# production's: with the public key alone, on any machine
docker compose -f docker-compose.yml -f docker-compose.setup.yml run --rm --entrypoint "" composer \
    php bin/console secrets:set STRIPE_API_KEY --env=prod

(--entrypoint "" skips the service's own entrypoint, which runs a whole composer install. On a machine with PHP, php bin/console secrets:set … from the project's directory does the same.)

Then: commit config/secrets/<env>/ except prod.decrypt.private.php (git-ignored: check .gitignore has a line for config/secrets/prod*/prod*.decrypt.private.php), and clear the cache of the running site (docker exec <app>-web-1 php bin/console cache:clear): the secrets are read when the container is compiled. Reading them works in the web container: make secrets (secrets:list --reveal).

The same key pair seals the fields marked #[Vault] - the API keys typed in the back office - and without it they are refused, not stored in clear: see Sealed fields.

The demonstration: what a site adds {#demo}

APP_ENV=demo runs the site as a demonstration (The demo environment): production's behaviour, a database of its own (<database>_demo), the demonstration account named in the banner of every page, one button for each role on the sign-in page, a back office that opens with a secret, a reset every night. Everything is in omnisense/omnibase; a site adds these lines.

.env.demo (committed: defaults only, as .env.prod; no secret):

HTTPS=on
HTTP_REDUCTION=true
HTTP_DOMAIN='["demo.example.org", "localhost"]'
HTTP_SUBDOMAIN='["", "www"]'
HTTP_MACHINE='[""]'
HTTP_BASEDIR=/
HTTP_PORT='[80,8126]'
HTTPS_PORT='[443,8643]'
USE_SYS_TMPDIR=false
# DEMO_SUPERADMIN_PASSWORD and DEMO_ADMIN_PASSWORD are NOT here: the passwords
# of the super-administrator and of the back office's accounts (ROLE_ADMIN) in
# the demonstration are secrets of the server (.env.demo.local, git-ignored,
# or real variables). Unset, those accounts cannot sign in.

A real variable beats every .env* file, and the containers get .env as real variables: .env.demo cannot change what .env defines. What differs in demo is said under when@demo.

config/bundles.php - the fixtures are loaded in demo:

Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle::class => ['dev' => true, 'test' => true, 'demo' => true],

(doctrine/doctrine-fixtures-bundle is in require-dev: deployments/docker/composer/entrypoint.sh installs the dev packages for demo too - a demo*) composer install --no-interaction ;; beside test*).)

config/services.yaml - the fixtures are services where the bundle is:

when@dev: &fixtures
    services:
        App\DataFixtures\:
            resource: '../src/DataFixtures/'
            autowire: true
            autoconfigure: true

when@demo: *fixtures

config/packages/doctrine.yaml - production's pools, a database of its own:

when@prod: &prod
    framework:
        cache:
            pools:
                doctrine.result_cache_pool: { adapter: cache.app }
                doctrine.system_cache_pool: { adapter: cache.system }

when@demo:
    <<: *prod
    doctrine:
        dbal:
            connections:
                default:
                    dbname_suffix: '_demo'

config/packages/base.yaml - which database production's is (the demonstration refuses to start on it, and without this line):

when@demo:
    base:
        demo:
            production_database: 'mysql://%env(DOCTRINE_DATABASE_HOST)%:%env(DOCTRINE_DATABASE_PORT)%/%env(DOCTRINE_DATABASE)%'
            reset:
                purge: []      # storages of the site's own that demo:reset empties

Every other when@prod (monolog.yaml, ...): when@prod: &prod, then when@demo: *prod at the end of the file. config/packages/mailer.yaml: when@demo: { framework: { mailer: { dsn: 'null://null' } } } (omnibase refuses every message in demo whatever the DSN; this keeps anything else from trying).

deployments/docker/cron/crontab - the same file in every environment, so the line checks:

30  3  * * *  [ "$APP_ENV" = demo ] && php /srv/app/bin/console demo:reset >> /srv/app/var/log/cron.demo-reset.log 2>&1

config/packages/flysystem.yaml - the demonstration's files in directories of its own, which demo:reset empties: nothing of another environment is ever there (a development machine runs both from one checkout):

when@demo:
    flysystem:
        storages:
            local.uploads: { local: { directory: '%kernel.project_dir%/var/storage/demo/uploads' } }
            local.wysiwyg: { local: { directory: '%kernel.project_dir%/var/storage/demo/wysiwyg' } }
            # and every other storage visitors write to (omnibase/office's local.share...)

# config/packages/base.yaml, under when@demo's base.demo
            reset:
                purge: ['%kernel.project_dir%/var/storage/demo']
                orphans: false     # everything is in the directory above: no search among the uploads

Makefile:

## Configure environment for the demonstration (production's behaviour, the database <name>_demo)
env-demo:
	@APP_ENV=demo APP_DEBUG=0 $(MAKE) env

## Create the demonstration's database (<name>_demo), its schema and its fixtures
database-demo:
	@$(DOCKER_DATABASE) mysql -h localhost -u root -p$(MYSQL_ROOT_PASSWORD) -e "CREATE DATABASE IF NOT EXISTS $(MYSQL_DATABASE)_demo; GRANT ALL ON $(MYSQL_DATABASE)_demo.* TO '$(MYSQL_USER)'@'%'; FLUSH PRIVILEGES;"
	@$(DOCKER_WEB) php bin/console doctrine:migrations:migrate --env=demo --no-debug --no-interaction
	@$(DOCKER_WEB) php bin/console doctrine:fixtures:load --env=demo --no-debug --no-interaction

The keys - what the fixtures need to seal (omnibase/office's SHARE_MASTER_KEY, omnibase/mailbox's MAILBOX_KEY) is given in .env.demo as demonstration keys, known to everyone and used nowhere else, as .env.test does (base64 of demo-key-demo-key-demo-key-00001): what they seal is the fixtures' fictional data, emptied every night. The one real secret of a demonstration, DEMO_SUPERADMIN_PASSWORD, is the server's: .env.demo.local, a real variable, or the demo vault (secrets:generate-keys --env=demo then secrets:set DEMO_SUPERADMIN_PASSWORD --env=demo, see Secrets; its private key stays on the server, as production's - .gitignore: config/secrets/demo*/demo*.decrypt.private.php). That key pair is also what #[Vault] needs if the super-administrator types API keys in the demonstration's back office (Sealed fields).

The templates - one line each:

{# templates/base.html.twig (or the layout): first thing in <body> #}
{{ include('@Base/demo/_banner.html.twig') }}

{# templates/security/login.html.twig: under the form #}
{{ include('@Base/demo/_accounts.html.twig') }}

The accounts - a bundle of the trade declares its roles; the site adds its own in src/Demo/DemoAccounts.php (DemoAccountProviderInterface), and its fixtures take them from Base\Demo\DemoAccountFactory instead of writing them a second time.

src/Kernel.php - only if it lists the environments it allows (getAllowedEnvs(), Symfony 8.1's skeleton): add 'demo'.

Then:

make env-demo && make up       # production's stack, APP_ENV=demo
make database-demo             # once

On a development machine, to look at it without leaving the dev stack: the web container alone in demo, by an override of two lines (services: { web: { environment: { APP_ENV: demo, APP_DEBUG: "0" } } }, docker compose ... -f that-file.yml up -d web), then make database-demo; make up brings dev back. The links public/uploads and public/images follow whichever environment cleared its cache last.

What a new site no longer copies

First start, in this order

make install-dev          # = make env-dev, make build, make up - build BEFORE up
make doctrine-migration   # the site's first migration
make doctrine-migrate
make database-test        # the test database
docker exec <app>-web-1 php vendor/bin/phpunit

make build comes before any up. /srv/app/public is a named volume (<app>-public) that no image seeds: the composer step of make build copies ./public (its index.php) into it when the volume is empty, then composer's assets:install links the bundles' assets (public/bundles/*). A stack started first - make up, a bare docker compose up - creates the volume with the public/assets mountpoint alone: not empty, so never seeded, and every page answers "File not found". The reference site's Makefile repairs that case itself since 2026-10-04 (seed-public, run by make build: a volume that exists without index.php gets ./public); with an older Makefile, by hand:

docker run --rm -v <app>-public:/to -v "$PWD/public":/from:ro alpine cp /from/index.php /to/
docker exec <app>-web-1 php bin/console assets:install public --symlink --relative

Stopping a site

make down (docker compose down, without -v): the containers and the site's two networks go, the volumes (database, public, vendor, storage) stay, and make up brings the site back as it was. Not docker compose stop: it keeps the networks, each holding a subnet of Docker's address pool, and with enough stopped sites the next up fails on "could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network". -v deletes the volumes: the database with them.

Steps

1. Copy the files of the first part - tracked files only, symfony.lock among them, neither .env.local nor .htpasswd; rename (APP_NAME, ports, composer.json, package.json); give the two networks their subnets.
2. make install-dev (composer and yarn in the setup containers, COMPOSER_ALLOW_SUPERUSER=1): see the order above.
3. Generate the key pairs (secrets:generate-keys, dev and test: see Secrets), then make doctrine-migration, make doctrine-migrate and make database-test. These run from a script or an agent as well as from a terminal: the Makefile's DOCKER_WEB, DOCKER_DATABASE, DOCKER_PROXY and DOCKER_ASSETS pass docker exec the TTY_FLAG (-ti when standard input is a terminal, -i otherwise), and so do make shell / make shell-debug given ARGS. The reference site's DOCKER_DATABASE and DOCKER_PROXY used a bare -ti, and make database-test stopped on "the input device is not a TTY" outside a terminal (fixed 2026-10-04): a site copied from an older Makefile changes those two lines the same way.
4. Write the site's SettingsSectionInterface classes for its own settings and keys.
5. docker exec <app>-web-1 php vendor/bin/phpunit: green before the first commit.

The reference site moved onto the shared bricks in migrations/Version20261004090000.php (textOverride → layoutTextOverride, blog_comment → threadComment, the hours tables): the model for the existing sites when they are attached one by one.

Settings

Settings are stored per locale and compiled into a single snapshot at warmup, so reading one at runtime never queries the database. They are what the back office edits (base.settings.title, base.settings.maintenance, api.spam.akismet...), read through Base\Service\SettingBag (Base\Service\SettingBagInterface).

base.parameter_bag.use_setting_bag must be on: off, the snapshot is empty and every setting reads as unset (Configuration reference).

Reading a setting

$title = $settingBag->getScalar('base.settings.title');          // 'My site', or null
$title = $settingBag->getScalar('base.settings.title', 'fr-FR'); // in that locale
$tree  = $settingBag->get('base.settings');                      // the values under the path

get() answers an array: the path's own value under _self, the values of the paths under it by their names (get('base.settings.title') is ['_self' => 'My site']). getScalar() is get($path, $locale)['_self'] ?? null. Both take a list of paths too. A value is read in the locale asked, else the default locale, else the first locale it has.

A missing setting degrades to null rather than throwing - a missing setting is a normal state during a deployment, not an error. A malformed path (_self in the middle of it) still throws.

In a template, app.settings is get('app.settings'), and the setting base.settings.maintenance puts the site under maintenance.

Writing a setting

$settingBag->set('base.settings.title', 'My site', 'en-GB');
$settingBag->set('base.settings.title', null, 'en-GB'); // removes that locale's value

set() creates the setting when it does not exist, refuses a locked one (lock(), unlock()), flushes, evicts the second-level cache and invalidates the snapshot. setLabel() and setHelp() give the back office's label and help text, secure() marks a setting as secret. has(), remove().

Translatable values

A setting's value lives in SettingIntl, one row per locale. The default locale is not special-cased at the storage layer; every locale is a row.

A setting over a parameter

setBag($path, $parameterName) links a setting to a parameter of the configuration: with base.parameter_bag.use_hot_bag on, the setting's value (in the default locale) answers for that parameter before base.yaml's (getBagParameters(), laid over the parameters by HotParameters on each request and command). This is how the back office changes an option of the configuration without a deploy.

Architecture

The bundle is organised around a few long-lived pieces:

• What the core requires — since 4.0 its Foundation alone (Doctrine, Twig, the standalone components); under Symfony the framework comes with omnibridge/symfony, and the bundles the core works with are suggested: What the core requires.
• Entities — Thread and its subtypes carry the shared title/slug/content model that articles, comments and pages all reuse.
• The contracts of the Foundation — what framework-free code asks of the application (URLs, translations, access, locales, files, the clock, events, mail), through Base\Contract\Runtime: The contracts.
• The Doctrine mapping — what omnibase assembles at runtime (the attributes, the translations, the discriminator maps, the filters, the types), wired by Base\Bridge\Doctrine under Symfony and on an entity manager built by hand, on doctrine/orm as published: The Doctrine mapping.
• Settings — a compiled snapshot of configuration, read through SettingBag.
• Admin — the back office is a package of its own, omnibase/admin (formerly base-bundle-admin), with its own manual.
• Account security — what the administrator sets, and a second factor required of some roles: Account security.
• The demo environment — APP_ENV=demo: declared demonstration accounts, one click to sign in, a nightly reset, and what it refuses: The demo environment.
• Forms — the theme, and where a field's texts are translated: Forms.
• Sealed fields — #[Vault], its key pair, and what happens without one: Sealed fields.
• Errors — which status an error is answered under, and the 404 that are meant: Errors and refusals.
• Time — PHP's zone is the visitor's; a moment is stored in UTC (utc_datetime_immutable), see Time and time zones.
• The forms' guard — a trap, the time, the lists, a captcha, the classifier, one option (guard): The forms' guard.
• Politeness — tu or vous, です / ます or 敬語: one setting of the site (base.translator.politeness) and a variant per text (key._polite), see How the site addresses people.

The warm-up: every class of every bundle

On its first boot (and after a cache:clear), BaseBundle::warmUp() maps each Base\* bundle's directories onto their mirrors (Base\X\Entity\Y ↔ Base\Entity\X\Y, Base\Entity\Y ↔ App\Entity\Y...) and, to do so, loads every class it finds there. The result is kept in var/cache/<env>/pools/base/bundle.php.

A bundle may hold classes for a package it only suggests - a digest source implementing omnibase/newsletter's interface, an exporter extending a provider's class. Without that package, such a class cannot be declared (Interface "..." not found, or Class, Trait, Enum). The warm-up passes it by: it is not aliased, and the rest of the directory is. Nothing registers it without its package (the bundle's service configuration loads it only when the package is there), so nothing misses it. Any other error while loading a class

• a parse error, a broken bundle - still stops the boot.

AbstractBaseBundle::classLoads($class) is that check (true, false, or the error rethrown); AbstractBaseBundle::getUnloadableClasses() lists what the warm-up passed by in this process, with the reason - the first place to look when an alias is missing.

Rebuilding an entity's previous state

The attributes that act on a change (#[Uploader] above all) compare an entity with its state before the change: AbstractAttribute::getOldEntity() rebuilds it, without its constructor, from Doctrine's original data through object_hydrate(). Doctrine keeps an enum field there as its backing value ("draft", not Status::Draft); object_hydrate() turns it back into the case (BackedEnum::tryFrom(), or the case of that name for a pure enum) whenever the property is typed with an enum, and leaves the property out when no case matches. property_enum_value(ReflectionProperty, $value) is that conversion, for any other code that fills typed properties by reflection.

What the core requires

Since 5.0 (branch 5.x, plan "omnibase agnostic", step F6) omnisense/omnibase is a library (type: library) that requires the agnostic core's packages alone, the list bare --strict holds it to: PHP 8.4 and its extensions (bcmath, exif, igbinary, imagick); the PSRs (cache, clock, container, event-dispatcher, log, simple-cache); omnisense/omnibridge, omnisense/omnidrive, omnibridge/composer; doctrine/collections; embed, endroid/qr-code, svg-sanitize, hashids, imagine, crawler-detect, league/flysystem; the standalone Symfony components kept (string, uid, intl, translation, mime, mailer, notifier, property-access, options-resolver, yaml, password-hasher, filesystem, finder, serializer) and the contracts (service, translation, event-dispatcher, cache, http-client). docker/bin/bare --install --alone installs exactly that (var/bare-alone), and bare --strict --alone loads the agnostic core on it (BareTest's testTheCoreAloneLoadsTheAgnosticCore).

The bundle itself is omnibridge/symfony's since 5.0: Omnibridge\Symfony\Omnibase\BaseBundle, its Bundle\*, DependencyInjection\*, the Symfony controllers and the service configuration (config/omnibase/); their former names (Base\BaseBundle...) stay aliases until 6.0. The bundle's path is still the core's src/ (@BaseBundle/..., the templates, the translations), and its extension maps the core's entities under the bundle's name, as auto_mapping did.

The classes of the core that stand on a package it now suggests load where that package is installed: the constraints of Base\Validator\ (symfony/validator), Base\Service\Model\WorkflowInterface (symfony/workflow), Base\Twig\AssetPackage (symfony/asset). bare reports them as optional where the package is absent, as it does src/Twig without Twig. The local caches (the obfuscator's map...) take any PSR-6 pool: symfony/cache's PHP array file where it is installed, Base\Cache\Pool\MemoryPool otherwise. doctrine/lexer, which egulias/email-validator reads when symfony/mime checks an address, is accepted by --strict as the mailer stack's.

The symfony/process patch is still declared by the core (applied only where symfony/process is installed): it moves to omnibridge/symfony when 4.x is no longer served, because the 4.x core declares it too and the second declaration would fail on the sites still on 4.x.

4.x (branch 4.x, 4.0.x-dev) is kept for the applications locked on it; the bridges' 1.x serve both majors. Upgrading: UPGRADE-5.0.md. What follows is the 4.0 state.

4.0

Since 4.0 (branch 4.x, plan "omnibase agnostique", step C7) omnisense/omnibase requires its Foundation alone: what tests/Foundation.php loads, and what it stands on. The framework is no longer a requirement of the core: a Symfony application adds it, a Laravel application does not.

omnibridge/doctrine stays required: the core does not load without it. Base\Database\Type\UtcDateTimeType, UtcDateTimeImmutableType and DateTimeTypeUTC extend omnibridge/doctrine's types and Base\Database\Type\Utc reads its zone (the types registered at every boot, BaseExtension::prependDoctrineTypes(), BaseBundle::boot()); Base\Database\Mapping\NamingStrategy extends its NamingStrategy; Base\DependencyInjection\Compiler\Pass\DoctrineConfigurationPass and Base\Bridge\Doctrine\Mapping wrap every entity manager's driver in its DeclarationDriver. Since the agnostic core's step F3 the core's Doctrine classes themselves are omnibridge/doctrine's (Omnibridge\Doctrine\Omnibase\, their former names aliased by the core: the Doctrine mapping); leaving the package to the application is the composer.json switch, F6. omnibridge/twig left the core's requirements with Twig at step F4: config/services/twig.php registers its HelperExtension with the Twig layer, and Base\Twig\Extension\FunctionTwigExtension calls it (join_if_exists, less_than), both only where Twig is installed.

symfony/console is still installed with the core alone: doctrine/orm 3 requires it. Nothing of the Foundation loads it, which is what bare checks: "free of Symfony" reads nothing of the framework loaded, not absent from vendor.

Doctrine: the latest major, one line. The core follows each Doctrine package's current major, open upwards - doctrine/orm ^3.4, doctrine/dbal ^4.2 (omnibridge/doctrine's floors), doctrine/collections ^3.1 (which requires PHP 8.4, the core's floor), doctrine/event-manager ^2.0, doctrine/persistence ^4.0, doctrine/common ^3.0 - with no older branch kept alive, no upper bound and no pinned version; Doctrine is used as published (no patch, no fork). doctrine/dbal included (4.0, step C6b): no Composer plugin rewrites its schema managers; what omnibase needs of them goes through DBAL's own SchemaManagerFactory (Base\Bridge\Doctrine\SchemaManagerFactory, a SET column read with its values, the (DC2Type:...) comments of before left out). A new major is taken up when it comes, not maintained beside the old one.

A Symfony application

composer require omnisense/omnibase:4.0.*-dev omnibridge/symfony:1.x-dev

then the bundles its config/bundles.php registers, for an application made on omnibase's usual set:

composer require scheb/2fa league/flysystem-bundle hwi/oauth-bundle web-auth/webauthn-symfony-bundle \
    api-platform/symfony api-platform/doctrine-orm symfony/webpack-encore-bundle symfony/ux-twig-component \
    glitchr/ux-google glitchr/well-known nelmio/cors-bundle nelmio/security-bundle

An application coming from 3.x already had every one of them, through the core: requiring them itself keeps them (Composer would otherwise remove what nothing requires any more). No Flex recipe runs again for a package already locked: nothing changes in config/.

The core's Symfony host code is omnibridge/symfony's, under Omnibridge\Symfony\Omnibase\ with the same path (step F5c): the form layer (Field\Type\*, Form\*), the console (Console\*), the kernel subscribers (Subscriber\*), the router (Routing\{AdvancedRouter, AdvancedRouterInterface, Generator, Matcher, Loader}), the cache warmers and clearer (Cache\{Warmer, Clearer}\*, Cache\Abstract\AbstractLocalCacheWarmer), the data collectors (Inspector\*), Response\{PdfResponse, XmlResponse}, Symfony Security's authenticators, user providers, user checker, sign-in guard, session storage and voters (Security\*, but the framework-free ones), the contracts' Symfony adapters (Bridge\Symfony\X is Omnibridge\Symfony\Omnibase\X). The pages of this manual still name them by their former names (Base\Subscriber\...), which the core aliases until 6.0 (src/Resources/former-names.symfony.php).

Composer: omnibridge/composer

The core requires one Composer plugin, omnibridge/composer (in place of glitchr/base-plugin until 4.0), and declares what it asks of it in its own composer.json, extra.omnibridge:

• the stubs of App\Entity, App\Enum, App\Form, App\Notifier and App\Repository - one per plain class Base\<Name>\X the application does not define in src/<Name>/, the alias AbstractBaseBundle declares at run time - by the providers Base\Bridge\Composer\Stub\*, written after every dump-autoload into vendor/composer/omnibridge/stubs/, which no autoloader reads (for an IDE; never a definition at run time; StubsTest). The providers are loaded by the engine alone, outside the Foundation;
• one patch, process-timeout-from-env on symfony/process: a Process built without a timeout waits SYMFONY_PROCESS_TIMEOUT seconds, 60 when unset.

An application allows the plugin:

"config": { "allow-plugins": { "omnibridge/composer": true } }

and checks vendor/ in its CI with composer omnibridge:patches --check (and composer omnibridge:stubs --check). composer omnibridge:patches --diff shows the patch.

Nothing else is changed in an application: its bin/console keeps its own line, use Base\Console\Application; in place of FrameworkBundle's (glitchr/base-plugin used to rewrite it at each install; a site made from the skeleton writes it once). The class is omnibridge/symfony's Omnibridge\Symfony\Omnibase\Console\Application since step F5c; its former name stays aliased until 6.0.

None required de facto

Up to step C7b two of them could not be left out; each has its fallback now, and the user class and the storages load without either:

• scheb/2fa - Base\Entity\User implements Base\Contract\SecurityUser and Base\Contract\TwoFactorUser. Where symfony/security-core and scheb/2fa are installed, they are aliases of Base\Bridge\Symfony\SecurityUser (Security's UserInterface and PasswordAuthenticatedUserInterface) and Base\Bridge\Symfony\TwoFactorUser (scheb's TOTP, e-mail, backup-code and trusted-device interfaces): under Symfony the user implements exactly what it did. Elsewhere they are empty interfaces, and the user loads without them. Installed means declared, and nothing else decides (Base\Contract\Framework::declares(), step C7c): no environment variable, no switch - a Laravel application reading a Symfony application's vendor/ gets the user with Security's interfaces, which ask nothing of it but the methods the user has. Without the bundle registered (the package installed) the interfaces are still declared: only the two-factor sign-in itself is the bundle's. Where the framework is not installed is measured on such a vendor: bare loads the Foundation with the core installed alone (composer install --no-dev, see the harness). The users' repository follows the same rule (step R2): Base\Repository\UserRepository implements Base\Contract\SecurityUserLoader and SecurityUserProvider, aliases of Base\Bridge\Symfony\SecurityUserLoader (doctrine-bridge's UserLoaderInterface) and SecurityUserProvider (Security's UserProviderInterface and PasswordUpgraderInterface) where symfony/doctrine-bridge and symfony/security-core are installed, empty interfaces elsewhere. So do the passkeys' repositories (plan "omniauth", AU1): PasskeyRepository and WebauthnUserEntityRepository implement Base\Contract\PasskeyRecords and PasskeyUsers, WebauthnBundle's interfaces where it is installed.
• league/flysystem-bundle - Base\Service\Flysystem (the flysystem service, which the file, image, upload, backup and cache-clear services read) is the core's own class, built from a PSR-11 container of storages by name: the services tagged flysystem.storage, which the bundle tags from the application's config/packages/flysystem.yaml. Without the bundle, Base\Discovery's storages (compiled by omnibridge/symfony's DiscoveryPass) gives omnibase's local storages: local.cache (var/cache/<env>/images), local.uploads and local.wysiwyg (var/storage/...), each with its .public under public/.

The others have a fallback:

A Laravel application

Laravel does not install Symfony's framework: it requires the core and, when it exists, omnibridge/laravel, which fills the contracts (Base\Contract\Runtime, see The contracts) with Laravel's services. Doctrine stays the storage (laravel-doctrine/orm), Twig the view (omnibridge/twig). The pilot, lesringostars-laravel, does so already from a Symfony application's vendor/.

The core's own suite

require-dev holds omnibridge/symfony and the bundles the core's code names (scheb/2fa, league/flysystem-bundle, hwi/oauth-bundle, web-auth/webauthn-symfony-bundle, api-platform/symfony, symfony/webpack-encore-bundle, glitchr/ux-google), so that Dockerfile.test (composer install of the core alone) resolves what its kernel tests use. The harness's application (docker/Dockerfile) requires omnibridge/symfony and every bundle its config/bundles.php registers, as a site does.

Entities and repositories

Repositories

Base\Database\Repository\ServiceEntityRepository is doctrine/orm's EntityRepository built from the ManagerRegistry (doctrine/persistence), as DoctrineBundle's service repository is - __construct(ManagerRegistry $registry, ?string $entityName = null), the entity guessed from the repository's name - plus the finder language (findByStateAndLocale(), cacheOneBySlug(), countByDomain()...). It does not extend DoctrineBundle's class: a repository loads without the framework (it is in tests/Foundation.php). Under Symfony every service extending it is tagged doctrine.repository_service (BaseExtension, registerForAutoconfiguration()), so an application's App\Repository\* is still handed out by getRepository() and autowired.

Counting gives an integer. count([]), count(['state' => 'draft']), countByState('draft') and distinctCountForLocaleByDomain('messages') each run one SELECT COUNT(...) and return an int, as Doctrine's count() promises. Only a grouped count (a $groupBy or a $selectAs argument) returns rows, each with its count (ThreadRepository::countForChildrenIn()).

What is registered as a repository. A bundle maps its src/Repository (setMapping() in its Bundle class): every class there is aliased under the application's namespace, and the ones that are repository services are registered (doctrine.repository_service, built with doctrine). A repository service is a class whose name ends with Repository, that can be instantiated and extends omnibase's ServiceEntityRepository or implements DoctrineBundle's ServiceEntityRepositoryInterface (AbstractBaseBundle::isRepositoryService()). An abstract base repository, an interface or a trait in that directory is aliased, never registered: a bundle may keep AbstractCatalogueRepository beside the repositories that extend it.

Repositories behind interfaces. The code of a site and of the core asks its repositories through interfaces named by what they answer, in the namespace of their entity (audit "lesringostars face au master plan", step R15): Base\Database\Repository\Entities - what every repository answers: find(), findAll(), findBy(), findOneBy(), count(), persist(), remove(), flush() -, and one per entity: Base\Repository\Threads, Users, Thread\Tags, User\Notifications, Layout\Settings; a site adds its own beside its repositories (App\Repository\Article\Articles extends Threads). Nothing of the ORM in what they take or give back: arrays of criteria and of order (field => ASC|DESC), the entities, lists of them, integers. The Doctrine repository implements its interface, each method by the finder call it replaces (Threads::oneBySlugAndState() is cacheOneBySlugWithRouteAndState()): same query, same result cache. Under Symfony each interface is an alias of the repository service (config/services/database.php; a site's own by #[AsAlias] on its repository); under Laravel the application binds each to the repository omnibridge/laravel resolves by its class. Another persistence implements the same interfaces over the same tables (the structure: schema.md).

The finder language (cacheOneBySlug()...) stays the repositories' own: an application calls the interface's methods, never the finder through it.

The interfaces are listed in Base\Repository\Aliases::INTERFACES (29 with Repositories, since step E2' of the plan "omnibase agnostic": User\Complaints, and Thread\Comments answering what omnibase/blog asks - findVisible(), countVisible(), countPending(), findPending()). A site or a bundle types on them, not on a repository's class: since E2' the core's bundles and lesringostars do, but for omnibase/admin's dashboard tile of complaints, which keeps ComplaintRepository while the bundle serves omnibase 4.x as well (4.x has no Complaints).

The finder language, read without Doctrine

A finder's name - findOneByEmailAndUsername(), cacheOneByStateAndSlugStartingWith(), countByStateAndPublishedAtYoungerThan(), cachePreviousOneByClassOfAndState(), lengthOfTagsByState() - is read by Base\Database\Repository\Finder\Parser, which knows nothing of an ORM (plan "omnibase agnostic", 2026-11-01, step F1). Its parse($method, $arguments) gives a Finder\Query, the language's neutral form:

• method and arguments: the internal request the name leads to (__findBy, __findOneBy, __findLastBy, __findAtMostBy, __findPreviousBy, __findNextBy, __findRandomlyBy, __findAll, __countBy, __distinctCountBy, __lengthOfBy...) and its arguments - the criteria first (those the name declares, "field:index" => value, merged into the array given, then the specials' numbers and keys as "special:..."), then the order, the limit, the offset, the grouping, the selected expressions;
• criteria and options: the criteria the name declares and their words (EqualTo, NotEqualTo, GreaterThan, LowerThan, YoungerThan, OlderThan, Within, IsOver, StartingWith, Null, Empty, True, Insensitive, Partial, ClosestTo, InstanceOf, ClassOf, MemberOf...); criterions() gives them as Finder\Criterion objects (field, index, value, options), extras() the specials' numbers and keys;
• separator (And or Or), column (countFor<Column>By, lengthOf<Column>By, sumOf<Column>By...), cacheable, eagerly, request (find, count, lengthOf, sumOf, minOf, maxOf) and special (One, All, Randomly, AtMost, Last, LastOne, Previous, PreviousOne, Next, NextOne).

What the parser asks of the entity is a Finder\Subject: its class, its fields (a field whose name holds a word of the language is refused), whether it has a field or association, a Query-by-Example's criteria. A host's request given to a ...WithRoute finder is turned into route parameters by the resolver the parser is given (Request and KernelEvent under Symfony).

A persistence compiles the Query into its own queries. On Doctrine it is ServiceEntityParser: the Subject of its entity, read() (the parse alone) and execute() (the DQL, the joins, the date bounds, the DQL functions, the caches, the eager loading); parse() does both, as ServiceEntityRepository::__call() asks. The compiler is omnibridge/doctrine's since step F3 (Omnibridge\Doctrine\Omnibase\Database\Repository\ServiceEntityParser, its former name aliased by the core, see the Doctrine mapping), and omnibridge/eloquent compiles the same Query into Illuminate's query builder at F7: the language is one, whatever the backend.

The parse is the one of before F1, word for word: tests/Database/Repository/FinderParityTest compares, for 57 finder calls (the core's own shapes and one of each word), the parse and the query (DQL, parameters, first and maximum results, or what a running finder gave or threw) with finder-parity.json, recorded on the code of before (FINDER_PARITY_RECORD=1). lesringostars' FinderParityTest compares the results on the site's data. tests/Database/Repository/Finder/ParserTest reads each word on an entity known by its fields alone, and BareTest::testTheFinderLanguageIsReadWithoutDoctrine parses under bare --strict.

Each word does what its name says (fixed before step F2, tests/Database/Repository/FinderDefectsTest): LowerEqualTo, GreaterEqualTo, OlderEqualTo and YoungerEqualTo compare with <= and >=; a negative word is read before the positive one it ends with (NotStartingWith, NotEndingWith, NotInstanceOf, NotClassOf, NotMemberOf), and NotClassOf is ClassOf's opposite (anything but that class exactly); lengthOf<Collection>By gives each entity's number of members (SIZE()), lengthOf<Field>By its length (LENGTH()); a DateTimeImmutable compared with a field of a mutable type is bound as the same moment; Null and NotNull bind no parameter.

Groups, aggregates, and the queries one persistence runs (step E2)

A repository's method is written in the finder language wherever it can be, so that every persistence compiles it (plan "omnibase agnostic", step E2; the inventory of the repositories' hand-written queries, each sorted, is in the plan). Two features were added for it:

• Groups. A name joins its criteria with one separator, And or Or. The parentheses a name cannot say are an entry of the criteria array, Finder\Group::by(<name>, ...values), read by the same parser as the criteria part of findBy<name>, its own separator inside:

  $notifications->count(['user' => $user, 'isRead' => false,
      Group::by('TitleNotEmptyOrSubjectNotEmptyOrContentNotEmpty')]);
  $translations->findByTranslatableNotNull([
      Group::by('InsensitivePartialTitleOrInsensitivePartialExcerpt', '%word%', '%word%'),
      'translatable.state' => ['STATE_PUBLISH'],
  ]);
  

  Every word of a criterion is allowed in a group; not what is no condition (ClosestTo, FarestTo, Model), WithRoute, nor a criteria array or any argument after the named values. Query::criterions() gives a group as one criterion whose value is the Group read (Group::criterions(), Group::separator()); omnibridge/doctrine compiles it into a parenthesised expression whose parameters and options are its own.

• Aggregates. sumOf<Column>By..., minOf<Column>By... and maxOf<Column>By... give SUM(), MIN() or MAX() of a field over the rows the criteria select (sumOfViewsByDateGreaterEqualTo($since, ['path' => '/']), minOfDate()): the database's value as it gives it, null without a row (Query::$request sumOf, minOf, maxOf; internal __sumOfBy...).

omnibridge/doctrine's compiler also binds an equality on one value with the field's type when that type converts it (ConvertedInCriteria: the passkeys' base64 and AAGUID columns), as Doctrine's own findBy() does: findOneBy(['publicKeyCredentialId' => $bytes]) finds the row.

What the language does not say stays the backends', declared so: #[Base\Database\Repository\BackendOnly(['doctrine', 'eloquent'], reason)] on the core's interface method - the analytics' native SQL (upserts, INSERT IGNORE, DATE() groupings, correlated subqueries) and Redirections::hit()'s bulk UPDATE. No finder compiles them: each persistence writes them in its own terms, omnibridge/doctrine through DBAL (its implementation declares BackendOnly('doctrine', ...) too), omnibridge/eloquent the same statements through Illuminate's connection (step F7f; Redirections::hit() as one UPDATE ... SET hits = hits + 1). BackendOnly::declared() lists them (14, kept in tests/Database/Repository/BackendOnlyTest), BackendOnly::runs() tells whether a persistence runs one, and a persistence not named answers BackendOnly::refuse() - an UnsupportedQueryException that names the method, the backends it is written for and why - until it writes the query in its own terms, never a silent wrong answer. None of the 14 is tied to Doctrine itself: plain SQL a connection runs, and an UPDATE whose hits + 1 the database computes (no DQL-only construct, no Doctrine locking).

Each rewritten method gives the rows of its former query, in the same order: FinderParityTest::testTheRewrittenQueriesGiveTheRowsOfBefore runs both (the former queries kept word for word in tests/Database/Repository/HandWrittenQueries.php) on rows it writes in the harness, and lesringostars' FinderParityTest runs them on the site's data. Under omnisense/omnibase 4.x, whose finder has neither groups nor aggregates, omnibridge/doctrine's methods written on them keep their former query (ServiceEntityRepository::finderReadsGroups()).

An association compared by its key, without a join (step E2b)

A criterion on an association is compiled through a join of it (LEFT JOIN e.thread e_thread, e_thread = :thread), and a persistence that scopes the joined entity puts its scope there: Doctrine's trash filter on Thread goes into the join's ON, so a comment whose thread is in the trash reads as a comment without a thread. Finder\Key::of($value), a criterion's value, compares the row's own foreign key instead, with no join:

$comments->findBy([
    'state' => CommentState::APPROVED,
    'thread' => Key::of($thread),   // e.thread = :key_thread; null: e.thread IS NULL
    'parent' => Key::of(null),
], ['createdAt' => 'DESC'], 200);
$comments->findByThreadNotEqualTo(Key::of([3, 4]));   // e.thread NOT IN (:key_thread_0)

It takes an entity, its identifier, a list of them (IN; an empty list leaves the criterion out, as any list of the language) or null, with EqualTo (the default) or NotEqualTo only, on an association of the entity itself; the Parser refuses a path (thread.parent needs the join) and any other word, the compiler a field that is no single-valued association. In the criteria array, in a name's arguments or in a group alike; Criterion::byKey() tells a compiler. omnibridge/doctrine compiles it to e.<association> (=, <>, IN, NOT IN, IS NULL, IS NOT NULL), omnibridge/eloquent to the foreign-key column. Not a word of the name: "Key" in a name would make every field holding the word (Passkey's publicKeyCredentialId) one the language refuses.

Comments::findVisible() and countVisible() are written on it: the comments of a thread in the trash stay its own, as with their former query (FinderParityTest writes them, beside a live thread's and the visitors' book's). Under omnisense/omnibase 4.x, which has no Key, the methods keep their former query (ServiceEntityRepository::finderReadsKeys()).

Translations

An entity using TranslatableTrait reads and writes its translated fields through translate():

$post->translate('de')->setTitle('Apfel');   // written in German, persisted at the next flush
$post->translate('ja')->getTitle();          // null when nothing is written in Japanese; creates nothing
$post->translate()->getTitle();              // what the current page shows

• translate($locale) is that locale's translation. When the entity has none, it is a new, empty one the entity holds aside (out of getTranslations()) until a value is written in it: a read creates no translation. A written one joins the collection at the next getTranslations() or flush (commitPendingTranslations(), called by IntlSubscriber before each flush).
• translate() without a locale is the translation to show on the current page: the page's language when something is written in it, else the same language in another region (pt-BR on a pt-PT page), else the default locale's, else the first available locale's, else any written one.
• The magic getters ($post->getTitle(), post.title in Twig) read translate(), then the default locale when the value is null.

An isEmpty() translation is never persisted (IntlSubscriber::onFlush).

Countries

{{ code|country_name }} names a country from its ISO 3166-1 code, in the page's language; {{ code|country_name('de') }} in the one given (Localizer::getCountryName(), on symfony/intl). JP is "Japon" on a French page; alpha-3 (JPN) is read too; an unknown code is printed as it is. The country of a locale (fr-BE → "Belgium") is |locale_country_name.

A taxon's slug is unique per type

Base\Entity\Thread\Taxon is the root of a JOINED hierarchy: a FAQ's Section, a classroom's Subject, a menu's MenuSection, a site's own Category all share the table threadTaxon and its slug column. The slug is unique among the taxa of one type - the unique index is on (class, slug), class being the discriminator - so a menu's section and a blog's category may both be desserts. (It was unique on the column alone: the second one became desserts-2, whatever its type.)

#[Slugify(reference: 'translations.label', perType: true)] is what numbers a slug only against the entities of the same class; any hierarchy that shares a slug column may use it.

The migration an application generates after updating omnibase (bin/console doctrine:migrations:diff), on threadTaxon: the unique index on slug is dropped, a unique index thread_taxon_type_slug on (class, slug) and a plain index thread_taxon_slug on slug are created. No row changes; the new constraint is weaker than the old one, so it always applies. Until that migration has run, omnibase sees the old index and keeps numbering slugs for all types together: nothing fails in between.

A taxon is found by its slug through the repository of its type (SectionRepository::findOneBySlug()): TaxonRepository itself may now find several types under one slug.

The second-level cache after the fixtures

A site that turns on Doctrine's second-level cache (doctrine.orm.second_level_cache) caches its entities by id. A command that rewrites the database behind the ORM's back leaves that cache wrong: doctrine:fixtures:load purges the tables with DELETE / TRUNCATE, the new rows are numbered from 1 again, and the cache answered yesterday's entity for today's id until it expired.

Base\Subscriber\SecondLevelCacheConsoleSubscriber empties every region (entities, collections, queries) of every entity manager when one of these commands ends: doctrine:fixtures:load, doctrine:schema:{drop,create,update}, doctrine:database:{drop,import}, doctrine:migrations:{migrate,execute}, dbal:run-sql. Nothing to configure; cache:pool:clear by hand after loading fixtures is no longer needed. A command of your own that writes SQL directly calls it: $subscriber->evict().

The contracts of the Foundation

What omnibase's framework-free code (an entity's getter, an attribute, a value object) asks of the application it runs in, by an interface, never by a Symfony service (plan "omnibase agnostique", step C4). Each is reached through one registry, Base\Contract\Runtime, which the framework fills at boot.

The host's contracts are omnisense/omnibridge's (plan "omnibase agnostique", A2). What any host answers - addresses, translations, languages, access, sessions, tokens, stored files, routes, environment - lives in the omnibridge family's core, omnisense/omnibridge, as Omnibridge\Contract\*, with the registry itself (Omnibridge\Runtime, its MissingContractException and SystemClock). What describes omnibase's own models stays here as Base\Contract\*: Nouns, Media, Pictures, Texts, the screens' ContextProvider, the user's SecurityUser/TwoFactorUser, its repository's SecurityUserLoader/SecurityUserProvider and the passkeys' repositories' PasskeyRecords/PasskeyUsers. Base\Contract\Runtime is omnibridge's registry (the same state) with omnibase's accessors beside it: parameters(), nouns(), media(), pictures(), texts(), mailer(). The former names (Base\Contract\Urls... and omnibridge/twig's Omnibridge\Twig\Contract\Urls and Translations), aliases of the moved interfaces since A2, were removed at omnibase 4's final pass: name Omnibridge\Contract\*.

Locales is plural, as omnibridge's Urls and Translations are, and so that importing it never shadows PHP's \Locale.

A token per intent, under Symfony only. Symfony's CSRF tokens are one per intent (2fa_disable, passkey_delete_12...): a screen's action carries the token of its own intent, and the controller checks that one. Laravel has a single session token for every intent: an action pointing at a Symfony route, rendered by Laravel, would carry a token Symfony refuses. Nothing does that today - the Laravel twin shows no account page; a framework rendering another's actions binds Tokens to the other's tokens, or posts to its own routes.

No contract for the mail. symfony/mailer is a standalone component, allowed in the Foundation (decision D1), and Laravel's own mail is built on it: its MailerInterface is the contract, and another framework hands a Mailer over its own transport.

BaseTrait and BaseService: the application's shortcuts (step C9)

The rule: BaseTrait to go fast in an application; the contracts in the core and the bundles. Base\Traits\BaseTrait (static accessors usable from an entity, an attribute, a subscriber) and Base\Service\BaseService (its facade) are the tool for writing an application quickly, and they stay - neither is deprecated, nor removed in 5.0. The core and its bundles add no new use of either: a class of theirs asks Base\Contract\Runtime (or is given the service it needs), so that it runs where there is no Symfony.

What changed in C9:

• BaseService is a lazy service. The container hands out a ghost of the class (PHP 8.4's lazy objects, not a proxy subclass), built with its 23 services the first time one of its methods reads a property. Injected in a class that never calls it, it builds nothing.
• Nothing on a page's path injects it any more. SiteVariable and AdminVariable (app.site, app.admin) and EmailVariable read the settings from the SettingBag and the route index from the router; FormTypeBootstrapExtension the parameters; ErrorController the Environment contract (Base\Service\Model\DevelopmentEnvironment, isDevelopment()'s rule); MainController and UserSettingsController never called it. The core's getService()->isDebug(), getSalt(), isGranted(), isEntity() calls are Runtime::environment()->isDebug(), ->secret(), Runtime::access()->isGranted(), and BaseTrait's static isEntity() (the class metadata manipulator).
• What a contract answers, they ask the contract when the registry has it, so they answer outside Symfony too, and the methods below read no property of BaseService - called on the ghost, they build nothing:

The other accessors stay on the lazy base.runtime locator, one service built on its first call; since F2f (below) they name contracts only, and the framework's services they handed out are deprecated.

The bundles' uses (for step C8, which moves them to the contracts; nothing changed in the bundles): no bundle injects BaseService or calls getService(). Fourteen entities use BaseTrait - marketplace's Order (getTrading() x8, getTranslator() x3, getRouter(), getParameterBag()), Product (getParameterBag(), getRouter(), getTranslator(), getTwig()), Order\OrderItem (getTrading() x3), Order\Method\PaymentMethod (getParameterBag()), ShippingMethod (getParameterBag() x2), Sales\Attribute\Rule\TotalPriceAdapter (getTrading()); forum's Category (getRouter()); and, calling none of its accessors, marketplace's Sales\Discount, Fee, Sales\Attribute\Action\FixedAmountAdapter, forum's Post, mailbox's Conversation, classroom's Entitlement and Resource.

BaseTrait on contracts only (step F2f)

Base\Traits\BaseTrait names contracts only: each type its accessors take or answer is an interface of omnisense/omnibridge or Base\Contract\, or a class of the agnostic core (tests/Agnostic.php) - never a class of Symfony, Doctrine or Twig (tests/Traits/BaseTraitContractsTest). Each service comes in two forms:

The services: AttributeReader, SettingBag, EntityHydratorInterface, MediaService, Obfuscator, IconProvider, LocalizerInterface, BaseNotifierInterface, TranslatorInterface, TradingInterface, ParameterBagInterface (getParameterBag($key) still answers null for a key the parameters do not have: only a host without parameters throws). isEntity() answers a bool, and throws without the class metadata manipulator (no persistence) instead of answering null. getEnvironment(), getProjectDir() and the directories are unchanged.

The framework's accessors are deprecated - getRouter(), getTwig(), getDoctrine(), getObjectManager(), getEntityManager(), getRepository(), getClassMetadataManipulator(), getTokenStorage(), getRequestStack(), getFirewallMap(), getSlugger(), getService(). They moved to Base\Traits\FrameworkAccessorsTrait, which BaseTrait still uses: same types, same null where the host has no such service, and an E_USER_DEPRECATED on each call naming what to call instead (Link::to() for getRouter()->generate(), the unit of work and the repositories for Doctrine's, Runtime::access() / ::sessions() / ::routes() for the security and request ones, Omnibridge\Contract\Views for Twig). They are removed with the former names at 6.0, after the sites have moved (step S). The core's host code - BaseService, the validators, EditorController, Notification's mails until they render through Views (F5a) - asks the same services of Base\Bridge\Symfony\FrameworkLocator, without the deprecation; it moves with the host code (Doctrine's part at F3, Symfony's at F5c). The bundles, which still accept the core 3.x, call no FrameworkLocator: their entities link through Link::to() (in 3.x too), and marketplace's Product and Review::__autocomplete() keep the deprecated getTwig() until Views has a Symfony adapter (F5a).

The deprecation path, for an application (step S):

• getX() of a contract that it tests for null (?->, if (!...), ?? ): findX();
• getX() it calls straight on: nothing to change, its type is no longer nullable;
• a framework accessor: what its deprecation names (or FrameworkLocator in host code).

What was measured when F2f was made (core, the omnibase/* bundles, omnibridge/*, lesringostars and lesringostars-laravel; 116 calls in 39 files, plus one static call on an entity class): 63 calls on the contracts' accessors, of which 4 do without the service (Uploader's getMediaService()?->, Notification's notifier check, AbstractExtension's isEntity(), lesringostars' Notification::getTranslator() with ?->) and 3 test a missing parameter key (marketplace); 53 calls on the framework's accessors - 31 getRouter() (20 of them ->generate() in an entity's __toLink(), now Link::to(); the other 11 in BaseService), 6 getTwig(), 8 getRequestStack(), 3 getDoctrine(), 3 getEntityManager(), 2 getTokenStorage(). No omnibridge package and nothing in lesringostars-laravel calls them.

The parameters and the settings over them (step C9)

Base\Service\DottedParameterBag (Foundation) reads parameters given by their full names (base.user.active_delay => 300) by a dotted path - a path naming the values under it (base.user) gives them all. ArrayParameterBag (an array) and ParameterBag (the Symfony container's parameters, and DependencyInjection's two interfaces) read through it. has() is whether get() finds a value: a parameter set to false, 0 or "" is there, one set to null is not (it was the value's truth).

Base\Service\HotParameters (Foundation) lays the settings stored in the database - a back office's setting linked to a parameter - over any ParameterBagInterface. get() reads, in this order, by the presence of a value:

1. the $bag given to the call,
2. the settings (add(); when the overlay is on and $useHotBag is true),
3. the configuration.

A setting stored as false wins over the configuration's true; a setting whose value is null (none was typed) is no value, the configuration's is read. The overlay is on when base.parameter_bag.use_hot_bag is true; off, the configuration is read (it read nothing at all before: every parameter was null unless a $bag was given). has() reads the same sources in the same order.

Under Symfony parameter_bag is HotParameterBag, that overlay over ParameterBag as DependencyInjection's ParameterBagInterface and ContainerBagInterface; it refuses clear() and remove() as the frozen bag does, and HotParameterBagSubscriber gives it the settings on the first request or command. parameter_bag, the autowiring of Base\Service\ParameterBagInterface (which gave the plain ParameterBag, without the settings: an autowired EditorController, AttributeReader read the configuration alone), DependencyInjection's interfaces, Runtime::parameters() and BaseTrait::getParameterBag() are one object (ParameterBagServicesTest). Elsewhere: new HotParameters(new ArrayParameterBag([...]), true) and add() the settings.

Base\Service\SettingBag (the settings themselves) keeps its snapshot in a PSR-6 pool (Psr\Cache\CacheItemPoolInterface, no longer Symfony's CacheInterface); its cache warmer is Base\Bridge\Symfony\SettingBagWarmer. It is in the Foundation: Doctrine and psr/cache.

The registry

use Base\Contract\Runtime;

Runtime::urls()->path('blog_article', ['slug' => $slug]);
Runtime::access()->isGranted('ROLE_ADMIN');
Runtime::translations()->trans('@entities.article._singular', [], null, Runtime::locales()->getLocale());

• Filled at boot. BaseBundle::boot() hands it the base.contracts locator (Base\Discovery's contracts, compiled by omnibridge/symfony's DiscoveryPass): each contract by its interface's name, bound to the service the container gives that name - an application rebinds one by aliasing the interface. Only the contracts whose service exists are listed, and a locator holds closures: nothing is built before it is asked. Another framework calls Runtime::setContainer() with a PSR-11 container whose ids are the interfaces' names (Laravel's application is one), or Runtime::set() one contract at a time (it wins over the container's).
• Loud when empty. A contract asked and not filled throws Base\Exception\MissingContractException, which names it - where a getter through BaseTrait that found no service returned null in silence. Runtime::find() answers null instead, for a caller that can do without.
• One kernel at a time. A different container forgets what the previous one gave (as BaseCommonTrait::setRuntime() does); Runtime::reset() forgets everything (a test's tear-down).

The contracts, the registry, SystemClock and the adapters load without the framework (tests/Foundation.php); tests/BareTest.php runs tests/Contract/runtime-without-framework.php with the autoloader alone: plain PHP implementations bound as another framework binds them, and a user of the contracts that answers through them. tests/Bridge/Symfony/ContractAdaptersTest compares every adapter's answers with the services and the Twig functions they stand for.

A link by a router's reference type: Base\Contract\Link

The entities' __toLink(array $routeParameters = [], int $referenceType = ...) take Symfony's reference types. Link::to($name, $parameters, $referenceType) makes the address through Runtime::urls(): Link::ABSOLUTE_PATH (1) is path(), Link::ABSOLUTE_URL (0) is url() - the values of UrlGeneratorInterface's constants, named here so that a link is made without the routing component (LinkableInterface's default is Link::ABSOLUTE_PATH). A relative or a network path has no equivalent in the contract: it is asked of the implementation's own generate($name, $parameters, $referenceType) when it has one (RouterUrls, the router as before) and refused otherwise. It is a helper, not a contract.

Since step E1 Link::to() is the static door of Base\Service\Links, a service on Urls (in Base\Services::definitions()): the registry's where the host lists it, else one made on Runtime::urls(). The widgets' __toLink() (Page, Link, Attachment) default to Link::ABSOLUTE_PATH and import nothing of the routing component.

The entities reach no service (step E1)

No entity of src/Entity imports Symfony's routing component, property-access or a Symfony bridge, nor calls an accessor of BaseTrait (self::/static:: get*(), $this->getNotifier()...): docker/bin/bare --strict reads the sources and refuses it (its report's entities, asserted empty by BareTest). What an entity needs of a service it asks the registry: Notification its notifier, translator and folder through Runtime::notifier(), ::translator(), ::projectDir(); User reads its identifier field itself, as property-access read it; Redirection and TextOverride declare Base\Validator\Constraints\Unique (UniqueEntity on the unit of work's Repositories). The entities keep use BaseTrait for the applications that call its accessors through them.

The entities' getters on the contracts (step C3e)

What an entity of the core asked of BaseTrait's services and now asks of the registry, with the same answers under Symfony (tests/Contract/EntityGettersTest compares each with the service it used) and answers where there is no framework (tests/Contract/entities-without-framework.php, run by BareTest):

Base\Service\Model\LocaleNormalizer is the Localizer's rule for omnibase's xx-XX form, taken out of it: Localizer::normalizeLocale(), __toLocaleLang() and getLocales() now ask it with the Localizer's own statics, so the strings are the same by construction; the entities ask it with the Locales contract's (here()). The test keeps a copy of the rule as it was and compares both paths with it.

The screens (step C5)

A controller hands a template and a view model (Base\Screen\View: template, Base\Screen\Screen, the React component's name, the status) to Base\Bridge\Symfony\ScreenResponder - Symfony's adapter of the framework-free Base\Screen\Negotiation (step R10; omnibridge/laravel's Screen\Responder is Laravel's), which also answers what an action written once for every host hands back: a Template (its data in JSON too when it allows it), Json (its templates rendered), a Shell (omnibridge/react's protocol), a File, or null for no such page -, which renders it with the request's frame (Base\Screen\ContextProvider, under Symfony SymfonyScreenContext: locale, site, links, viewer, theme, a site's own fields; the flashes) - Twig with frame and screen, or omnibridge/react's page in JSON (X-Omnibridge; without omnibridge/react, a request asking application/json alone gets the props). A JSON answer carrying a viewer is private and varies on Cookie. The view models (Base\Screen\*: Frame, Site, Viewer, Author, Tag, Link, StoryText, Card, Story, Comment, Reply, Discussion) keep lesringostars' prop names (App\Screen\*, the pilot's); Base\Screen\Builder\Stories makes them from a Thread and its comments with the Texts and Pictures contracts and the clock (recent, so that no template compares a moment). All of them are in the Foundation (tests/Screen/screens-without-framework.php).

The account's pages are screens too (C5, its second part): a member's profile, the settings, the notifications (Base\Screen\Account\{ProfilePage, SettingsPage, NotificationsPage} and their parts), built by Base\Screen\Builder\Accounts from the entities and the security policy, with the Urls and Tokens contracts and the clock (a notification's group, in Twig's time zone), and handed by the controllers with Base\Bridge\Symfony\AccountScreens (what only Symfony knows: the viewer, an avatar's thumbnail, the providers, web push). A visitor's profile carries what its page shows them, nothing of the account. The settings' small forms are Actions (an address and the token of its intent); a screen carrying tokens is Base\Screen\Confidential, whose answers are private, no-store and vary on Cookie. A screen's props never take one of the frame's keys (Frame::RESERVED): the responder refuses it. A template a site overrides gets the variables of before as well (ScreenResponder::legacy()); a host page renders the core's profile template with the user alone, account_profile(user) giving it the model. The forms (profile edit, sign-in, sign-up, passwords, two-factor setup) stay Symfony's (D3).

What the classes read through BaseTrait, on contracts (step C4b)

What a class of the core still asked of BaseTrait's services after C3e, now asked of the registry, in the order lesringostars' pages go through it. Each move keeps the answers under Symfony (a test compares them with the service's, its old code copied as it was) and gives answers where there is no framework (tests/Contract/basetrait-seams-without-framework.php, run by BareTest). BaseTrait itself stays, its accessors' signatures unchanged, for the bundles and the sites that call them (since C9 the ones a contract answers ask it, above).

Base\Entity\User reads nothing through BaseTrait any more (it still uses it: the sites call its accessors on a user).

Where C4b stops. Left on BaseTrait, each for a reason: Notification (the notifier, Twig and the project's directory - its message half is already Bridge\Symfony, step C3f; the notifier is a Symfony service by nature), AbstractExtension::isEntity() (Doctrine's metadata, a question for Bridge/Doctrine), Uploader's AttributeReader (omnibase's own service, already in the Foundation), MediaEnhancer (the media service inside the Wysiwyg pipeline, which Texts already covers from outside), the forms, fields, controllers and validators (Symfony by nature, decision D3), and the bundles' entities (step C8).

What an entity is called: Base\Service\Model\EntityNouns. The rule of Translator::transEntity(), transEntityExists() and parseClass() (the key of a class: its name less its entity namespace, dotted, in snake case - Base\Marketplace\Entity\Order is marketplace.order; then the variants its options ask for, NounVariants, the first the "entities" catalogue holds) moved into a class of the Foundation, built on the Translations contract and the entity namespaces of the application's bundles. The translator now answers by an instance of it over itself (getEntityNouns(), the bundles BaseBundle knows), and that instance is the Nouns contract under Symfony: one rule, the same strings. A host without the framework builds one with new EntityNouns($translations, EntityNouns::namespacesOf([...its bundle classes])) and binds it to Base\Contract\Nouns.

A number of seconds in words: Base\Service\Model\Duration. Translator::transTime()'s words (base.years to base.seconds, ICU plurals; a month of 30 days) over the Translations contract (trans()). Under Symfony that is the translator chain, so a unit the team rewrote in the back office is the one printed, as before; transTime() now answers by it.

The Doctrine mapping, with or without Symfony

omnibase assembles part of its entities' mapping at runtime: the attributes read by Base\Attributes\AttributeReader (#[DiscriminatorEntry], #[Alias], #[Hierarchify], #[Cache], #[OrderColumn], #[Cascade], #[OrphanRemoval], #[Vault]...), the translations' associations and discriminators (IntlSubscriber), the enumerations as column types, the trash_filter and the vault_filter, the DQL functions. Since step C6 of the plan "omnibase agnostique" all of it is wired by Base\Bridge\Doctrine - under Symfony through the bundle, as before, and on an entity manager built by hand without DoctrineBundle - on doctrine/orm as published: nothing needs a member Doctrine keeps private, and nothing patches doctrine/orm (since 4.0 the core declares its one patch, on symfony/process, to omnibridge/composer: extra.omnibridge).

In omnibridge/doctrine since step F3

Since step F3 of the plan "omnibase agnostic" (2026-11-02), the core's Doctrine classes are omnibridge/doctrine's, under Omnibridge\Doctrine\Omnibase\: 142 classes, by one rule - Base\Bridge\Doctrine\X is Omnibridge\Doctrine\Omnibase\X, any other keeps its path below Omnibridge\Doctrine\Omnibase\.

What stays in the core: the neutral parts - the finder language (Base\Database\Repository\Finder\*), Entities, Repositories, the repository interfaces (Base\Repository\Users, Thread\Tags...) and Aliases, the shapes (EntityShape, EntityShapes, DescriptionShapes), the schema rules, the enumerations (EnumType, SetType, Enumerations), Utc, the behaviours' attributes and their neutral backends' contracts, the listeners' logic (Base\Database\Lifecycle\*). The Doctrine half of Base\Bridge\Symfony\FrameworkLocator is Omnibridge\Doctrine\Omnibase\DoctrineLocator (FrameworkLocator's methods call it). #[Cache]'s regions, #[Vault]'s unique constraints and #[OrderColumn]'s order field - the attributes' loadClassMetadata(), typed on Doctrine's ClassMetadata - are Omnibridge\Doctrine\Omnibase\Behaviour\DoctrineMappingHooks, which AttributeSubscriber and the manipulator call for each attribute before its own (deprecated) Doctrine-typed hook.

The former names keep working, until 6.0: src/Resources/former-names.php (required by Functions.php) aliases each one, from src/Resources/former-names.doctrine.php (former => new; Base\Database\FormerNames reads it). The alias is declared whichever name is loaded first - asked by its former name, the moved class is loaded and aliased; loaded by its new name (or as a parent), its file is included by the core's autoloader and the former name aliased at once, because PHP checks an instanceof or a type written with a name without autoloading it. For the same reason the core's extension sets .container.dumper.inline_class_loader to false: Symfony's debug container would otherwise include the services' files itself, past the autoloader.

• The entities still name their repositories by their former names (repositoryClass: UserRepository::class, Base\Repository\UserRepository): Doctrine's metadata, and MetadataSnapshot, are those of before. BaseBundle maps the moved repositories Base\Repository\X => App\Repository\X from omnibridge/doctrine's folder, and registers them under their former ids, as before.
• An entity's repositoryClass may name a repository interface of the core (Base\Repository\Thread\Tags): Omnibridge\Doctrine\Omnibase\RepositoryFactory::implementation() gives the repository bound to it (Base\Repository\Aliases::INTERFACES), and under Symfony Base\Discovery's repositories (omnibridge/symfony's DiscoveryPass) adds the interfaces to DoctrineBundle's repository locator.
• The moved services are registered under their new names; their former ids are aliases (config/services/database.php).
• MetadataSnapshot names a filter or a type whose class moved by its former name: it compares the mapping, not where a class lives.
• The core still requires omnibridge/doctrine (and doctrine/*) until the composer.json switch (F6), so that the sites keep everything they had.

Without Symfony

use Doctrine\DBAL\DriverManager;
use Omnibridge\Doctrine\EntityManagers;
use Omnibridge\Doctrine\Omnibase\Mapping;   // formerly Base\Bridge\Doctrine\Mapping

$connection = DriverManager::getConnection(['driver' => 'pdo_mysql', 'host' => ..., 'dbname' => ...]);
$entityManager = EntityManagers::create($connection, [
    $vendor.'/omnisense/omnibase/src/Entity',
    $projectDir.'/src/Entity',
    // a bundle's src/Entity...
], configure: Mapping::configure(...));   // the repository factory, before the entity manager exists
$mapping = Mapping::register($entityManager, [
    'project_dir' => $projectDir,          // its src/Enum, its src/Attribute
    'environment' => 'prod',               // the vault filter's
    'types' => [/* a bundle's enumerations, by name */],
    'resolve_target_entities' => [/* interface => class */],
]);

$articles = $entityManager->getRepository(App\Entity\Blog\Article::class)->findBy([], ['id' => 'DESC'], 10);
$article = $entityManager->createQuery('SELECT a FROM App\Entity\Blog\Article a WHERE a.slug = :slug')->setParameter('slug', 'le-fuji')->getOneOrNullResult();

Mapping::register() is called before the first metadata is read. Doctrine's own ClassMetadataFactory is used; the class names are the core's (D6).

What the hand-built side does not have: the framework's services. The AttributeReader is given no router, request stack, token storage, filesystem nor event dispatcher (an asset's base path, the user signed in, the routes' attributes answer without them), IntlSubscriber no localizer, and the parameters are those given (Base\Service\ArrayParameterBag). Symfony's doctrine-bridge types (uuid, ulid, date_point...) are Symfony's alone.

The enumerations

An enumeration of omnibase (Base\Database\Type\EnumType, SetType: ThreadState, UserRole, an application's or a bundle's) is a plain PHP class since step F2a of the plan "omnibase agnostic": its constants are its values, toDatabaseValue() and toPHPValue() its conversions (a SetType's values joined by commas). On Doctrine each is a Base\Bridge\Doctrine\EnumTypeAdapter registered under its getStaticName() (thread_state, user_role): an ENUM(...) column, SET(...) for a SetType, a CLOB on SQLite. Base\Database\Type\Enumerations::classOf('user_role') gives the enumeration of a type's name, whatever persistence registered it.

• Under Symfony an enumeration is still listed in DoctrineBundle's doctrine.dbal.types (the core's and the application's by BaseExtension, a bundle's by its own prepend: omnibase/marketplace); Base\Discovery's enumerations (omnibridge/symfony's DiscoveryPass) takes them out of it (DoctrineBundle instantiates each type's class) and gives them to Base\Bridge\Doctrine\EnumerationsMiddleware, which registers the adapters when the connection is made, before any metadata is read - the moment DoctrineBundle registered them. The parameter base.database.enumerations lists them by name.
• By hand, Types::register() registers them (the folders' enumerations, and those given by name).
• ClassMetadataManipulator::getDoctrineType() answers an enumeration's column with an instance of the enumeration, as the type was before, so instanceof EnumType and its static methods answer as they did; MetadataSnapshot writes an enumeration's type by the enumeration's class, so the recorded metadata is unchanged.

The behaviours' hooks

omnibase's behaviours (#[Timestamp], #[Slugify], #[Uploader]...: Base\Attributes\AbstractAttribute) answer the moments of an entity's life. Since step F2b of the plan "omnibase agnostic" they have neutral hooks (onPrePersist(Lifecycle\PrePersist $event, ?string $property), ..., onOnFlush(Lifecycle\OnFlush $event, object $entity, ?string $property)) taking omnisense/omnibridge's events, which carry the entity and the unit of work (Base\Bridge\Doctrine\DoctrineUnitOfWork on Doctrine). AttributeSubscriber relays Doctrine's events: the neutral hook first, then the Doctrine-typed hook of before (prePersist(LifecycleEventArgs, ClassMetadata, $entity, ?string)), kept for the applications' and bundles' attributes that override it. Another persistence dispatches the neutral events alone. Only the fields a neutral PreUpdate hook gave a new value (setNewValue()) are passed on to Doctrine's update; a hook that changes the entity and calls recompute() keeps what Doctrine's change set says.

The persistence's part of a behaviour

What only a given persistence can do is asked of a small interface of Base\Database\Attribute\Backend, one per behaviour, implemented once per persistence and registered for its unit of work class with Backends::register(); a behaviour asks $this->backend($event, VaultBackend::class) and gets the implementation for the unit of work its event carries, or an UnsupportedBehaviourException when the persistence has none.

AttributeSubscriber registers Doctrine's (DoctrineBehaviours::register()) when it is made, under Symfony and in Base\Bridge\Doctrine\Mapping alike. #[Uploader] needs none: the unit of work's contract covers it (contains(), isNew(), recompute()). The mapping hooks (loadClassMetadata(): #[Cache]'s regions, #[Vault]'s unique constraints) stay Doctrine's. At step F3 the Doctrine implementations move to omnibridge/doctrine as they are; omnibridge/eloquent brings its own at F7 (a persistence without a second-level cache implements CacheBackend as nothing to do).

The entity's shape

A behaviour reads the entity's mapping through $this->shape($event, $entity), a Base\Database\Mapping\EntityShape (one Omnibridge\Schema\Entity of the Description: fields and types, associations and their kind and side, identifier, root, discriminator), never Doctrine's ClassMetadata. The shapes come from the persistence (EntityShapes, registered in Backends like the behaviours' parts: DoctrineShapes on Doctrine, each class's metadata written by MetadataDescription) or from a Description (DescriptionShapes). #[Alias], #[Associate] and #[OrderColumn] read it; ClassMetadataManipulator answers the association kinds and sides from it for an entity or a class (a ClassMetadata being built is read as it stands), and EntityHydrator its defaults and identifiers. OrderColumnBackend keeps a lazy collection's positions until it is read (Doctrine's PersistentCollection); without it the property is sorted when loaded.

The entity's values, the old entity and its changes (step F7c)

AbstractAttribute's helpers getFieldValue(), setFieldValue(), getPropertyValue(), setPropertyValue(), getEntityChangeSet(), getOriginalEntityData(), getOldEntity(), getOldEntityData(), getEntityFromData() and getPropertyOwnerRepository() take, last, the unit of work of the hook's event. Given one whose persistence registered its shapes, they answer on omnisense/omnibridge's contracts, whichever persistence keeps the entity:

• the values through Base\Database\Entity\EntityValues (the shapes in place of Doctrine's metadata: a mapped property read and written as it is held, an enumeration field as its backing value, any other through Symfony's property accessor, paths and translations followed; what ClassMetadataManipulator does);
• the changes: recompute() then changes(); the old entity: Snapshots::original(), the identifier beside, the changes' former values over it (a persistence without Snapshots is refused with UnsupportedBehaviourException);
• the slug's holder: the persistence's Repositories.

#[Slugify] and #[Uploader] pass their event's unit of work; #[Timestamp], #[Blameable], #[Randomize] and #[GenerateUuid] too. Without one the helpers keep omnibridge/doctrine's ClassMetadataManipulator, as before (an application's attribute calling them statically). Still read on Doctrine's metadata where Doctrine is installed (step F7d makes them neutral): #[OrderColumn]'s field name, #[Uploader]'s declaring class (its path) and static readers (getPublic(), get()), #[Hashify] and #[Countify]'s helpers. omnibridge/eloquent runs the behaviours on its unit of work (its relay, its parts, its listeners' adapters: its docs/behaviours.md); the core's behaviour tests run on both backends (docs/30-operations/harness.md, the harness switch).

The core's services on the unit of work

Plan "omnibase agnostic", step F2d. The core's services, listeners, stores, controllers and commands take omnisense/omnibridge's UnitOfWork where they took Doctrine's entity manager, and ask it nothing of the ORM:

• writing: persist(), remove(), flush(), refresh(), contains(); an entity's identifier and class: identifier(), className();
• reading: their repository by its interface (Base\Repository\*, a new User\Identities, the Passkeys finder findOneByCredential()), or UnitOfWorks::repositories($unitOfWork)->of($class) for a class named at run time (Base\Database\Repository\Repositories);
• an entity's fields: UnitOfWorks::shapes($unitOfWork) (the entity's shape, above);
• what only a persistence does, a small interface of Base\Database\Backend registered in Backends like the behaviours' parts:

Base\Database\UnitOfWorks::of() gives the unit of work for what a service was handed: the unit of work itself, or a persistence's manager adapted once (UnitOfWorks::ADAPTERS, Doctrine's entity manager to DoctrineUnitOfWork; another persistence registers its own). The services' constructors still accept the entity manager, as the deprecated other half of a union (UnitOfWork|EntityManagerInterface, until 6.0): omnibridge/laravel, the bundles' wiring and the tests hand it to them. Under Symfony the container's Omnibridge\Persistence\UnitOfWork is DoctrineUnitOfWork over the entity manager, and the union is aliased to it, so that an autowired constructor gets the same instance. A DoctrineUnitOfWork registers Doctrine's backends when it is made (DoctrineBehaviours::ensureRegistered()), before any Doctrine event.

With base.persistence: eloquent (step F7d) every service that takes the unit of work or a repository interface answers from omnibridge/eloquent. The declarations therefore name the core's repository interfaces, never a Doctrine repository class (Analytics, SettingBag, the connections' tracker and listeners, FormGuard, the enhancers, the push and notification services: step F7d-3), and ConnectionSubscriber, DemoAccountFactory and UniqueEntityValidator work on the unit of work. What is still Doctrine's under Eloquent: Doctrine's metadata where it is read (field types, the AttributeReader), the TimeMachine, the console commands named after Doctrine, the back office, and the repositories without an interface (Layout\Widget\PageRepository, TextOverrideRepository, User\GroupRepository, User\PermissionRepository).

What keeps the entity manager, on purpose: the mapping (ClassMetadataManipulator, ClassMetadataFactory, EntityHydrator), ServiceEntityRepository, the Doctrine listeners, the Doctrine commands (doctrine:database:import, doctrine:array:upgrade, the schema's charset), the validators and CropperType (the form layer, F5b), AbstractEventDispatcher and BaseNotifier (F5a), DemoAccountFactory (Doctrine's fixtures), Base\Console\Command (omnibridge/symfony's Omnibase\Console\Command since F5c; its deprecated $entityManager, read by the applications' commands, beside its $unitOfWork), Base\Bridge\Symfony\FrameworkLocator (since F2f: the entity manager and the registry BaseTrait handed out, now deprecated there). tests/Database/UnitOfWorkPathTest keeps the converted files off the entity manager.

The scopes and the pages

Step F2e. The trash and the vault are scopes (omnisense/omnibridge's Scope): Base\Database\Scope\TrashScope keeps a #[Trasheable] entity while its deletion field is null, VaultScope a #[Vault] entity whose vault field is null or names the environment it was enabled with. Doctrine compiles them as its SQL filters trash_filter and vault_filter (TrashFilter, VaultFilter, same SQL as before); Base\Bridge\Doctrine\DoctrineBackend (omnibridge's Backend, the service Omnibridge\Persistence\Backend and in Backends) enables and disables them by the scope's name. TrashManager::withTrash() asks the Backend; the extension rows of a destroyed entity go through Base\Database\Backend\BulkDeletes.

Pagination pages an array, or Base\Service\Model\Pages (a count and a slice). A Doctrine Query is adapted to Base\Bridge\Doctrine\QueryPages, which keeps what Pagination did with it: the rows grouped by id through Doctrine's Paginator, the translations joined, the total counted on a clone by CountWalker. Both move to omnibridge/doctrine at F3; an Eloquent backend brings its own Backend and Pages at F7.

The lifecycle listeners: logic and Doctrine wiring

The listeners that record something keep their logic in Base\Database\Lifecycle, on no persistence, and their Doctrine part in their former class, which keeps its name and its wiring:

The others are Doctrine's by nature and move as they are at F3: IntlSubscriber (the translations' mapping and discriminators, orphan removal), ExtensionSubscriber (extension rows written inside the flush), InverseCollectionCacheSubscriber (the second-level cache), TrackingPolicySubscriber (the mapping), AttributeSubscriber itself (the relay, the mapping and query hooks). DemoAccountLockSubscriber reads the request and the session (step F5a); ConnectionSubscriber, UserSubscriber and ThreadSubscriber (besides its Doctrine wiring above) listen to Symfony's events (F5c).

The discriminator maps

A root entity that declares an inheritance and no #[DiscriminatorMap] gets one generated by MappingDriver, after the attributes are read: the class and every subclass the driver knows, each under its class name, which #[DiscriminatorEntry] (AttributeSubscriber, loadClassMetadata) then renames (common, marketplace_product, forum_topic...). Doctrine generates such a map itself, under the classes' lower-cased short names - which collide here (App\Entity\Thread\Tag and Base\Entity\Thread\Tag are both tag) - and its getShortName() is private: until C6 glitchr/base-plugin made it protected so that omnibase's factory could answer the class name. The map is now there before Doctrine looks, with the keys the factory gave.

The resolveDiscriminator event (Base\Database\Events) is dispatched by the driver before a class is read, as the factory dispatched it: IntlSubscriber gives a translation class (ThreadIntl...) the inheritance and the map of its translatable.

The proof

tests/Bridge/Doctrine/HandBuiltEntityManagerTest (the harness, or an application's vendor suite):

• an entity manager built by hand in a PHP process of its own (tests/Bridge/Doctrine/hand-built.php: Composer's autoloader, a DBAL connection, EntityManagers::create(), Mapping::register()) gives the metadata Symfony's gives, class by class - Base\Bridge\Doctrine\MetadataSnapshot: every public property of each ClassMetadata (table, inheritance, discriminator map and value, fields and their types, associations, cache, callbacks, entity listeners, repository), what each filter adds to a query of it, the completor the attributes filled (aliases, hierarchy), the types registered - on the same database, and reads the thread Symfony wrote; the process loads neither the kernel nor a bundle;
• Symfony's entity manager gives the metadata it gave before C6 (fixtures/doctrine-metadata.json, recorded on the code of before with DOCTRINE_SNAPSHOT=1; the discriminator maps and the subclasses compared sorted: generated, they come in the order PHP declared the classes).

Since step R14 the mapping driver also reads the classes' declarations rather than the attributes (omnibridge/doctrine's DeclarationDriver): the structure is described once, outside Doctrine - see schema.md.

The harness runs it on doctrine/orm as released: docker compose -f compose.yml -f compose.checkouts.yml run --rm -v <doctrine/orm's release>/src:/srv/demo/vendor/doctrine/orm/src:ro omnibase test.

The data structure, described outside Doctrine

Marco's bridge principle (2026-10-19): the omni bridges are only the adapters of contracts for one technique, so that several persistence techniques can map the same tables - Doctrine today, Eloquent or another tomorrow - without changing the structure (the naming, the columns, the relations, the discriminators). Since step R14 of the audit "lesringostars face au master plan", that structure is described once, outside any ORM, and Doctrine reads it.

Where it lives, and why

• omnisense/omnibridge, Omnibridge\Schema (framework-free, ORM-free): the generic part. Schema\Declaration reads what the entity classes declare from their attributes by reflection, without instantiating them - the attributes are Doctrine\ORM\Mapping's, the vocabulary every omnibase entity is written in, but their classes need not exist (Vocabulary holds their parameters and defaults as data). Schema\Description is the neutral description: each Entity (table, kind, parent and root, Inheritance with its column, map and value, identifier, Fields with their portable types, Relations with their JoinColumns or JoinTable) and each Table (Columns, primary key, Indexes, ForeignKeys), plain data too (toJson()). Schema\Builder builds it from the declarations alone, the way Doctrine completes its metadata and the way its SchemaTool makes the tables; Schema\Naming (CamelCaseNaming) names what the declarations leave unnamed, including an index or a foreign key as DBAL names it. Schema\Database\MySqlSchema reads a MySQL information_schema and compares it with a description.
• omnibridge/doctrine: the Doctrine side. DeclarationDriver builds Doctrine's metadata from the declarations (wrapping the application's driver, which still says which classes exist); MetadataDescription writes what an entity manager maps in the neutral form; NamingStrategy answers Doctrine's naming strategy with the family's Naming.
• the core, Base\Database\Schema (Foundation): what is omnibase's own - the rules its listeners add to Doctrine's metadata, written once more as Omnibridge\Schema\Builder\Rules applied at the same three moments (before the declaration is read, once declared, once loaded): DiscriminatorRule (the maps generated under class names, #[DiscriminatorEntry]'s values), VaultRule (#[Vault]'s unique constraints), OrderColumnRule (#[OrderColumn]'s json column), TranslationRule (a translation's inheritance from its translatable, the translations and translatable relations, locale, <table>_unique_translation), TargetRule (the targets DoctrineBundle resolves) and ExtensionRule (extension_entity); and Describer, which builds an application's description from its entities' folders with omnibase's naming and rules.

The split follows the A1/A2 rule of the plan: generic glue for a host or a technique goes to omnibridge, what reads omnibase's own models stays in the core.

How Doctrine uses it

Under Symfony DoctrineConfigurationPass wraps every entity manager's driver in omnibridge/doctrine's DeclarationDriver, then in Base\Bridge\Doctrine\MappingDriver; Base\Bridge\Doctrine\Mapping::register() does the same on an entity manager built by hand. Doctrine thus no longer reads the attributes itself: its metadata are built from the declarations - the same source the ORM-free description is built from - and they are those its attribute driver built, to the property (MetadataSnapshot, every class, on both hosts).

use Base\Database\Schema\Describer;

$description = Describer::describe([$vendor.'/omnisense/omnibase/src/Entity', $projectDir.'/src/Entity'], ['project_dir' => $projectDir]);
$description->table('thread')->column('slug');                    // string(255), not null
$description->entity(Base\Entity\Thread::class)->relation('tags'); // many_to_many, join table thread_tags
file_put_contents('var/schema.json', $description->toJson());

The proof

tests/Bridge/Doctrine/SchemaDescriptionTest (the harness, or an application's suite run from vendor/):

• the entity manager's driver is the DeclarationDriver;
• the description Describer builds without any ORM is MetadataDescription's of the entity manager, entity by entity and table by table (the harness: 202 classes; lesringostars: 115), and #[DiscriminatorEntry]'s values derived without the attribute's reader are Doctrine's;
• on MySQL (lesringostars), the description is the database's own schema: every table, column (SQL type, nullable, default, auto-increment), primary key, index and foreign key read from information_schema, nothing of Doctrine asked (doctrine_migration_versions and messenger_messages apart).

The schema created from it (step F7a)

A new site creates its tables from the description, whatever the persistence; migrations evolve an existing database and belong to the persistence chosen (the plan "omnibase agnostic", answer 11).

• Base\Database\Schema\EntitySchema is the core's describer, with no persistence installed: the same description as Describer (omnibridge/doctrine's, which feeds Doctrine; the test compares them), and omnibase's column types as data (columnTypes(): the enumerations' and sets' values, array and the passkeys' base64 and AAGUID columns as texts, their trust path as JSON - the SQL Doctrine's types declare, the test compares them on MySQL and SQLite).
• omnisense/omnibridge's Omnibridge\Schema\Database\SchemaCreator writes and runs the statements (MySQL, SQLite), no ORM.
• omnibridge:schema:create on every host: bin/console omnibridge:schema:create (omnibridge/symfony: the folders, targets and enumerations Doctrine's configuration was given, the connection's PDO and default table options), php artisan omnibridge:schema:create (omnibridge/laravel: omnibridge.doctrine.entities beside the core's, omnibridge.doctrine.omnibase's options, Laravel's PDO), and in plain PHP vendor/bin/omnibridge-schema-create --schema=vendor/omnisense/omnibase/src/Resources/schema.php (the current folder's src/Entity beside the core's, or OMNIBASE_PROJECT_DIR; DATABASE_URL or --url/--dsn). Each has --dump-sql, and refuses a database that already holds a table of the description.

use Base\Database\Schema\EntitySchema;
use Omnibridge\Schema\Database\SchemaCreator;

$options = ['project_dir' => $projectDir];
$description = EntitySchema::describe(EntitySchema::directories($projectDir), $options);
(new SchemaCreator($pdo, EntitySchema::columnTypes($options)))->create($description);

The proof, in SchemaDescriptionTest: the database SchemaCreator makes is the one Doctrine's SchemaTool makes from the mapping - tables, columns in order (type, nullable, default, auto-increment), primary keys, indexes, foreign keys - on SQLite in the harness, and on MySQL where OMNIBASE_SCHEMA_DATABASES names two empty databases (lesringostars: 132 tables, 552 columns, 144 indexes, 157 foreign keys, no difference). BareTest creates the core's tables on SQLite from the core installed alone (no Doctrine at all) and reads them back as the description.

How another persistence would read it

An Eloquent (or any other) bridge needs no attribute of Doctrine's and no class of the core's mapping: it reads Omnibridge\Schema\Description - built by Describer::describe() once, or read back from the JSON file it wrote - and maps from it:

• a model per Entity: $entity->table is the table, $entity->identifier the key(s), $entity->fields the attributes with the column each one is kept in (Field::$column), its portable type (string, integer, json, datetime, thread_state...: the casts), nullable, length, enum (the PHP enumeration to cast to), generated (identity: the database gives the key);
• the relations: Relation::$kind says belongsTo (many_to_one, by its joinColumns), hasMany (one_to_many, through the owning side's join column named by mappedBy), hasOne/belongsTo for one_to_one, and belongsToMany with JoinTable::$name and its joinColumns/inverseJoinColumns;
• the hierarchies: Entity::$inheritance gives the discriminator column, the map (value => class) and the entity's own value - a single-table hierarchy is a global scope on the discriminator, a joined one a model per table keyed by the root's identifier (Entity::$root, Entity::$parent);
• the tables themselves (Description::$tables) for migrations or a schema check, with the same names, types, indexes and foreign keys as Doctrine's.

Nothing of it needs Doctrine installed: omnisense/omnibridge requires PHP and three PSR interfaces, and its BareTest proves the Schema loads with nothing else. The Eloquent bridge itself is a later step; this one gives it what to read.

Time and time zones

omnibase sets PHP's time zone per visitor: BaseBundle::boot() reads the visitor's zone in the cookie the page's script writes (LOCATION/TIMEZONE where the visitor answers for the time zone apart, else USER/INFO's timezone; User::getCookie('timezone') reads both) and calls date_default_timezone_set() with it, UTC without one - a visitor who refused that cookie included. new \DateTime(), date() and Twig's |date are therefore the visitor's clock: "today" is the visitor's day.

What a column holds depends on its Doctrine type:

datetime_immutable is Doctrine's own: the same instant is stored at different hours by a visitor in Paris and one in Tokyo, and a row written by one comes back as another moment to the other. It is right for a wall clock (a reservation at 20:00 in the restaurant, whoever looks at it) and wrong for a moment (when a message was sent, when a link expires).

A moment: utc_datetime_immutable

use Base\Database\Type\UtcDateTimeImmutableType;

#[ORM\Column(type: UtcDateTimeImmutableType::NAME)]   // 'utc_datetime_immutable'
private \DateTimeImmutable $sentAt;

#[ORM\Column(type: UtcDateTimeImmutableType::NAME, nullable: true)]
private ?\DateTimeImmutable $expiresAt = null;

The bundle registers the type (and utc_datetime, its \DateTime twin): nothing to configure. Whatever zone the object given carries, the column gets the moment in UTC; what comes back is a \DateTimeImmutable in UTC, the same moment for every request. To show it, {{ message.sentAt|date('d/m/Y H:i') }} converts to PHP's zone (the visitor's); in PHP, ->setTimezone(new \DateTimeZone('Europe/Paris')).

In a query, bind the parameter with the type, or as a UTC moment (Base\Database\Type\Utc):

$qb->andWhere('m.sentAt >= :since')
   ->setParameter('since', $since, UtcDateTimeImmutableType::NAME);
// or
   ->setParameter('since', Utc::from($since));          // the same moment, in UTC
Utc::now();                                             // the present, in UTC

A \DateTimeInterface bound without a type is formatted in its own zone, and compared as text with a column that holds UTC.

Existing columns

Nothing changes for a column that is not given the type: datetime_immutable keeps Doctrine's behaviour, datetime stays UTC.

Moving a column from datetime_immutable to utc_datetime_immutable changes no schema (both are the platform's DATETIME: doctrine:migrations:diff finds nothing on DBAL 4), but it changes what the stored values mean: rows written by requests in another zone than UTC hold that zone's wall clock. A site whose visitors have no timezone cookie yet (PHP was in UTC) has nothing to convert; otherwise the migration that accompanies the change shifts the rows from the zone they were written in:

UPDATE office_appointment SET startsAt = CONVERT_TZ(startsAt, 'Europe/Paris', 'UTC');

For bundles

Base\Restaurant\Model\Instant and Base\Office\Database\UtcDateTimeImmutableType answered the same need before the core did; a bundle now names the core's type and drops its own (utc_datetime_immutable is the same name as office's: its columns need no change).

The services, everywhere

Marco's answer 3 to the plan "omnibase agnostic" (2026-11-01): the host-only Symfony code leaves for omnibridge/symfony, but the services stay available everywhere - under Symfony, under Laravel, and in a plain PHP script. Step F5a (2026-11-02) is what makes that true.

One list, three containers

Base\Services::definitions() is the core's services as data (every one of them since step F5e slice 4a: 192 definitions in src/Resources/services/<group>.php): each a class (or its parent's), its service id (the class by default), the contracts it answers (interfaces and former ids, aliased to it, with their visibility), its arguments by position or by name in Omnibridge\Container's syntax - '@id' a service, '@?id' one or null, '%name%' a parameter, ['!tagged_iterator' => tag], ['!service_closure' => '@id'] -, its bindings, calls, tags, decoration and factory, what a host must have installed for it (requires) and the environment it is for (environment); what only Symfony's container gives it, by Symfony's own ids, is its symfony part. The format is omnisense/omnibridge's Omnibridge\Container\Declarations (its docs/container.md).

The whole graph builds in plain PHP: tests/Services/graph-without-framework.php (BareTest, on the core installed alone) gives Omnibridge\Container the host's contracts of container-without-framework.php, stand-ins for the repositories and the request's contracts, and builds every definition that applies (91 there; the others say what they require: Twig, omniauth, symfony/validator, the Symfony router...).

What a constructor asks and the list does not give is the host's: omnibridge's contracts (Urls, Views, Environment, Translations, Locales...), Base\Service\ParameterBagInterface, Base\Contract\MediaRouter, Base\Service\Storages, and three ids - imagine.bitmap, imagine.svg and Symfony\Component\Translation\Translator (the catalogues the core's translator decorates).

$container = Omnibridge\Container::fromDefinitions(Base\Services::definitions(), $parameters, [
    Base\Service\ParameterBagInterface::class => new Base\Service\ArrayParameterBag($parameters),
    Omnibridge\Contract\Views::class => $views,
    Omnibridge\Contract\Urls::class => $urls,
    Omnibridge\Contract\Environment::class => $environment,
    Base\Contract\MediaRouter::class => $mediaRouter,
    Base\Service\Storages::class => new Base\Service\Flysystem($drives),
    'imagine.bitmap' => new Imagine\Imagick\Imagine(),
    'imagine.svg' => new Base\Imagine\Svg\Imagine(),
    Symfony\Component\Translation\Translator::class => $catalogues,
]);
$container->get(Base\Notifier\Mail\EmailComposer::class)->compose('anne@example.org', '@App/mail/welcome.html.twig', ['name' => 'Anne']);

tests/Services/container-without-framework.php is such a script, run by bare --strict (BareTest::testTheServicesAreBuiltByAPlainPhpContainer): nothing of Symfony's container, the framework, Doctrine nor Twig is loaded.

Rendering through Views

The services that rendered with Twig's environment render through omnibridge's Views (and, for a picture an e-mail embeds, ViewSources): the notifier (BaseNotifier::getViews()), EmailComposer and InlineImages, Notification::renderHtml(), MediaService/FileService's media tags, Sitemapper, QrSheet, the sharing adapters, WysiwygEnhancer/EditorEnhancer, the ScreenResponder. Under Symfony and Laravel Views is omnibridge/twig's TwigViews over the host's environment (config/services/twig.php, omnibridge/laravel's provider); an application binds its own to render them with another engine. The e-mail's text part is written in PHP (EmailComposer::text(), what Twig wrote from EmailComposer::TEXT).

Each of these constructors still accepts Twig's environment, deprecated until 6.0 (Base\View\ViewsAdapter wraps it in a TwigViews, with an E_USER_DEPRECATED). BaseNotifier::getEnvironment() is deprecated for getViews(); BaseNotifierInterface declares getViews() in its place.

On contracts

• Paginator and Pagination: their links through Urls (Urls|RouterInterface; Symfony's advanced_router under Symfony, the links as they were).
• Translator: whether the kernel debugs through omnibridge's Environment (Environment|KernelInterface).
• Obfuscator: its compressions may be given to its constructor (iterable $compressions).
• AbstractEventDispatcher and BaseNotifier: omnibridge's UnitOfWork (the entity manager accepted, deprecated, as step F2d did; getEntityManager() deprecated for getUnitOfWork()); the dispatcher's association change set reads the entity's shape.
• DemoAccountLockSubscriber: its rule is Base\Demo\DemoAccountLock's (the original row, the columns, how to read and write them); the listener keeps Doctrine's identity map (it leaves with omnibridge/doctrine); the request and the flash message go through Omnibridge\Contract\Requests (F5c).

The request, the session and the events (F5c)

omnisense/omnibridge's Omnibridge\Contract\Requests is the request being answered, read without the framework's request object: has(), ip(), header(), uri(), host(), route(), attribute(), the session's session(), remember(), forget(), its flashes flash(), flashes(), and request() for code that still needs the host's own object. Symfony answers it with omnibridge/symfony's StackRequests, Laravel with omnibridge/laravel's LaravelRequests; outside a request nothing is read or written.

A RequestStack given is wrapped by Base\Http\RequestsOf in omnibridge/symfony's StackRequests.

The entity events are dispatched with Omnibridge\Event\Events::dispatch() through any PSR-14 dispatcher. AbstractEvent is a NamedEvent: its dispatcher sets the name it is raised under (user.register), Symfony's dispatcher is given that name, omnibridge/laravel's DispatcherEvents gives the event to the listeners of its name, so UserSubscriber::listen() registers the same listeners on Laravel's dispatcher as getSubscribedEvents() does on Symfony's.

A notification's e-mail is the Twig bridge's NotificationEmail under Symfony; on a host without Symfony's Twig bridge (Laravel) it is EmailComposer::compose()'s, from NotificationMessages::composed().

The options, one schema (F5e slice 4b)

The options under base: are declared once too: Base\Options reads src/Resources/options.php, a schema in omnisense/omnibridge's Omnibridge\Options\Processor format. Each node has a type (bool, int, float, scalar, enum with its values, mixed, array), an info, a default, and may be deprecated, bounded (min, max) or nested: an array holds named children (completed with their defaults when defaults is true) or a prototype (a list, or a map by its key attribute; default_children, default, deep_merging).

Base\Options::process(['guard' => ['min_delay' => 5]])['guard']['min_delay']; // 5
Base\Options::parameters()['base.paginator.page_size'];                       // 10
Base\Options::process(['guard' => ['min_delay' => -1]]);
// Omnibridge\Options\InvalidOption: The value -1 is too small for path "base.guard.min_delay". Should be greater than or equal to 0

The defaults keep their placeholders (%kernel.project_dir%/public/maintenance.lock, %env(APP_ENV)%): each host resolves them (omnisense/omnibridge's Options\Placeholders). Options::environment() holds the variables a service reads through %env()% that need a value where the environment has none - Symfony's env(NAME) parameters, set by omnibridge/symfony where the group of services that reads them is compiled, and omnibridge/laravel's %env()% default. tests/Options/OptionsHostsTest gives the same configurations to Symfony's tree and to the Processor and expects the same values, refusals and deprecations.

What is discovered, one declaration (F5e slice 4c)

What a host looks for among the services is declared once as well: Base\Discovery reads src/Resources/discovery.php, one registry per kind (Discovery::KINDS, registries(), registry($kind)). Until slice 4c omnibridge/symfony held these lists in fifteen compiler passes and BaseExtension; one generic pass, DiscoveryPass, compiles them now.

The generic kinds (autoconfigure, collect, fallbacks) are in omnisense/omnibridge's Container\Discovery format: Omnibridge\Container::fromDefinitions($definitions, $parameters, $services, Discovery::registries()) builds with them, and BareTest checks that it discovers what Symfony's container discovers on lesringostars (tests/Services/discovered-by-symfony.php: the obfuscator's five compressions, the six sharing adapters, the enumerations, in their order). Symfony's own passes stay omnibridge/symfony's: TwigComponent, DoctrineConfiguration, WebauthnMapping, WebauthnDeprecatedAlias, Workflow, FormerFormTypes.

Left for later steps

• F5b: the field and form types (the neutral form layer); the services that take Symfony's form factory.
• F5c, what its first part left: BaseService (the facade, Symfony's by nature), HotParameterBag (the container's half of HotParameters), SecurityPolicy (the role hierarchy), the field types' twig arguments, EntityHydrator (Doctrine's metadata), Referrer's and the Notifier's use of omnibase's router; the moves of §2.2 (Console, the kernel subscribers, Routing, the warmers, Security, the controllers, DI, BaseBundle); config/services/*.php, which then read the list.

Politeness

A site says tu or vous, du or Sie, 常体, 丁寧語 or 敬語. That is one setting of the site, and one variant per text that changes with it.

# config/packages/base.yaml
base:
    translator:
        politeness: polite      # plain | polite | formal - unset by default

Unset, nothing changes: every text is the one written in the catalogue. The parameter is base.translator.politeness; Base\Service\Translator holds it (getPoliteness(), setPoliteness() for a message written to somebody the site addresses otherwise).

The three levels and the key of a variant

A text keeps one key and one base text. A variant is that key followed by the level, beside it in the same file:

# translations/notifications+intl-icu.fr.yaml
login:
    already: Tu es déjà connecté !
    already._polite: "Vous êtes déjà connecté !"

Nothing changes where the text is asked: '@notifications.login.already'|trans answers the base text or its variant, by the site's level.

What is tried, the first found wins:

A variant takes the parameters of its text ({0}, {name}, a plural). It is a text like another: asked by its own key (key._polite) it is answered as it is, whatever the level.

The base text is not at the same level in every language

The base text is whatever was written first. What a level needs depends on it:

omnibase itself ships French and English. A language's row holds for a bundle's or an application's catalogue in that language too: say in which level the base text is written, write the variants of the others.

For a Japanese site in formal: a _formal variant of each sentence addressed to the visitor (confirmations, errors, e-mails, the checkout's steps - 保存しました。 becomes 保存いたしました。, できません becomes いたしかねます), in the catalogues of the bundles it uses and its own. Labels, titles and buttons stay as they are. Until a variant is written the sentence stays in です / ます, which a 敬語 page tolerates.

Language first, level second

The catalogues are walked as Symfony falls back between languages, and in each one the variants are looked for before the base text. A German page whose text has no _plain variant keeps its German text - it is not given the French one that has it. A text missing in German altogether is read in the fallback language, at the level asked.

Whose text it is

Within a language, the closest hand wins:

1. a text rewritten in the back office (omnibase/admin's « Textes du site »): its key._polite if it rewrote one, else its key;
2. the application's own catalogue (translations/ of the project): its key._polite, else its key;
3. the bundles': their key._polite, else their key.

So an application that replaced a bundle's text under its key - a practice's « Aucun message. » in place of a forum's « Tu n'as aucun message dans ta boîte. » - keeps its sentence when the bundle brings a polite variant of the one it replaced, and still gets the bundle's variants for what it did not replace. Nothing in the merged catalogues tells whose a text is: the application's keys are read while the container is built (Base\Discovery's texts, Base\Translation\ApplicationTexts, from translator.default_path: YAML, PHP and JSON catalogues), and only when a level is set.

Where it applies

Base\Service\Translator is the translator service (it decorates Symfony's), so the level holds on every way a text is asked:

• the service (trans(), transQuiet(), transEntity(), transEnum());
• Twig: |trans, {% trans %}, the form themes' labels, helps and errors;
• the e-mails and the notifications, which translate through it;
• the validator's messages (a constraint's message is a key like another).

A text that refers to another one ("@notifications.login.success.day.first") is answered at the same level.

A call that gives its own level

It is answered at that one, the site's is not asked:

$translator->trans('@emails.resetPassword.subject', [Translator::TRANSLATION_POLITENESS => Translator::POLITENESS_PLAIN]);
$translator->trans('@emails.resetPassword.subject', ['politeness' => 'none']);   // the text as written
$translator->transEntity($user, 'email', [Translator::POLITENESS_FORMAL, Translator::NOUN_SINGULAR]);

{{ '@notifications.login.already'|trans({politeness: 'plain'}) }}

politeness is taken out of the parameters before the text is formatted.

Adding variants in a bundle or an application

1. Find the texts that address the reader at the base level (in French: tu, te, ton, ta, tes, toi and the imperatives - Choisis, Clique - which no pronoun gives away).
2. Write each variant under <key>._polite (or ._plain, ._formal) right after its text, same indentation, same parameters, same meaning.
3. An application overrides a bundle's variant as it overrides any text: the same key in its own translations/<domain>+intl-icu.<lang>.yaml.

tests/Translation/PolitenessCataloguesTest is the check omnibase runs on its own catalogues: every variant beside its text, with its parameters; in French no polite variant that still says tu, no text that says tu without one. Copy it for a bundle's catalogues.

The forms' guard

One option on a form, every check in its order:

$this->createForm(ContactType::class, $model, ['guard' => true]);
$this->createForm(ContactType::class, $model, ['guard' => ['action' => 'contact', 'min_delay' => 5]]);

Step 5 is spam_protection, on by default outside the back office as it always was: it runs only once the form is otherwise valid, so nothing is sent to the classifier for a form already refused. A robot caught by steps 1 to 3 does not reach the captcha's provider either.

The messages are the forms domain's guard.* (French and English), the captcha's the validators domain's - none says tu.

The option

The captcha after a few refused tries

A visitor who fills a form once does not see the captcha. Each try of a guarded form that is refused - by the guard (trap, time, lists, the classifier's spam) or because the form is invalid - counts one for that form and that visitor (the address, else the session; in cache.app, for 15 minutes); a form sent forgets them. From captcha_after tries on, the form prints the widget and the guard asks its token; below, nothing of the captcha is printed (neither the widget nor its script) and no token is asked. The trap, the time and the lists are asked every time.

The form refused at the threshold, printed again, carries the widget: the field is always in the form, but below the threshold it is taken out of the form's view, so form.guard_captcha is defined is false, form_rest and form_end print nothing of it, and a template that writes {% if form.guard_captcha is defined %}{{ form_row(form.guard_captcha) }}{% endif %} needs no change. Without cache.app - or without an address or a session to count by - the captcha is always shown, as it was before the threshold. captcha_after: 0, on a form or in base.guard, does the same.

Without omnisense/omnishield

omnisense/omnishield is suggested, not required. Without it - or without a gateway configured - the trap and the time alone, and no error. With it:

// config/bundles.php
Omnishield\Bridge\Symfony\OmnishieldBundle::class => ['all' => true],

# config/packages/omnishield.yaml
omnishield:
    gateways:
        forms: { factory: altcha, options: { hmac_key: '%env(ALTCHA_HMAC_KEY)%' } }
        emails: { factory: disposable }
    challenge: { gateway: forms }

when@test:
    omnishield:
        gateways:
            forms: { factory: fixed }      # the hidden field omnishield-token carries omnishield-fixed-token

# config/packages/base.yaml
base:
    guard:
        challenge: ~             # the captcha: null for omnishield.challenge.gateway, a gateway's name, false for none
        fallback: ~              # the captcha of a visitor who refused the third party the captcha reaches
        reputation: [emails]     # the lists asked about the sender
        classifier: ~            # the classifier behind SpamChecker; null: Akismet with api.spam.akismet
        unreachable: accept      # a list or a classifier that does not answer: accept, or reject
        min_delay: 3
        sign_in_after: 3         # failed sign-ins from an address before the sign-in asks the captcha
        captcha_after: 3         # refused tries of a form from a visitor before it shows its captcha; 0: always

The captcha's own conduct when its provider does not answer is omnishield's (omnishield.challenge.unreachable).

With glitchr/ux-google

Where google.recaptcha.enable is true, ux-google's extension adds its own captcha (_captcha) to every form: the option guard then adds no second one - the trap, the time, the lists and the classifier stay. The places that ask ux-google's reCAPTCHA themselves (CommentType's recaptcha, omnibase/faq's AskType, the sign-in's badge) are left as they are.

Guarded by default

The captcha is checked by the guard itself, in its order and whatever the form's validation groups (the sign-up validates in new alone, where a field's constraint is not asked).

The sign-in

Symfony's login_throttling is the first line (five tries a minute). From base.guard.sign_in_after failed sign-ins from an address (3, counted for 15 minutes in cache.app, forgotten after a success), the sign-in form carries the captcha and a sign-in without a valid token is refused before its password is checked (Base\Security\SignInGuard). Not the rescue door, not the demonstration's one click; nothing where ux-google's reCAPTCHA is on.

Consent

ALTCHA, the default, reaches nobody: omnishield's Symfony bridge serves its widget's script from the site (omnishield/altcha ships it: /omnishield/altcha/3.3.0/altcha.min.js), so the page loads nothing from anyone else and there is no consent to ask. Nothing to add on a site but omnishield's bundle; omnishield.serve_scripts: false would put the CDN back.

A captcha whose widget reaches a third party (Widget::reachesOthers(): Turnstile, reCAPTCHA, ALTCHA's script when a site names a CDN) waits for the visitor's consent - omnibase/consent's feature CAPTCHA, declared by Consent.use() - kept inert in a <template> until then. Beside it, the fallback that reaches nobody (base.guard.fallback, ALTCHA) is shown, and stays after a refusal: a refusal does not open the form. The guard asks the third party's token when there is one, the fallback's otherwise. Without a fallback, a widget that sets cookies (reCAPTCHA) waits all the same; one that sets none is loaded at once. A page without omnibase/consent's script shows the fallback alone.

In a site's tests

The test client submits a form the moment it reads it, and a suite signs in wrong on purpose:

when@test:
    base:
        guard:
            min_delay: 0          # the stamp is still checked: post the one the page prints
            sign_in_after: 0

Or keep the site's delay and move the clock rather than wait: the guard reads the time from the clock (Symfony's clock, else Base\Contract\Runtime::clock()), never time(); the core's HTTP tests use Tests\Base\Http\MovesTheClockTrait (takeTheTimeAPersonTakes() between reading the form and sending it, putTheClockBack() in tearDown()).

With factory: fixed as the test captcha, the page prints a hidden omnishield-token field holding omnishield-fixed-token, outside the form: a test client that submits the page's form sends it; a request built by hand adds it. Below captcha_after the page prints no captcha and none is asked: a token posted all the same is not read.

The comment forms

Base\Service\CommentGuard is the comment forms' face of FormGuard: CommentType's url trap and opened time, and a second comment from the same address within base.comments.flood_interval. omnibase/blog and omnibase/video call it.

Account security

Base\Service\SecurityPolicy is the one place that says what an account may change about its own security; the settings page (/settings), the actions behind its buttons and the enrolment prompt all ask it. In a template it is the global security_policy.

What the administrator sets

Settings, saved in the back office (each has its own default while unsaved):

A second factor for some roles

"Mandatory" in the settings is for everyone or no one. An application that requires a second factor of some accounts only - the staff of a practice, not its patients - says which roles:

# config/packages/base.yaml
base:
    security:
        two_factor:
            required_roles: [ROLE_STAFF]   # held directly or through security.role_hierarchy
            postpone: true                 # false: no "not now" on the enrolment prompt

The list is one value: defined again - in the file's when@dev or when@test block, or in another file - the later definition replaces it (Symfony would append the items of a list; this one opts out), so an environment can require it of other roles, or of none:

when@test:
    base:
        security:
            two_factor:
                required_roles: []         # nobody is sent to the enrolment page in the tests

A definition that does not name required_roles (only postpone, say) keeps the list as it was.

An account holding one of these roles and no second factor is sent to /settings/security-required (user_settings_enrolment) by SecurityEnrolmentSubscriber - on a plain page load only: a form post, an XHR, a download are never interrupted, nor the settings, sign-in and sign-out pages. It cannot switch its last factor off afterwards. Every other account stays free to choose. While base.settings.security.two_factor is off, nothing is required of anyone.

postpone: true (the default) keeps the prompt's "not now": the answer lasts the session, and the prompt returns at the next sign-in. With false the button is gone and the account is sent back to the prompt on every page until it has a second factor. An administrator impersonating the account is never the one asked to enrol.

$policy->isTwoFactorMandatory();        // for the whole site (the administrator's setting)
$policy->isTwoFactorMandatory($user);   // for this account: the setting, or one of its roles
$policy->isTwoFactorRequiredByRole($user);
$policy->needsEnrolment($user);         // mandatory for it, and it has none
$policy->canDisableTwoFactor($user);
$policy->canSkipEnrolment($user);

A passkey replaces the password; it is not counted as a second factor.

In the demo environment

A declared demonstration account (The demo environment) is shared by every visitor: nothing above is required of it - not the second factor of its roles, not "mandatory for everyone" - and it changes none of its credentials (isDemoAccount($user), canChangeCredentials($user), canEnableTwoFactor($user)). Every other account, and every environment other than demo, is as described here.

Under omniauth (Base\Auth\)

With omnisense/omniauth installed (the core suggests it, its identity providers included, and its method packages omniauth/webauthn and omniauth/otp - formerly omniauth/passkey and omniauth/totp; Google is omniauth/google), Base\Auth\ fills its contracts on omnibase's own tables - the same rows Symfony's sign-in reads today, so an account signs in the same way under any host. Nothing is wired by the core itself: a host bridge (omnibridge/symfony, omnibridge/laravel) mounts them.

The TOTP secrets at rest (Marco's decision QA5). A site turns sealing on with totp: { secret_key: '%env(OMNIAUTH_TOTP_KEY)%' } in omniauth.yaml (its Laravel twin: 'secret_key' => env('OMNIAUTH_TOTP_KEY') in config/omniauth.php, the same key): base64 of 32 bytes, from the secrets vault in production, .env.local in development, a fixed key of the test environment's own in .env.test - never a committed real key. The settings page (UserSettingsController) writes the enrolled secret through omniauth's TotpSecrets and opens it only to draw the QR code; the sign-in opens it only to verify a code. The secrets written in clear before are read as they are until the site's migration rewrites them (lesringostars: Version20261023120000, up seals, down opens, idempotent); the column (VARCHAR(255)) holds the 130 characters of a sealed secret unchanged. Rotating the key: omniauth/otp's docs/otp.md.

Base\Auth\Policy is this page's rule on omniauth's second-factor rule: a demonstration account is never asked for one; an account a second factor is required of and that has none is signed in, then sent to enrol (needsEnrolment()); turning off the last second factor of such an account is refused (onRevoking(), reason two-factor-mandatory), any credential of a demonstration account too (demo-account); and an account that has a second factor or an administration role (SecurityPolicy::isAdministrator()) is never linked to an identity provider by its address alone (allowsEmailLinking(), through PolicyLinking).

The listeners, Base\Auth\Listener\*, each say which events they take (events()): GuardSignIn (the captcha after failures from an address, SignInGuard), TrackConnections (the browsers' connections), WarnNewDevice (the e-mail and the offer of a new device), UpdateAccount (unknown roles, time zone, language, kick, at each sign-in) and WelcomeBack (the e-mail of a disabled account).

The account's pages, written once (Base\Auth\Account\)

The decisions of the account's pages are the core's (plan "omnibase agnostic", step F5e, slice 5a); each host's controller or route keeps the forms, the firewall and the authenticator, and turns the rule's Base\Auth\Account\Outcome into its response.

The other pages (slice 5b)

The rest of omnibridge/symfony's controllers ask the core the same way; a page that answers JSON gets a Base\Screen\Json (its data and its status), a download a Base\Screen\File.

Each is decided under bare --strict (tests/Request/Pages/pages-without-framework.php and its expected result).

The demo environment

A fourth environment beside dev, test and prod: APP_ENV=demo runs a site as a demonstration - production's behaviour (no debug), a database of its own, and accounts that are always there, one for each role of the trade. A visitor reads the account's name in the banner of any page, opens the sign-in page, clicks "Patient", and is in. The back office is not part of what is public: its accounts sign in with a secret.

Everything below lives in omnisense/omnibase and is active when kernel.environment is demo, and only then. In dev, test and prod none of it is in the container: no route, no listener, no header. What an application adds to run it is listed in Scaffolding a site.

Declaring the accounts

A bundle declares the roles of its trade, the application its own, by implementing Base\Demo\DemoAccountProviderInterface (autoconfigured, tag base.demo_account_provider):

namespace App\Demo;

use Base\Demo\DemoAccount;
use Base\Demo\DemoAccountProviderInterface;

final class DemoAccounts implements DemoAccountProviderInterface
{
    public function getDemoAccounts(): iterable
    {
        yield new DemoAccount(
            identifier: 'client',                      // what it signs in with (User::$userIdentifier)
            label: 'demo.client.label',                // the button: a translation key, or the text itself
            description: 'demo.client.description',    // one sentence on what this role sees
            roles: ['ROLE_USER'],                      // its own roles
            position: 20,                              // the order on the sign-in page
        );
        yield new DemoAccount('docteur', '@health.demo.practitioner.label', '@health.demo.practitioner.description',
            group: 'Praticiens', groupRoles: ['ROLE_PRACTITIONER']);   // a Base\Entity\User\Group and its roles
    }
}

• The password is the identifier unless password: says otherwise, the address <identifier>@example.org unless email: does. A demonstration account is public: that is what it is for.
• Base\Demo\DemoAccountRegistry gathers every declaration. The application's replaces a bundle's for the same identifier; base.demo.exclude: [kine] drops the ones a site has no use for.
• A super-administrator is never a demonstration account. A declaration whose roles reach ROLE_SUPERADMIN - its own, its group's, or through security.role_hierarchy (a ROLE_EDITOR above it) - is refused with a LogicException as soon as the registry is read, in every environment.
• An account that opens the back office is declared, and offered to nobody. One whose roles reach base.demo.admin_roles ([ROLE_ADMIN], through the hierarchy too) is created by the fixtures as the others are - dev and the tests sign in with it - and in demo it is neither in the banner nor on the sign-in page: DemoAccountRegistry::offered() is the list without them. See The back office.

One account for each role of the application, none for the back office

The roles of the application are the constants of its user_role type (App\Enum\UserRole, else Base\Enum\UserRole). Each one below the back office has a demonstration account holding it - its own roles or its group's; ROLE_USER is held by any account. Those that open the back office (base.demo.admin_roles, ROLE_SUPERADMIN, ROLE_EDITOR above it) have none offered. Roles a group gives and the enum does not name (a practice's ROLE_PRACTITIONER) are the bundle's to declare, as they do.

$registry->missingRoles();   // [] when every role has its account; demo:reset warns otherwise

A site's suite asserts it (self::assertSame([], $registry->missingRoles())). The banner names one account, the first offered (position); the others wait on the sign-in page.

In the fixtures

Base\Demo\DemoAccountFactory turns the declarations into rows, so that dev, test and demo have the same accounts and nobody writes them twice:

final class SiteFixtures extends Fixture
{
    public function __construct(private readonly DemoAccountFactory $accounts) {}

    public function load(ObjectManager $manager): void
    {
        $docteur = $this->accounts->account('docteur', $manager);   // the database's, or created from its declaration
        $this->accounts->load($manager);                            // every declared account

        // ...the practice's team, agenda and files, attached to $docteur
        $manager->flush();                                          // the factory flushes nothing
    }
}

An account the database already has is returned as it is: fixtures that create theirs themselves keep them, identifier included. A group is created with groupRoles when the database has none of that name, and left alone otherwise.

On the sign-in page

@Base/demo/_accounts.html.twig prints "Comptes de démonstration": one button for each account offered that exists. omnibase's own sign-in page includes it; an application with its own templates/security/login.html.twig adds the line under its form:

{{ include('@Base/demo/_accounts.html.twig') }}

Each button is a POST form with a CSRF token to security_loginDemo (/login/demo) - never a link: a GET that signs in is followed by a prefetch, a crawler, a link preview. The route is declared for the demo environment only. Base\Controller\DemoController signs in an account that is offered and nothing else: an identifier nobody declared, an account of the back office, or one promoted to it since, is sent back to the sign-in page.

The partial prints nothing outside demo. Its look hangs on .base-demo-accounts (it inherits the page's colours). A button and its sentence stand side by side; in a narrow place - a sign-in card of some twenty rem - the sentence goes under its button, full width (the flex line folds when less than 14rem are left beside the button: no script, no query on the window). To rewrite it, templates/bundles/BaseBundle/demo/_accounts.html.twig. In a template of your own: demo_mode() (true in demo) and demo_accounts() (the list).

The banner

@Base/demo/_banner.html.twig prints "Démonstration — données remises à zéro chaque nuit" (fr, en: the demo translation domain). A layout includes it once, first thing in <body>; omnibase/admin's layout does, so the back office shows it too:

<body>
    {{ include('@Base/demo/_banner.html.twig') }}

Two custom properties set its colours (--demo-banner-bg, --demo-banner-fg); templates/bundles/BaseBundle/demo/_banner.html.twig rewrites it.

The account, on every page

To a visitor who is not signed in, the banner goes on: "Compte de démonstration « Client » : identifiant client, mot de passe client. Se connecter" - the first account offered, what it signs in with, and a link to the sign-in page ("Se connecter ou choisir un autre rôle" when there are several). A site that includes the banner has nothing to add; a site with no account to offer keeps the banner's first sentence alone. Signed in, the sentence is gone.

It is a sentence and a link, not a button: a button that signs in is a form with a CSRF token, a token needs a session, and no public page starts one for a visitor who only reads.

demo:reset

php bin/console demo:reset                # the fixtures, the uploaded files, the caches
php bin/console demo:reset --keep-files   # the database and the caches only

In order: it refuses outside demo (and on what the guard below refuses); takes a lock (symfony/lock, the lock.factory service: two resets never overlap); empties the directories of base.demo.reset.purge; runs doctrine:fixtures:load; creates the declared accounts the fixtures left out; deletes the uploaded files no row names any more (uploader:entities --delete-orphans, unless base.demo.reset.orphans: false); empties every cache pool and Doctrine's second-level cache. Each step is written to the output and to the log; the exit code is not 0 when one failed.

It is written for the cron container. The crontab is the same in every environment, so the line checks the environment itself:

30 3 * * *  [ "$APP_ENV" = demo ] && php /srv/app/bin/console demo:reset >> /srv/app/var/log/cron.demo-reset.log 2>&1

# config/packages/base.yaml
when@demo:
    base:
        demo:
            reset:
                purge:                                   # storages of the application's own
                    - '%kernel.project_dir%/var/storage/documents'

The sessions open at that moment end: the accounts are new rows.

Give the demonstration storages of its own (when@demo in flysystem.yaml: var/storage/demo/uploads...), name that directory in purge, and turn the orphan search off (orphans: false): everything a visitor sent is then in one place that no other environment writes to. The orphan search reads the uploads through public/uploads, a link that points at the storage of whichever environment cleared its cache last - right on a server that runs the demonstration alone, not on a machine that runs dev from the same checkout.

The safeguards

E-mail: refused, not looped back

The two ways were a null transport and the "technical loopback" of dev (every message rewritten to one mailbox). The demonstration takes the first, and enforces it in the bundle rather than leaving it to MAILER_DSN: a visitor signed in as "patient" types any address in a form, and a loopback still delivers - to a mailbox someone then has to empty, and to a real person the day the loopback is misconfigured. A message that is never handed to a transport cannot reach anyone. An application still sets framework.mailer.dsn: 'null://null' under when@demo, so that nothing is even attempted by a library that would bypass Symfony's mailer.

What would have gone is in the log, at the info level of the demo channel (production's fingers_crossed handler keeps it for the context of an error; bin/console ... -vv shows it):

demo.INFO: Demonstration: e-mail not sent. {"to":["patient@example.org"],"subject":"Votre rendez-vous","queued":false}

What a demonstration account cannot change

Every visitor signs in with the same account: whoever changed its password would lock the next one out until the night's reset.

• omnibase's pages refuse with a message (@notifications.demo.locked): the second factor (/settings/2fa, its switches), closing the account (/account-goodbye), a password reset asked for or followed. The settings page says so first. They ask SecurityPolicy::isDemoAccount($user) / canChangeCredentials($user): use the same in a page of your own.
• For every other form - the application's "my account" page, the back office's users - Base\DatabaseSubscriber\DemoAccountLockSubscriber puts the values back before the row is written (and flashes the same message), and answers 403 to a deletion. Only during a request: the fixtures and demo:reset write these accounts from the console.

$policy->isDemoAccount($user);          // a declared account, in the demo environment
$policy->canChangeCredentials($user);   // false for it
$policy->canEnableTwoFactor($user);     // false for it
$policy->needsEnrolment($user);         // false for it, whatever its roles

The back office

A demonstration's password is its identifier: whoever reads "client / client" in the banner can guess "gestion / gestion". Behind the back office are the accounts of the visitors who signed up that day, the settings, the uploads - what one visitor writes there, every other one reads until the night's reset. So it is not public.

In demo, an account whose roles reach base.demo.admin_roles ([ROLE_ADMIN] by default; through security.role_hierarchy too) - declared as a demonstration account or not:

• is not offered: not in the banner, not on the sign-in page, not signed in by /login/demo;
• is the only one the back office opens to: any other account signed in
  • a demonstration account or one a visitor created, whatever its roles give it elsewhere (the kitchen's ROLE_STAFF reading the orders under /admin)
  • gets a 403 on every page of it (/admin, omnibase/admin's routes);
• signs in with base.demo.admin_password - by default %env(default::DEMO_ADMIN_PASSWORD)% - typed in the ordinary sign-in form with its identifier ("gestion"). The stored password is not looked at. Unset or empty, it cannot sign in by any means.

DEMO_ADMIN_PASSWORD is the secret given to whoever is shown the back office - a prospect, for the time of a presentation; changing it closes the door again. It is the deployment's, like the super-administrator's: a real environment variable or .env.demo.local, never .env.demo. Once in, the account is a demonstration account like the others: its credentials do not change, the staff's second factor is not asked of it.

when@demo:
    base:
        demo:
            admin_roles: [ROLE_ADMIN, ROLE_MANAGER]   # another role opens the back office here
            # admin_roles: []                         # ...or none: the back office as public as the rest

A role below these - the kitchen's ROLE_STAFF, a practitioner's group - stays public, with whatever pages of the back office the application opens to it: name it in admin_roles when those pages are not for everyone.

The super-administrator

The fixtures give Glitch Art's account a password everyone knows ("glitchr" / "glitchr"); a demonstration is public. In demo, Base\Subscriber\DemoBackOfficeSubscriber compares what is typed with base.demo.superadmin_password - by default %env(default::DEMO_SUPERADMIN_PASSWORD)% - and never looks at the stored password. Unset or empty, an account whose roles reach ROLE_SUPERADMIN cannot sign in by any means ("This account is not available in the demonstration."). It is not listed on the sign-in page and not signed in by /login/demo either way.

DEMO_SUPERADMIN_PASSWORD is a secret of the deployment: a real environment variable or .env.demo.local (git-ignored) on the demonstration's server. Never .env.demo, which is committed.

What it refuses to start on

Base\Demo\DemoGuard, asked by BaseBundle::boot() - for a page as for a command - throws Base\Exception\DemoRefusedException when:

• debug is on: APP_DEBUG=0 (bin/console --env=demo --no-debug);

• a connection reaches the production database: the application names it, and the guard compares server, port and database name (not the user: the same database under another account is the same database);

  when@demo:
      doctrine:
          dbal:
              connections:
                  default:
                      dbname_suffix: '_demo'            # <database>_demo, as the tests have <database>_test
      base:
          demo:
              production_database: 'mysql://%env(DOCTRINE_DATABASE_HOST)%:%env(DOCTRINE_DATABASE_PORT)%/%env(DOCTRINE_DATABASE)%'
  

• base.demo.production_database is unset: nothing could be compared, and demo:reset empties the database it is given.

One configuration for prod and demo

The demonstration behaves as production does: what a file sets under when@prod is shared, not copied. A YAML anchor does it within a file:

# config/packages/monolog.yaml
when@prod: &prod
    monolog:
        handlers: ...

when@demo: *prod

and a merge key when demo adds something of its own:

# config/packages/doctrine.yaml
when@prod: &prod
    framework:
        cache:
            pools: ...

when@demo:
    <<: *prod
    doctrine:
        dbal:
            connections:
                default:
                    dbname_suffix: '_demo'

(<< merges the top-level keys only: a key demo repeats replaces prod's whole block of that name.) A setting that has to differ in dev and test only is better turned round: the value at the root of the file, overridden under when@dev and when@test - then prod and demo both read the root.

A real environment variable beats every .env* file, and the containers receive .env and .env.local as real variables: .env.demo cannot change a value .env defines. What differs in demo is therefore said in the configuration (when@demo), and .env.demo holds only what .env leaves out (the hosts, as .env.prod does).

Reference

base:
    demo:
        production_database: ~            # DSN of production's database; required in demo
        superadmin_password: '%env(default::DEMO_SUPERADMIN_PASSWORD)%'
        admin_roles: [ROLE_ADMIN]         # the roles that open the back office: not offered, signed in by the secret
        admin_password: '%env(default::DEMO_ADMIN_PASSWORD)%'
        exclude: []                       # declared identifiers this site leaves out
        reset:
            purge: []                     # directories demo:reset empties before the fixtures
            groups: []                    # fixture groups it loads (--group); none: every fixture
            orphans: true                 # uploader:entities --delete-orphans after them

Forms

omnibase's form theme (templates/form/form_div_layout.html.twig, added to twig.form_themes by the bundle) renders every form: the form2 blocks, the label strip, the custom field types.

Labels, help and placeholders are translation keys

Texts are translated by Base\Service\Translator. A key may name its domain (@mailbox.form.subject), or be looked up in the field's translation_domain.

Every field has the domain fields by default (Base\Form\Extension\FormTypeExtension), where omnibase's own field types keep their words. A form type that declares its own domain is followed by its fields:

public function configureOptions(OptionsResolver $resolver): void
{
    $resolver->setDefaults(['translation_domain' => 'mailbox']);
}

public function buildForm(FormBuilderInterface $builder, array $options): void
{
    $builder->add('subject', TextType::class, [
        'label' => 'form.subject',                         // mailbox.form.subject
        'help' => 'form.subject_help',
        'attr' => ['placeholder' => 'form.subject_placeholder'],
    ]);
}

The rule, applied when the view is finished (FormTypeExtension::inheritTranslationDomain()): when none of a field's label, help and placeholder exists in the field's own domain and one of them exists in the domain of a form above it, the field is rendered in that domain. Otherwise nothing changes: a field whose texts are in fields stays there, a key that names its domain is translated in it, and 'translation_domain' => false prints the texts as written.

(A field used to ignore its form's domain: the key was looked up in fields, found nothing, and the label was printed empty. The bundles named the domain in every key to go around it; they no longer need to.)

A PHP enum in a select

Base\Field\Type\SelectType bound to a property that holds a PHP enum finds its choices by itself - the cases - and hands the case back to the record:

$builder->add('state', SelectType::class);                                   // Doctrine enumType:, or a property typed with the enum
$builder->add('states', SelectType::class, ['class' => CommentState::class, 'multiple' => true]);

The select holds a case by its backed value (its name when the enum is not backed, Base\Form\Common\NativeEnum::id()). A case is labelled, in this order: by itself when the enum implements Symfony's TranslatableInterface; by the key <short class name in snake case>.<value> of the enums domain (comment_state.pending); by its name made readable. A value that names no case is an invalid choice, and the record keeps what it had.

A field that gives choices (or a choice_loader) keeps them as they are: the enum is not guessed over them, and ['Label' => 'value'] shows the label (translated when it is a key such as @agenda.role.soloist).

ClassMetadataManipulator::getFields() - what AssociationType builds an embedded form from - maps such a column to a SelectType as well; it used to be a TextType, which cannot print a case.

An entity in a select

SelectType with an entity class (or bound to a Doctrine association) is fed by the autocompletion and loads what was chosen from the class's repository: cacheById() on omnibase's repositories, find() / findBy() on a plain Doctrine one.

AssociationType embeds the related record's own form, always. The back office decides, for an AssociationField, between that form and a picker: see omnibase/admin's docs/crud-fields.md.

A select works before its script does

SelectType is drawn by select2, but the <select> the server prints is a whole one: on a page whose script did not run - blocked, failed, not loaded yet - it can be read, changed and sent.

• Its options. The choices of a static list or of an enum, groups as <optgroup>, with the labels select2 shows; for an autocompleted list, the records already chosen. select2 empties the select before filling it from its own data, as it always did: nothing is listed twice.
• Its selection. The record's value is the selected option - also in the lists that printed their options already (a choice_loader: CurrencyType), where none was selected and the browser sent the first of the list in place of the record's currency.
• An empty first option in a select of one value, carrying the placeholder: without it the browser picks the first choice for a record that has none. It is the option select2 itself asks for to show a placeholder.

(The select was printed with no option at all and filled by select2 alone: without the script a product's availability arrived null.)

required is checked by the server

A required SelectType sent empty is an error of the form - "This value should not be blank.", in the visitor's language (validators domain) - on the field itself, where its row prints it. The browser's required attribute was the only check, and the back office's forms are novalidate.

The empty value is not written into the record, which keeps what it had: the field fails as a transformation does (it is not synchronized), so a setter that takes no null - setStatus(PublicationStatus $status) - is not called with one. That call answered 500 ("Expected argument of type ..., null given") in place of the form's error.

• required is what the field says, true unless said otherwise ('required' => false, ->setRequired(false) on a CRUD field): a select on a nullable property that may stay empty has to say so.
• A list of several may be empty, as before, unless 'required_when_multiple' => true.
• A disabled field is not asked.

The field's errors no longer go up to the form (error_bubbling is false, as for Symfony's own compound choice and date fields): a constraint of the property is printed beside the select too, not at the top of the form.

The neutral form layer (plan "omnibase agnostic", step F5b)

Every site has forms, and the admin builds its own from the Fields (Marco's answer 4): forms are not Symfony's alone. The core describes a form without a form library; each host renders and processes it.

Field descriptors name a kind

A field descriptor (TextField::new('title'), FieldDescriptor) names a kind (Base\Field\Kind: text, textarea, email, password, integer, number, money, choice, country, association, date, datetime, file, image, collection, boolean, editor...), never a Symfony form type class. Its options are plain data (getOptions(), getOption('attr.maxlength')), its constraints plain objects (addConstraint()) that the host's Omnibridge\Contract\Validation reads, its label and help translatable keys.

Base\Field\Kinds maps a kind to a host's own name for it: Symfony's form type for getFormType() (the map SymfonyKinds, read by name: the same class each descriptor named before), a theme's block for another host. A bundle or an application registers its own kinds:

Kinds::register('symfony', ['signature' => SignatureType::class]);

setFormType() stays, as the escape hatch of a Symfony-only field: a type a kind maps to sets that kind too (a TextField given ChoiceType is a choice), another keeps the kind set, or is Kind::CUSTOM.

A form: FormDefinition

use Base\Form\Definition\FormDefinition;

$form = FormDefinition::new('comment')
    ->add(TextareaField::new('content', 'comment.content')->setRequired(true)->addConstraint(new NotBlank()))
    ->add(BooleanField::new('notify'), 'options')
    ->addAction('submit', 'comment.submit')
    ->setDataClass(Comment::class);

// or the fields a CRUD page shows
$form = FormDefinition::fromFields('crud_form', $controller->configureFields('edit'), 'edit');

A definition holds its fields by name, their groups, its actions (the buttons; the one clicked is the submitted intent), its method and target, the intent of its token (its name by default), the data class, the translation domain (the host's default when null) and, as an escape hatch, options only one host reads (setHostOptions([...], 'symfony')).

What a site's form needs beyond fields, each read by every host:

• FormDefinition::field('email', Kind::EMAIL): a bare field, none of what a descriptor class adds for the back office;
• setFormTypeOption('data', true): a value fixed whatever the data; 'choices' => $repository->subscribable(...): a callable, asked when read; a list of records as choices (each says its own name, its id the value);
• addRewrite(fn (array $sent): array => ...): what was sent rewritten before it is read (Symfony's PRE_SUBMIT);
• Kind::REPEATED: one value typed twice, option type the kind of the two inputs, the mismatch said under the first;
• addAction('submit', null, Kind::BUTTON, [], ['confirmation' => true, 'type' => 'submit']): ButtonType's modal;
• setGuard(['action' => 'signup']): FormGuard's trap, stamp, lists, under Symfony by the option guard, elsewhere by FormProcessor;
• setValidationGroups(['new']), setValidationEntity(User::class, ['username']): the record's class-level rules on the form's values, its refusals the form's own but for the fields named. FormSubmission::isTaken('email') tells a page which.

A model's or entity's rules stay on one line: Omnibridge\Validation\AttributeConstraints reads symfony/validator's attributes by name, their class never loaded, as the kept constraints. Unique asks Base\Form\Definition\UniqueLookup, over Repositories, on both hosts.

Binding, view, processing

• FormBinder turns what is sent into the data (an array, an entity, a DTO) and the data into the values shown, by kind: a trimmed string (a password untrimmed), '' as null or the empty data, an integer, a number, a date (input: datetime, datetime_immutable, string), a choice among the field's choices, an association by its id (UnitOfWork::reference()), a file as the host gives it, a missing checkbox as false. A value it cannot read is a violation of its field with Symfony's own message ("Please enter an integer.") and leaves the data untouched; a disabled field keeps the data's value; the data is written only where its value changes (Properties: getters, setters, public properties, "." paths, without property-info). Transformers are plain callables: withTransformer($kind, $reverse, $transform), or a field's custom options FormBinder::OPTION_REVERSE / OPTION_TRANSFORM.
• FormView is a plain tree a renderer reads: each view's vars (name, full_name, id, kind, type, value, label, help, errors, attr, required, disabled, choices as a list of value/label, multiple, checked; the root's method, action, valid) named as Symfony's FormView names them, its children by name, the token as the hidden child _token. toArray() (and json_encode()) gives the props of a React page.
• FormProcessor handles a request's part: bind, check the token (Omnibridge\Contract\Tokens, the definition's intent), validate (Omnibridge\Contract\Validation: the data against what its class declares, each field's value against the field's constraints), then keep the data (Omnibridge\Persistence\UnitOfWork) when asked and valid. Each contract is optional. It is in Base\Services::definitions(), so every host's container gives it.

$submission = $processor->handle($form, $request->request->all('comment') + $request->files->all('comment'), $comment, persist: true);
if ($submission->isValid()) {
    return redirect(...);
}

return view('comment', ['form' => $submission->createView()]);   // the values sent, their errors, a token

What a host does once a form holds (step F5c)

• An empty string a definition gives as its empty data (setEmptyData('')) stays a string, as Symfony's TextType keeps it, whether the field came empty or not at all (Laravel sends an empty field as null).
• What the binder could not read ("The values do not match.") is said in the page's language: the validators domain, when the processor has Translations.
• A record's uniqueness declared without its class (#[UniqueEntity(fields: ['email'])] on the entity) is looked up among the records of the form's validation entity.
• A refusal the code that keeps the data gives (a spam, a record not found) is added to the submission: $submission->withError($message, $field), a new submission, as Symfony's addError().
• A record the form has just written into is held to its class's rules before it is kept: RecordRules::violations($validation, $record, $groups) - its uniqueness above all, the record itself not counted as taken. omnibase's profile editor does it on both hosts: a name another account has is said under its field, the account read again as it is stored (it answered 500 and signed the session out).
• A sign-up once its form holds is Base\Auth\Registration::register() on every host (approved, its password, named after its address when its class has a username left empty, kept); the host signs it in.
• A rule of the data on a field with error_bubbling is the form's error, as a rule of the field's own.
• The sign-up's terms of use are checked by the server (agreeTerms, user.agree_terms), in the default group and the sign-up's new.

The Symfony adapter (omnibridge/symfony)

The Symfony half of the form layer lives in Omnibridge\Symfony\Omnibase\ since F5b, each class under its former path: Field\Type\*, Form\Type\*, Form\Extension\*, Form\Transformer\*, Form\Traits\*, Form\Common\{AbstractType, FormTypeInterface}, Form\{FormFactory, FormProxy, FormProcessor} and their interfaces (78 classes). Their Base\ names keep working until 6.0: src/Resources/former-names.symfony.php. Sites keep createForm(), their themes and Base\Field\Type\X::class everywhere. Because ::class of a former name is a plain string while Symfony's registry asks a type's extensions by its declared name, FormerFormTypesPass gives the type locator both names and files the extensions under the declared one. A PreloadedExtension (a hand-built factory, in a test) knows the declared name only: ask it by the new one. App\Form\ stubs and aliases read both folders (FormStub, BaseBundle::symfonyFormDir()).

Omnibridge\Symfony\Omnibase\Form\DefinitionForms makes a Symfony form of a definition - types by kind, options as the admin maps a CRUD field's, kept constraints translated (SymfonyConstraints), actions as buttons, getHostOptions() winning - and Omnibridge\Contract\Validation is SymfonyValidation over symfony/validator. A site's form stays a type, what Symfony asks for: Omnibridge\Symfony\Omnibase\Form\DefinitionType builds it from a definition (definition(array $options)), so FormProxy::createProcessor(), its name and its block prefix do not change. The generic renderers - the Twig theme (omnibridge/twig), the Blade theme (omnibridge/laravel), React - read FormView. The whole layer loads under bare --strict (BareTest::testTheFormLayerWorksWithoutAFormLibrary).

Every kind on every host: behaviours, coverage, conformance (step F5d)

What a rich field does - a date picker, a slug made from another field, a switch that asks first, a select2 searched remotely, a colour, a localized number, a password typed twice - lived only in its Symfony type, and a host that did not know a kind drew a plain input in silence. Three pieces close it.

Behaviours. omnisense/omnibridge's Omnibridge\Form\FieldBehaviour is the contract one behaviour answers whatever host draws it: options() (the given ones over its defaults, normalized), vars() (what its widget reads, plain data: datetimepicker, select2, data attributes under attr), transform() and reverse() (the value shown, the value read back; \UnexpectedValueException for a value it cannot read), assets() (the script's entry, the prefix of the attributes its controller reads, FieldAssets), endpoints() (the host's routes it calls, Endpoint: a select's remote search). The core's Base\Field\Behaviour\* hold the logic the Symfony types held, and Behaviours::of($kind) gives them:

The Symfony types read them (DateTimePickerType, SlugType, BooleanType, ColorType, ColorPickerType, NumberType, SelectType's select2 settings): the 13 forms and the back office's pages draw the same markup. The neutral FormBinder reads through a behaviour first (the field's options completed with its defaults), then the kind's generic rule; the neutral FormView gives a rich field its widget, webpack_entry, settings and endpoints (the address of each route on this host, null where it has none). A select2 is its form's choice part on both hosts (name[value][choice]), as SelectType names it. A field whose host type is named (setFormType()) has no behaviour: its type decides.

Coverage. Each host declares every kind, implemented or Coverage::unsupported('why') (omnisense/omnibridge's Omnibridge\Form\Coverage): Symfony's SymfonyKinds::COVERAGE, Laravel's LaravelKinds::COVERAGE, read by Kinds::coverage($host) (completed by Kinds::declare()); Kinds::faults($host) names a kind left undeclared, an application's own kinds included. A kind a host declares unsupported is refused aloud when drawn (Omnibridge\Form\UnsupportedKind): DefinitionForms for Symfony (html), omnibridge/laravel's FormRenderer for Laravel, which also refuses a select whose remote search route it does not have (an application without omnibase's media, through which the search's payload goes). A field that names its host type (setFormType()) and keeps a kind is drawn from its generic view by the generic renderers (explicit in its vars); one with no kind at all (custom) is refused there. lesringostars-react declares its own coverage (src/screens/kinds.json) against src/Resources/field-kinds.json, the core's list of kinds as JSON.

The record's mapping completes what a field leaves out, as the Symfony types guess it from Doctrine (Base\Field\Behaviour\Guess, on the unit of work's entity shapes, aliases resolved): a select's class (an association's target, an enumeration column's class) and whether it holds several, its sorting (#[OrderColumn]), a slug's required (its column not nullable). A select2's entries are omnibase's Autocomplete::resolve()'s (an enumeration's word and icon) where the host gives omnibase's translator; a country's carries its flag.

The remote search. A select of records (an association picked, class a record's) and an icon picker search their entries on the host: Base\Field\Search\RemoteSearch, the same on every host, at the routes of RemoteSearch::ROUTES - ux_autocomplete (/ux/autocomplete/{data}: a class's records through its repository's cacheByInstanceOf(), paged by the Paginator, named by Autocomplete, kept when their text holds the term; an enumeration's values) and ux_autocomplete_icons (/ux/autocomplete/{provider}/{pageSize}/{data}: an icon adapter's icons, through Base\Service\Icons). data is RemoteSearch::data(): the class, the fields, the filters (RemoteSearch::filters()), the case, whether the entries are HTML and show faces, and the visitor's token of intent select2 (the Tokens contract), obfuscated in its short form; the search refuses another token, an unknown payload, a method the environment does not take (GET and POST in debug, POST otherwise: autocomplete_type). Symfony's AutocompleteController and omnibridge/laravel's SearchController hand it the request's method, query and body and send its Answer as JSON. SelectType makes its data with it; the neutral FormView gives the search endpoint its data and starts select2 with the entries chosen (the records found by their ids, an icon named by its adapter's list), so both hosts draw the same picker.

Uploads. A file field (file, image, avatar, audio, video) is Base\Field\Behaviour\Upload on every host: the defaults and normalizers of omnibase's FileType and its children, and what their blocks show of the record's files - the stored files' names (the hidden input [file]), their public addresses, thumbnails and previews, the download links, the largest size and the types accepted (the record's #[Uploader] and #[File]), an image's thumbnail, modal and cropper. The file to send is [raw] (or [url] with allow_url); a field of several files with a dropzone sends each file as it is dropped to Base\Field\Upload\Dropzone's ux_dropzone, which keeps it under a uuid in the cache folder's dropzone/ until the form is sent (ux_dropzone_preview shows it again, ux_dropzone_delete removes it; its payload carries the visitor's token of intent dropzone). What is sent back is read as FileType reads it (Upload::reverse()): the file sent, else the one fetched, else what [file] names - the dropzone's kept files, or a stored file's name -; a compound sent empty removes the file, a field not sent keeps it. The record's #[Uploader] stores the file when the record is flushed. Symfony's types and its DropzoneController ask the behaviour and the service; the neutral FormView gives the behaviour the record it edits.

The file sent is refused when the form is validated, as FileType's File constraint on [raw] refuses it, on every host (Upload::refusal(), which the neutral FormBinder applies): a type its mime_types do not match (file.mime_type), else a size over its ceiling - PHP's upload limit, narrowed by its class' #[Uploader] and #[File] and by max_size - (file.max_size); the field's error is the constraint's message (the validators catalogue), the data is left untouched, the record's #[Uploader] is never reached. Base\Validator\Constraints\File reads an integer as bytes: FileType's ceiling, which it read as bits until then (32 MB refused a file over 4 MB).

Records made from uploads. An association_file field (a gallery's photos, a photo's picture: AssociationFileField) is Base\Field\Behaviour\AssociationFile on every host: a compound holding one upload field (file, image or avatar, by its form_type) named by the first part of entity_file, the path from a related record to its file (image.source). The upload field shows the related records' files (files()) and carries each stored file's name by its record's id (entries(), data-entry-id); several records when the association is to-many (the entity's shape), in order where it is kept so. What is sent is made into the related records (records()): a file sent (or kept by the dropzone) a new record - hydrated, then given entity_data, a callable or values, else its file -, a stored file's name its record kept, a name left out its record left; the neutral FormBinder writes them into the record (bind(): a to-many collection replaced, an inverse side's records told their owner, from the shape), Symfony's AssociationFileType into its PersistentCollection as before. The admin's edit link of a record (href) stays the Symfony back office's.

Editors. A text written in Editor.js (editor) or in Quill (wysiwyg) is kept in a hidden input on every host, its script's element beside it. Base\Field\Behaviour\Wysiwyg gives Quill's settings (wysiwyg: theme, toolbar, placeholder, height); Base\Field\Behaviour\Editor gives Editor.js's (editor: the placeholder and, when collab_autosave or collab_live is asked and the form's record is stored, its field's room - token, version hash, the account signed in; collab_live only where a relay is configured), the value with each picture's address made from its stored origin, and the five addresses of the editor's routes (uploadByFile, uploadByUrl, endpointByUser, endpointByThread, endpointByKeyword); a document sent without a block is read back as no text. Both widgets' ids have their dashes made underscores (a translation's fr-FR part). The routes are Base\Field\Editor\EditorJs's (ROUTES, the ux_editorjs_* names): the mentions with the editor's token (editorjs), five by page; a picture sent or fetched, stored in the editor's storage (base.twig.editor.storage); the relay's ticket and one field's autosave with its room's own token (a stale version refused, 409). Symfony's EditorController and omnibridge/laravel's answer them through it; the neutral FormView gives the behaviour the record and the field's name (editor_record, editor_field).

Embedded forms, lists and attributes. A related record's form (association, an AssociationField that embeds) is drawn on every host as AssociationType builds it: one record, its fields and its _index; several (a to-many association), the collection _collection whose entries, by their index in the association, are each one record's form, with the prototype of a new one where entries are added (__prototype__) and the window of a capped collection (max_entries, entry_offset; the indexes drawn sent back as _rendered). Base\Field\Behaviour\Association holds what the type decides (several records are never required, and nothing inside them; entries added and deleted only inside a group; the collection's and an entry's options) and its fields (RecordFields, the field's fields, autoload, excluded_fields), the association read through its alias (#[Alias]: a comment's replies); the neutral FormBinder binds each entry sent into its record, a new one from the prototype told its owner, one not sent removed where the field deletes (an entry's own collection of records is not written from it, as AssociationType leaves it). A list (collection, array) is Base\Field\Behaviour\Collection: CollectionType's and ArrayType's defaults (a pattern's {n} counted as a fixed length that neither adds nor deletes), the window, the empty markup, what is sent read as the list kept (an associative array's {key, value} entries as key => value). A record's attributes (attribute) are Base\Field\Behaviour\Attribute: the attribute's class and its adapters', the select of adapters (searched remotely, filter narrowing them), each attribute's part named by its adapter's code and id; bound, an attribute kept for each adapter still chosen, a new one for an adapter newly chosen. A translated attribute's value (its intl part, a TranslationType of several records) is drawn by Symfony's forms only: omnibridge/laravel refuses such a field aloud once it holds one. Symfony's AssociationType, CollectionType, ArrayType and AttributeType ask these helpers; a list of records written into the collection a record holds is written in place by the neutral binder (the records no longer chosen out, the new ones in), as Symfony's forms do through adders.

Translations. A translations field (translation) is one part per language, each the translation entity's fields, on every host: Base\Field\Behaviour\Translation holds what TranslationType decides (the languages drawn - every offered one, or for single_locale the default one, the record's one language when it has exactly one -; which part is required - the default and required_locales; locale_options per language; a callable required), and Symfony's type asks it. The translation entity's fields are Base\Field\Behaviour\RecordFields::of(), what ClassMetadataManipulator::getFields() lists from Doctrine read from the entity's shape: the fields named first, then the other columns unless autoload is off, id, translatable, locale and excluded_fields left out, each with the kind its column says (string a text, text a textarea, json or array a select of free tags, integer a number, datetime a datetime picker, an enumeration a select of its values) or the one its form_type names. The neutral FormView gives such a field a part per language (form[translations][fr-FR][title], ids form_translations_fr-FR_title), the record's values in each, and TranslationType's vars (nonempty_locales, compatible_locale...); FormBinder writes what is sent into the record's translations (translate()), a language left empty is not kept. omnibridge/laravel draws it as translatable_widget does - a tab per language -, and refuses it aloud when one of its fields is a kind it does not draw.

Conformance. Base\Field\Conformance\Suite runs Samples::all() (one sample per kind of Kind::all(), with Symfony's values: the reference) on a Host - its name, render(), submit(): every kind declared, each implemented one drawn under its name, its value shown, what is sent bound to the same value, a value it cannot read refused; each unsupported one refused. A kind added to Kind without a sample fails Samples::all(); without a host's word, the host's suite. The hosts' suites: tests/Field/SymfonyConformanceTest (the harness, Omnibridge\Symfony\Omnibase\Form\Conformance\SymfonyHost), omnibridge/laravel's tests/FieldConformanceTest (Omnibridge\Laravel\Form\Conformance\LaravelHost), and an application's own.

Sealed fields (#[Vault])

Base\Database\Attribute\Vault seals the fields of an entity before they reach the database, with libsodium (a sealed box, through Symfony's SodiumMarshaller), and opens them when the entity is loaded. omnibase uses it for the settings typed on the back office's "API keys" page (Base\Entity\Layout\SettingIntl::$value); an application uses it for its own secrets:

use Base\Database\Attribute\Vault;
use Base\Database\Entity\Extension\VaultTrait;

#[ORM\Entity]
#[Vault(fields: ['apiKey'])]
class AssistantKey
{
    use VaultTrait;          // the `vault` column: null (not secured) or the environment whose key sealed the row

    #[ORM\Column(type: 'text', nullable: true)]
    protected ?string $apiKey = null;
}

$key->setSecure(true);       // sealed from the next flush on, with the running environment's key

A row is sealed when its vault column names an environment (setSecure(true), SettingBag::secure($path)); a row whose vault is null is stored as it is.

The key pair

The key is the one of Symfony's secrets vault for the environment: config/secrets/<env>/<env>.decrypt.private.php (and its public half, <env>.encrypt.public.php). One command creates both:

php bin/console secrets:generate-keys                 # the running environment (dev)
php bin/console secrets:generate-keys --env=test      # the test suite seals too
php bin/console secrets:generate-keys --env=prod

• dev and test: commit both files, as Symfony's documentation says for these environments (they protect nothing that is not in the repository already).

• prod: commit prod.encrypt.public.php only. The private key (prod.decrypt.private.php) goes to the server by hand, or as the SYMFONY_DECRYPTION_SECRET environment variable:

  php -r 'echo base64_encode(require "config/secrets/prod/prod.decrypt.private.php");'
  

  #[Vault] reads the file first, then that variable. Losing the private key loses every sealed value: keep a copy where the backups are not.

• In Docker, the web container mounts the project read-only: it cannot write config/secrets/. Run the command where the project is writable - the one-shot composer service - see Scaffolding a site:

  docker compose -f docker-compose.yml -f docker-compose.setup.yml run --rm --entrypoint "" composer \
      php bin/console secrets:generate-keys
  

A row remembers the environment that sealed it: a database copied from production to a development machine keeps its sealed values unreadable there (they come back as the sealed text), which is the point.

Without the key pair: refused, not stored in clear

When a secured field is about to be written and the vault has no key pair, the flush fails with Base\Exception\VaultKeyNotFoundException:

The "dev" vault has no key pair (…/config/secrets/dev/dev.decrypt.private.php): a secured value would be stored in clear, so it is refused. Generate the pair with "php bin/console secrets:generate-keys --env=dev" […]

The message names the vault, the file and the command, never the value. omnibase/admin's "API keys" page checks first (Vault::canSeal()) and shows the same explanation instead of saving.

Until omnibase 3.x of 2026-10-05 the value was written unsealed, without a word - a site without keys believed its API keys were encrypted. A site that wants that behaviour back says so:

# config/packages/base.yaml
base:
    vault:
        allow_plaintext: true      # no key pair: secured fields are stored in clear

Reading never fails: a value stored in clear before the keys existed is read as it is, and sealed at its next save.

What an existing site does

1. Generate the pairs (dev, test, prod) as above.
2. Open the "API keys" page and save it once: the rows stored in clear are sealed. Or, in a migration or a command: $settingBag->secure('api.stripe.secret') for each path.
3. Nothing to migrate in the schema: the vault column and the fields keep their types.

Errors and refusals

An application hands its errors to omnibase:

# config/packages/framework.yaml
framework:
    error_controller: Base\Controller\ErrorController::Main

• In debug (dev, and the test environment): Symfony's debug page (ErrorController::Rescue()), under the error's own status.
• Otherwise: exception.html.twig, or @Admin/error.html.twig for a path under /admin when omnibase/admin is installed; the kernel gives the response the error's status. exception.html.twig extends the site's layout3.html.twig, or its layout1.html.twig when it has no layout3 (until 2026-10-06 a site without layout3 could not render the page: every unknown address answered 500 in prod).

A test asserts the real status: assertResponseStatusCodeSame(403) for a refusal, 422 for a validation failure.

(The debug page used to answer 404 whatever the error, so in dev and in the tests every refusal and every validation failure of a signed-in user read as "not found". Production was right. Tests that expected 404 for a refusal expect 403 now.)

File links

The debug page's and the profiler's links open the file on the developer's machine when the site runs in a container: APP_PATH (the project's path on the host, which a site's Makefile writes in .env.local) is mapped from kernel.project_dir with Symfony's own format, vscode://file/%f:%l&/srv/app/>/Users/me/site/ (omnibridge/symfony's Omnibridge\Symfony\FileLinks, formerly Base\Bridge\Symfony\FileLinks). debug.file_link_formatter is decorated with Symfony's FileLinkFormatter on that format (the HTML error renderer and the profiler receive it), and SYMFONY_IDE is set to it when Base\BaseBundle is constructed, for the page Symfony's ErrorHandler renders by itself before a request is handled (a container that does not compile). A site's own framework.ide or SYMFONY_IDE is kept; one that already maps (&...>) too; with none, VS Code's format. omnibase's former syntax, which the sites' framework.ide writes - "vscode://file/%%f[%%b:%env(APP_PATH)%]:%%l", %b read as the path in brackets - is read as Symfony's mapping.

Until 4.0, Base\Inspector\HtmlErrorRenderer and FileLinkFormatter did this by extending Symfony's classes - the formatter is @final - and glitchr/base-plugin patched symfony/error-handler for it (@final removed, private made protected, the ErrorHandler's new HtmlErrorRenderer replaced). Gone: symfony/error-handler is installed as published.

The 404 that are meant

Two refusals are answered 404 on purpose, so as not to tell that the place exists:

• While access is restricted (the base.settings.access_restriction.* settings: a site not open yet, or under maintenance), the back office and the profiler answer 404 to whoever is not granted BACKEND (Base\Subscriber\SecuritySubscriber).
• The profiler outside debug answers 404 (Base\Subscriber\ProfilerSubscriber).

An application that wants a record to stay unknown to those who may not see it (a private order, another customer's file) throws createNotFoundException() itself rather than denying access: that is its choice, record by record, not something omnibase does for it.

Deployment

This is the base deployment page. An application that deploys differently should override it by creating docs/30-operations/deployment.md.

Generic flow

1. Run the test suite.
2. Build assets.
3. Run migrations.
4. Warm the cache.

Cache

Warm the cache before switching traffic. Several warmers touch the database, so a cold cache on the first request after a deploy is both slow and risky.

omnibase's cache:clear checks the PHP configuration, the disk, webpack's build and the technical recipient before Symfony's clear, holds a lock (a second cache:clear started meanwhile exits without clearing), and on an installation's first clear runs a second one in a process of its own (base.autoclear). See Console commands.

Before switching traffic

• base.notifier.technical_loopback is true by default: every e-mail goes to the technical recipient. Production sets it to false.
• base.site.index names the home page's route, base.uploader.storage and base.twig.editor.storage the storages of the uploads (Configuration reference).

Commands to schedule

Backups

timemachine:snapshot:backup builds one archive of the application (its code, its uploaded data and a database dump) and transfers it to one or more configured storages.

The TimeMachine needs glitchr/backup-manager, which the core suggests and no longer requires (since 2026-11-01): Base\Service\TimeMachine extends its Manager. A site that backs up requires it at its root:

composer require glitchr/backup-manager:4.0.*-dev

Without it, neither the time_machine service nor the timemachine:* commands are registered, and base.time_machine is read by nothing.

php bin/console timemachine:snapshot:backup sftp.glitchr --batch --database default

The positional argument names the destination storages, not the sources - every storage listed in config/packages/flysystem.yaml may be used, and the snapshot is written to each of them in turn.

What ends up in the archive

The tarball deliberately leaves out anything a deployment can rebuild by itself. On a typical application vendor/ and node_modules/ alone account for roughly three quarters of the tree, and none of it is data you could not reproduce with composer install and yarn.

The default exclusion list is Base\Service\TimeMachineInterface::DEFAULT_EXCLUDES (TimeMachine::DEFAULT_EXCLUDES as well, its implementation's; the interface loads without glitchr/backup-manager):

./vendor  ./node_modules  ./var/cache  ./var/log  ./var/coverage  ./var/phpunit  ./.git

Override it per application when the defaults do not fit:

# config/packages/base.yaml
base:
    time_machine:
        excludes:
            - ./vendor
            - ./node_modules
            - ./var/cache
            - ./public/build

Restoring a snapshot built with these defaults therefore needs composer install (and a front-end build) before the application boots. Everything that is not reproducible - uploads, the database dump - is always archived.

Where the archive is staged

The snapshot is assembled on local disk before being transferred, by default under the kernel cache directory. On a host where the application shares a filesystem with everything else, a large snapshot can therefore fill the disk the application itself is running on.

Point the staging directory at another volume when that is a risk:

base:
    time_machine:
        snapshot_dir: /mnt/storage/snapshots

Before building anything, the command measures the source (with the exclusions applied) and refuses to start when the target filesystem cannot hold roughly twice that - the tarball and its compressed copy exist side by side while compressing:

Not enough free space to build the snapshot in "/srv/app/var/cache/prod":
~2.6GB needed (source ~1.2GB x2.2), only 900MB available.

Retention

Snapshots older than time_machine.time_limit (default +30 days) are deleted from the destination storage at the start of every run, and max_cycle bounds how many same-day cycles are kept. A destination is therefore not an archive of record: it is a rotating window. Keep anything that must outlive that window somewhere the command does not prune.

The Docker harness

docker/ builds this checkout into one Symfony application with every omnibase/* plugin (admin, marketplace, forge, forum, mailbox, docs), paying through omnisense/omnitrade, shipping through omnisense/omnibus and signing through omnisense/omnisign (a DocuSeal gateway, its recorded answers in the tests), on SQLite. It is where the bundles' suites run: there is no PHP on the host.

cd docker
docker compose -f compose.yml -f compose.checkouts.yml run --rm omnibase test              # omnisense/omnibase's suite
docker compose -f compose.yml -f compose.checkouts.yml run --rm omnibase test admin        # a plugin's: admin, marketplace, forge...
docker compose -f compose.yml -f compose.checkouts.yml run --rm omnibase test forge --filter License
docker compose -f compose.yml -f compose.checkouts.yml run --rm omnibase check             # container and templates linted
docker compose -f compose.yml -f compose.checkouts.yml run --rm omnibase bare              # the Foundation loaded without the framework
docker compose -f compose.yml -f compose.checkouts.yml up                                  # the demo, http://localhost:8000/

compose.checkouts.yml mounts the checkouts beside this one (../admin, ../marketplace...) over the installed packages: what is edited is what runs, no rebuild needed. Without it, the plugins are the Packagist ones.

omnibase/blog, omnibase/classroom, omnibase/agenda, omnibase/scholar, omnibase/press and omnibase/consulting are not installed by the image; the overlay mounts their checkouts too (test blog, test classroom, test agenda, test scholar, test press, test consulting), and omnisense/omnischolar's (OMNISCHOLAR, ../../../omnischolar by default), whose classes the scholar's tests' bootstrap registers. Their tests' bootstrap registers their classes (and the omnibase/* bundles they require, read beside them), and the demo's config/bundles.php and config/routes/plugins.php - mounted as checked out, with demo.sh - register their bundles and their pages for their own suites only: the other suites' map the same entities as before.

What test sets up

• The test environment. APP_ENV=test; PHPUnit starts from tests/harness.php, which loads .env then .env.test (as an application's own tests/bootstrap.php does), then the suite's own bootstrap (it registers the suite's test namespace). docker/app/.env.test holds test values for every variable the bundles' configuration reads: KERNEL_CLASS, DATABASE_URL, DEFAULT_URI, CORS_ALLOW_ORIGIN, GOOGLE_RECAPTCHA_SITE_KEY / GOOGLE_RECAPTCHA_SECRET (Google's public test keys), MAILER_DSN, MAILER_CONTACT, MESSENGER_TRANSPORT_DSN, the Stripe keys (empty). A suite that dies before its first test on a missing variable wants a line there.
• A fresh database. var/test.db (SQLite) is deleted, and its schema created from every mapped entity, at each run; the test container cache (var/cache/test) too - first, before the bundles' public files are linked: the previous suite's container may list bundles this one has not.

The suites that need a host application (KernelTestCase: core's analytics, admin's widgets, the forge's entities) run here as they do inside an application. Those that need rows to look at skip when the fresh database has none.

The Foundation: bare

tests/Foundation.php lists the classes of the core that load without the framework, sorted. tests/BareTest.php, part of the suite, runs docker/bin/bare in a PHP process of its own: Composer's autoloader alone - no kernel, no container, no bundle booted - then each class of the list, and every class, interface, trait and file PHP loaded on the way is checked. None may be the framework's: the Symfony bundles (FrameworkBundle, DoctrineBundle, TwigBundle, SecurityBundle, every *-bundle) and bridges, dependency-injection, config, http-kernel, http-foundation, routing, security-*, form, console, ux-*, API Platform, HWI, Scheb, Webauthn's bundle, Nelmio (a namespace segment ending in Bundle is a bundle's, except symfony/intl's resource readers, Symfony\Component\Intl\Data\Bundle\). The standalone Symfony components (string, uid, intl, translation, validator, serializer, mime, mailer, notifier, cache, workflow, event-dispatcher, http-client, the contracts...), Doctrine (storage) and Twig (the view) are allowed. A failure names the framework's class or file, the class of the list that loaded it and the class that asked for it. A second case loads Base\BaseBundle and Base\Repository\UserRepository the same way and checks the report names the framework (HttpKernel\Bundle\Bundle, asked by AbstractBaseBundle; Security's UserProviderInterface, implemented by the users' repository): the check is not blind. A third loads a repository (ThreadRepository): doctrine/orm's EntityRepository, nothing of the framework (plan "omnibase agnostique", C3b).

docker compose run --rm omnibase bare                      # the Foundation; exits 1 when the framework was loaded
docker compose run --rm omnibase bare 'Base\Entity\User'    # the classes named
docker compose run --rm omnibase bare --all --each         # every class of src/, each in a process of its own: those that can join
docker compose run --rm omnibase bare --json               # the whole report
docker compose run --rm omnibase bare --names              # informative: the classes of the Foundation that name the framework
docker compose run --rm omnibase bare vendor/omnisense/omnibase/tests/Contract/runtime-without-framework.php   # a script, with the autoloader alone

Where the framework is not installed (plan "omnibase agnostique", C7c): the classes are loaded with the autoloader of var/bare/vendor, the core installed alone by composer install --no-dev - its composer.json as it is, its autoload pointed back at the checkout's src/ - so none of Symfony's framework packages is there (symfony/console aside, doctrine/orm's). bare --install makes it, and makes it again when composer.json changed; demo.sh runs it before bare and before the core's suite, whose BareTest measures the Foundation there (skipped in an application's suite, where it was not made). A class declares what is installed: Base\Entity\User's contracts are empty interfaces there, Security's and scheb/2fa's on the harness's own vendor (BareTest checks both). OMNIBASE_AUTOLOAD names another autoloader to measure on.

What is checked is what loading a class loads - its parents, interfaces, traits, what its file runs - not what its methods do when called: an attribute's class, a type in a signature and a new in a method body load nothing until they run. Composer's autoloader itself includes api-platform/jsonld's HydraContext.php (a constant, a files entry) before any class: it is reported, not held against one.

A script given in place of a class (a path ending in .php) is run the same way, with the autoloader alone, and what it returns is in the --json report: BareTest runs tests/Contract/runtime-without-framework.php so, the contracts of the Foundation used without the framework (see The contracts of the Foundation).

The list only grows. A class enters it when it loads without the framework (bare --all --each); a class leaves it only by a decision written down in the plan "omnibase agnostique" and in CHANGELOG.md. On 2026-10-17 it held 599 of the 895 classes of src/; 691 of 908 after step C4; 694 of 911 after steps C3e and C3f; 718 of 921 after step C6 (the Doctrine mapping's bridge, and the services of omnibase's own caches, AbstractLocalCacheInterface no longer extending HttpKernel's WarmableInterface). The bare command is demo.sh's: an image built before it has the script only, docker compose run --rm omnibase php vendor/omnisense/omnibase/docker/bin/bare.

The names report: bare --names

A second report, informative, not a guard: which classes still name the framework, where loading them loads none of it (a type in a signature, a new in a method, an attribute). Nothing is loaded; each file of src/ is read, its use lines (grouped ones expanded, use function and use const too) and its fully qualified names. Two counts: the classes that name the framework themselves (●), and those that name it through the Base\ classes they name, followed to the end (○, with the chain). It is the dashboard of the seams (C3-C5): the Foundation only grows, this report only falls. --all reads every class of src/, a list of classes reads those; --json gives the whole report. On 2026-10-18 (after C4): of the 691 classes of the Foundation, 133 name the framework themselves (131 of the 679 before it, the two more are Symfony adapters), 420 themselves or through a Base\ name. After C3e and C3f: of 694, 129 name it themselves (128 of the classes of before, and Notification's Symfony half), 410 themselves or through a Base\ name. After C6: of 718, 134 name it themselves (the 129, and five of the services that joined: the AttributeReader and the ClassMetadataManipulator - form types in a method -, the Localizer, the Themizer, WebpackTagRenderer), 422 themselves or through a Base\ name.

The agnostic core: bare --strict

The Foundation allows Doctrine, Twig and the standalone Symfony components (decisions D1, D2, D4 of 2026-10-17). Since 2026-11-01 the goal is wider: the core imposes neither Doctrine, nor Twig, nor Symfony beyond the components kept (plan "omnibase agnostic", step F0). bare --strict measures that goal the same way, by loading, on the same vendor without the framework; it refuses, besides the framework:

• every Doctrine package but doctrine/collections (and doctrine/deprecations, which it reads): the ORM, DBAL, persistence, the event manager, common;
• Twig and its extras;
• the bridges to a host or a persistence: omnibridge/doctrine, twig, symfony and laravel; Laravel itself (Illuminate\);
• every Symfony component outside the kept ones - string, uid, intl, translation, mime, mailer, notifier (not its transports), property-access, options-resolver, yaml, password-hasher, filesystem, finder, serializer, the contracts and the polyfills -: validator, cache, event-dispatcher, http-client (HTTP is a contract only), process, workflow, var-dumper, error-handler, asset, expression-language, css-selector, property-info...

Its list is tests/Agnostic.php: the classes of the Foundation that pass, none of src/Bridge/ (the adapters, which move to the omnibridge/* packages). It only grows, as the steps of the plan put the core's code on contracts; a class leaves it only by a decision written in the plan and in CHANGELOG.md (its move to a bridge is one). BareTest::testTheAgnosticCoreLoadsWithoutDoctrineNorTwig is its guard, testTheStrictCheckNamesDoctrineAndTwig shows it is not blind (an enum's DBAL parent and a Twig extension are named). --strict combines with the other options: bare --strict --all --each says which classes of src/ pass, bare --strict --names names the wider set.

The core alone: bare --alone (5.0)

Since 5.0 (plan "omnibase agnostic", step F6) the core requires the agnostic core's packages alone. bare --install --alone makes var/bare-alone/vendor from the core's require and nothing else (not extra.omnibase.bare, which var/bare adds: omniauth and its methods, glitchr/backup-manager and omnibridge/doctrine), and bare --strict --alone loads tests/Agnostic.php there (BareTest::testTheCoreAloneLoadsTheAgnosticCore, which also builds the services' list in plain PHP on it). demo test makes both vendors before the core's suite. A class that stands on a package the core only suggests (symfony/validator, workflow, asset; omniauth, glitchr/backup-manager on the vendor alone) is reported as optional where that package is not installed, as src/Twig is without Twig. --strict accepts doctrine/lexer, which egulias/email-validator reads when symfony/mime checks an address. On 2026-11-03 (core 5.x): 741 agnostic classes on both vendors, the Foundation 802 (19 optional for symfony/validator, 35 for Twig, 1 each for workflow and asset).

On 2026-11-01 (core 4.x e156cfaf): 625 of the Foundation's 860 classes. What keeps the others out, most often: Twig's AbstractExtension, doctrine/orm's EntityRepository (the 81 repositories), the console, DBAL's Type (the 20 enums, through EnumType), the validator, the event dispatcher.

Twig is optional (step F4): twig/twig, its extras and omnibridge/twig are suggestions of the core, so var/bare/vendor has no Twig. There bare reports a class of src/Twig that cannot load for want of a class of Twig's (an extension, the environment, the loader) as "optional": "twig/twig" - not a failure -; the Twig-free classes of src/Twig and every other class are measured as before, and none may need Twig (BareTest::testTwigIsOptional). On a vendor where Twig is installed (OMNIBASE_AUTOLOAD, this run's) nothing is optional. tests/View/helpers-without-twig.php runs the neutral view helpers (Base\View\*) there under --strict (testTheViewHelpersWorkWithoutTwig). After step F4: 677 of the Foundation's 889 classes (+16 helpers, and Base\Service\BaseService, which no longer declares Twig's RuntimeExtensionInterface). After step F2c: 681 of 893; after step F2d: 686 of 898 (Base\Database\UnitOfWorks, the backends RowLocks, ConditionalUpdates, EntityCache, the Identities interface); after step F2e: 690 of 902 (the scopes TrashScope and VaultScope, BulkDeletes, Pages).

The behaviours on both backends: compose.eloquent.yml (step F7c)

docker compose -f compose.yml -f compose.checkouts.yml -f compose.eloquent.yml run --rm omnibase test

The overlay mounts omnibridge/eloquent's checkout (${OMNIBRIDGE:-../../../omnibridge}/eloquent, with its own vendor/) and sets OMNIBASE_ELOQUENT, the harness switch: each test using Tests\Base\Database\Backend\BothBackends (OrderColumnLazyTest, SlugifyPerTypeTest, UploaderSplFileInfoTest, EmptyTrashTest, ThreadParticipantsTest, BehaviourBackendsTest) runs once on Doctrine and once on omnibridge/eloquent, on the same database, the same calls through omnisense/omnibridge's UnitOfWork. Without the overlay the Eloquent cases are skipped, saying so. In an application's suite on base.persistence: eloquent they run on the application's own persistence instead (the switch unneeded), and the tests writing what the code under test reads write through the persistence the host chose (Tests\Base\Database\Backend\HostPersistence, used by HttpTestTrait - hostUser() - and DemoKernelTestCase); a test of Doctrine itself says so and is skipped there. The package's own behaviour parity (every row written on both) runs here too: test --filter WriteParityTest /srv/omnibridge/eloquent/tests/Harness/WriteParityTest.php.

doctrine/orm as released

Since 4.0 the image's doctrine/orm is as released: glitchr/base-plugin, which patched it for the cores before step C6, is gone (omnibridge/composer applies only what the core declares, extra.omnibridge: symfony/process). To run the suites on another release of doctrine/orm, mount its src/ over the installed one:

git clone --depth 1 --branch 3.7.5 https://github.com/doctrine/orm.git /tmp/orm
docker compose -f compose.yml -f compose.checkouts.yml run --rm -v /tmp/orm/src:/srv/demo/vendor/doctrine/orm/src:ro omnibase test

(docker compose run --rm omnibase composer show doctrine/orm names the installed version.) See The Doctrine mapping.

SQLite

The harness's database is SQLite; the applications run MySQL/MariaDB. Code that writes SQL by hand says so per platform: the analytics counters (Base\Repository\Analytics\*) upsert with ON DUPLICATE KEY UPDATE / INSERT IGNORE on MySQL and ON CONFLICT elsewhere (VisitRepository::insertIgnore()), and count distinct pairs over a SELECT DISTINCT subquery rather than MySQL's COUNT(DISTINCT a, b, c).

Rebuilding the image

The image installs the plugins and the sibling families from Packagist, their development branches (omnisense/omnitrade 1.x with its catalogue, omnitrade/stripe, omnisense/omnibus 2.x and two carriers). Docker keeps that layer until this checkout changes; to fetch the families' latest commits:

docker compose -f compose.yml -f compose.checkouts.yml build --build-arg OMNI_REFRESH=$(date +%s) omnibase

The same goes for the core's own dependencies on their development branches (omnibridge/doctrine, omnibridge/twig, 1.x-dev): an image built before a commit of theirs that the core needs keeps the older one. Rebuild with OMNI_REFRESH rather than mounting a checkout over vendor/; the image of 2026-10-18 has omnibridge/doctrine cf6b3b9 (the UTC types the core extends), and the suite runs on it without a mount.

docker/app/ (configuration, .env.test, tests/harness.php) is copied into the image: a change there needs a build too.

Shared bricks

What several sites need and used to copy, written once in omnisense/omnibase. An application or an omnibase/* bundle uses these; it does not keep a copy.

Installation

Nothing to enable: the services are registered by the bundle (config/services/commons.php), the entities mapped with the others. A site that updates omnisense/omnibase gets these tables on its next migration (hoursWeekDay, hoursSpecialDay, hoursScopedWeek, threadComment, layoutTextOverride, layoutRedirection):

bin/console doctrine:migrations:diff
bin/console doctrine:migrations:migrate

Their names differ from the copies some sites kept (weekDayHours, specialDay, blog_comment, textOverride): a site that has not moved yet is not disturbed, and moving is a RENAME TABLE (or, for the blog's comments, an INSERT … SELECT) in the migration that drops its copy. See Scaffolding a site for what a new site copies.

Configuration

# config/packages/base.yaml
base:
    opening_hours:
        timezone: Europe/Paris       # the hours are given in it
        cutoff: '18:00'              # past it, orderDay() is the next open day (null: the day's last closing)
        week:                        # until a week is saved in hoursWeekDay
            3: [['09:00', '13:00'], ['16:30', '19:00']]
            6: [['09:00', '18:00']]
    local_business:                  # see LocalBusiness JSON-LD
        address: { street: '1 rue des Exemples', postal_code: '67300', locality: Schiltigheim, country: FR }
    comments:
        min_delay: 4                 # seconds: a form sent faster is a robot
        flood_interval: 60           # seconds between two comments from one address
    download_links:
        ttl: 600                     # seconds a signed link stays valid

Opening hours

Base\Service\OpeningHours says when the place is open: the usual week (Base\Entity\Hours\WeekDayHours, one row per ISO day, else base.opening_hours.week) and the days off it (Base\Entity\Hours\SpecialDay: closed, or open at other hours, for one day or a run of days).

public function __construct(private OpeningHours $hours) {}

$this->hours->isOpenAt();                    // now, in base.opening_hours.timezone
$this->hours->hoursOn($day);                 // [['09:00', '13:00'], ['16:30', '19:00']], special days included
$this->hours->orderDay();                    // the day an order made now is for
$this->hours->slots($day, step: 30);         // ['12:00-12:30', ...] not before now + 30 min
$this->hours->summary();                     // the footer's lines: days in a row with the same hours together
$this->hours->notices(days: 14);             // special days to announce

Saving the week and a day off:

$weekDays->save([3 => [['09:00', '13:00']], 6 => [['09:00', '18:00']]]); // WeekDayHoursRepository
$em->persist((new SpecialDay(new \DateTime('2026-12-24'), new \DateTime('2026-12-26'), 'Noël')));

In a template, opening_hours() is the service:

{% for line in opening_hours().summary() %}…{% endfor %}
{{ local_business_jsonld() }}

schema() gives schema.org's openingHoursSpecification and specialOpeningHoursSpecification (a closed day opens and closes at 00:00): Google reads the days off from there. local_business_jsonld() prints them with the business's name, address and phone: LocalBusiness JSON-LD.

The week and the days off are edited in the back office (omnibase/admin's "Opening hours" screen, /admin/hours).

Several places

A site with one place needs nothing more. With several (shops, practices, rooms), each place is a scope: a key its owner chooses ('store:12'), or an entity (OpeningHours::scopeOf($store) is its class and id).

$hours = $this->hours->for($store);          // or ->for('store:12'): the same service, for that place
$hours->isOpenAt(); $hours->hoursOn($day); $hours->schema(); // ... every method above

$scopedWeeks->save('store:12', [1 => [['08:00', '12:00']]]);  // ScopedWeekRepository: the place's own week
$scopedWeeks->forget('store:12');                             // back to the site's
$em->persist(new SpecialDay($from, $until, 'Travaux', 'store:12'));

{% for line in opening_hours(store).summary() %}…{% endfor %}

• The week: the place's own (Base\Entity\Hours\ScopedWeek, one row per place) when it has one, else the site's.
• The special days: the place's own and the site's; on a date both cover, the place's wins (a shop open on a day the company is closed).
• The injected service and opening_hours() without an argument stay the whole site's: for() returns a new instance.

An update of omnisense/omnibase adds the table hoursScopedWeek and a nullable scope column (indexed) to hoursSpecialDay; hoursWeekDay is untouched.

Tests and a change made in the same request: withWeek([...]) and withSpecialDays([...]) replace what would be read from the database.

Calendar

Base\Service\Calendar\Ics writes iCalendar files (RFC 5545: CRLF, lines folded at 75 octets without cutting a character, escaped texts, a VTIMEZONE for each timezone used, whole days as dates) and GoogleCalendarLink the "add to Google Calendar" link. Both read a CalendarEntry, so any date of any bundle can be written: map your entity to one.

use Base\Service\Calendar\CalendarEntry;

$entry = new CalendarEntry(
    uid: $appointment->getId().'@'.$host,
    title: 'Consultation',
    start: $appointment->getStartsAt(),          // in the timezone it happens in
    end: $appointment->getEndsAt(),              // null: start + defaultDuration (PT2H)
    description: "Bring your card\nSecond floor",
    location: '12 rue de la Paix, Paris',
    url: $urls->generate('app_appointment', [...], UrlGeneratorInterface::ABSOLUTE_URL),
    cancelled: $appointment->isCancelled(),
);

return new Response($ics->calendar([$entry], 'Mes rendez-vous'), 200, ['Content-Type' => 'text/calendar; charset=utf-8']);
$link = $google->for($entry);

Ics::escape(), Ics::fold() and Ics::unfold() are public for whoever writes or reads a line by hand. omnibase/agenda maps its Event through Event::toCalendarEntry().

LocalBusiness JSON-LD

schema.org's LocalBusiness for a page: who the business is, where, how to reach it, when it is open. Search engines read the address, the phone and the hours - the days off too - from there.

{# in the layout's <head>, or on the contact page #}
{{ local_business_jsonld() }}

<script type="application/ld+json">{"@context":"https://schema.org","@type":"LocalBusiness","@id":"https://soifdepub.com/#business","name":"PANO Strasbourg","url":"https://soifdepub.com/","telephone":"03 55 40 13 81","address":{"@type":"PostalAddress","streetAddress":"1 rue des Exemples","postalCode":"67300","addressLocality":"Schiltigheim","addressCountry":"FR"},"openingHoursSpecification":[…],"specialOpeningHoursSpecification":[…]}</script>

Where each property comes from

In this order: what the template gives, the back office's settings, the configuration. A property nobody gives is left out.

# config/packages/base.yaml
base:
    local_business:
        type: LocalBusiness
        image: assets/ico/android-chrome-512x512.png
        address: { street: '1 rue des Exemples', postal_code: '67300', locality: Schiltigheim, country: FR }
        geo: { latitude: 48.6071, longitude: 7.7399 }
        same_as: ['https://www.facebook.com/panostrasbourg/', 'https://www.instagram.com/pano_strasbourg']
        area_served: [Strasbourg, Schiltigheim, Bas-Rhin]
        extra:
            parentOrganization: { '@type': Organization, name: PANO, url: 'https://pano-group.com' }

omnibase/admin's settings page has the phone and the address (BusinessSettingsSection): what is typed there wins over the configuration.

In a template

{{ local_business_jsonld({priceRange: '€€', servesCuisine: 'Japanese'}) }}   {# properties of the page's own; null removes one #}
{{ local_business_jsonld({name: store.name}, store) }}                       {# one place: its own hours (OpeningHours::for()) #}
{% set business = local_business() %}                                        {# the properties, to put in a graph of the page's own #}

The script is printed as it is (<, > and & are escaped inside the JSON: a title cannot close the script). In PHP: Base\Service\LocalBusiness::schema() and jsonLd().

Invitations

Nobody signs up, someone is invited: a random token (48 hexadecimal characters) is sent by e-mail and never stored - only its SHA-256 is kept. Its link, before it runs out, creates the account (the link proved the address) or attaches the existing one.

• Base\Entity\User\Invitation: a mapped superclass (e-mail, name, tokenHash, createdAt, expiresAt, acceptedAt, invitedBy). Each bundle keeps its own table and says what an invitation opens.
• Base\Service\Invitations: token(), hash(), expiry($days), save(), findOpen($class, $token), markAccepted(), createUser(), existingUser().

#[ORM\Entity]
#[ORM\Table(name: 'office_invitation')]
class Invitation extends \Base\Entity\User\Invitation
{
    #[ORM\Id, ORM\GeneratedValue, ORM\Column] private ?int $id = null;
    #[ORM\ManyToOne] private Practice $practice;
    public function getId(): ?int { return $this->id; }
}

$token = Invitations::token();
$invitations->save(new Invitation($email, $name, Invitations::hash($token), Invitations::expiry(14)));
// mail the link with $token; on the link:
$invitation = $invitations->findOpen(Invitation::class, $token) ?? throw new GoneHttpException();

omnibase/estate extends both (its Invitation keeps estate_invitation, its Invitations opens an associate, a tenant, a contractor or a member).

Downloads and QR codes

Base\Service\DownloadLinks signs a route's absolute URL with Symfony's UriSigner for base.download_links.ttl seconds (or the TTL given). Who may download is checked when the link is handed out; the download action only checks the signature.

return $this->redirect($links->sign('forge_download_file', ['id' => $artifact->getId(), 'filename' => $artifact->getFilename(), 'license' => $license->getId()], 900));

#[Route('/telechargements/fichier/{id}/{filename}', name: 'forge_download_file')]
public function file(Request $request, ...): Response
{
    if (!$this->links->verify($request)) { throw $this->createAccessDeniedException(); }
    ...
}

omnibase/forge (artifacts) and omnibase/classroom (resources) use it.

QR codes

Base\Service\Qr\QrCode draws a code with endroid/qr-code: svg($data), dataUri($data, $size, $margin, 'svg'|'png'). In Twig: qr_code(url).

Base\Service\Qr\QrSheet lays codes out on A4 pages to print at 100 %:

#[Route('/admin/tables/qr')]
public function sheet(QrSheet $sheet): Response
{
    $items = array_map(fn (Table $t) => ['data' => $this->generateUrl('app_table', ['id' => $t->getId()], UrlGeneratorInterface::ABSOLUTE_URL), 'label' => $t->getName()], $tables);

    return new Response($sheet->render($items, 'L7160', 'Tables', skip: 2)); // the first two labels already used
}

pages() gives the positions without rendering, for a template of your own. Check a layout once with a test print: label sheets of other makes differ by a millimetre or two.

Allergens

Base\Enum\Allergen lists the fourteen allergens a food business declares in the European Union (Regulation (EU) No 1169/2011, Annex II), in the Annex's order: gluten, crustaceans, eggs, fish, peanuts, soybeans, milk, nuts, celery, mustard, sesame, sulphites, lupin, molluscs.

#[ORM\Column(type: 'json')]
private array $allergens = [];                       // ['gluten', 'milk']

Allergen::fromList($dish->getAllergens());            // [Allergen::GLUTEN, Allergen::MILK], in the Annex's order
Allergen::MILK->number();                             // 7
$builder->add('allergens', ChoiceType::class, ['choices' => Allergen::choices(), 'multiple' => true, 'expanded' => true, 'choice_translation_domain' => 'enums']);

{% for a in allergens %}<abbr title="{{ ('@enums.' ~ a.trans)|trans }}">{{ a.number }}</abbr>{% endfor %}

Names in the enums domain (allergen.<value>), French and English.

Comments

Base\Entity\Thread\Comment is what a visitor leaves under a thread (a blog post, a sequence, a video) - or, with no thread, in the site's visitors' book: a name, an e-mail (never shown), a site, a text, a reply to another comment (one level), the account when signed in. Table threadComment.

• States (Base\Enum\CommentState): pending, approved, spam, trash.
• Akismet: the form's model (Base\Form\Model\CommentModel) implements SpamProtectionInterface; the score decides the state (toComment($thread, $autoApprove)).
• Robots: Base\Form\Type\CommentType adds a trap field (url) and the time the form was opened (opened); Base\Service\CommentGuard::check($form, $request) answers trapped (thank it, save nothing), too_fast, flood or null (base.comments.min_delay, base.comments.flood_interval).
• Reading: Base\Repository\Thread\CommentRepository::findVisible($thread), countVisible(), findPending(), countPending().

$model = CommentModel::forUser($user);
$form = $this->createForm(CommentType::class, $model, ['signed_in' => null !== $user]);
$form->handleRequest($request);
if ($form->isSubmitted() && CommentGuard::TRAPPED === $guard->check($form, $request)) { return $this->redirect($back); }
if ($form->isSubmitted() && $form->isValid()) {
    $comment = $model->toComment($thread, autoApprove: true)->setIp($request->getClientIp());
    $em->persist($comment); $em->flush();
}

A bundle that needs more on its comments extends Comment (JOINED) with a #[DiscriminatorEntry] of its own and passes its class to toComment(). omnibase/blog is the reference user (moderation screen, notifications, Akismet reports).

Pages and texts

{% set frame = embed_url(link) %}
{% if frame and frame.src %}
    <div style="aspect-ratio: {{ frame.ratio }}"><iframe src="{{ frame.src }}" title="{{ frame.title ?? frame.provider }}" loading="lazy" allowfullscreen></iframe></div>
{% else %}
    <a href="{{ link }}">{{ link }}</a>
{% endif %}

frame is {provider, src, ratio, height, title, html, url, known} (height: a player of a fixed height across the width, SoundCloud's, has no ratio). Known providers are read from the address alone (known: true): YouTube (as youtube-nocookie.com), Vimeo, Canva, Padlet, LearningApps, Genially, Google Slides. Any other address is asked to its site through the embed/embed library (oEmbed, Open Graph, a requirement of omnisense/omnibase), cached a day per address, and only the iframe's address is kept. embed_url(link, false) never asks.

Contact form

Base\Form\Type\ContactType on Base\Form\Model\ContactModel, as it is:

$form = $this->createForm(ContactType::class, $message = new ContactModel(), ['phone' => true, 'subject' => false, 'attachments' => false, 'buttons' => false, 'trap' => true]);
$form->handleRequest($request);
if ($form->isSubmitted() && $form->isValid()) {
    if (!$message->isRobot()) { $mailer->send(...); }   // the trap filled: thanked, nothing sent
}

Options: phone (off), subject (on), attachments (on), buttons (submit and reset, on), trap (the off-screen website field, off). The model validates the name, the e-mail and the message.

The data-protection notice, and the box to tick

A form that collects personal data says what they are used for (GDPR, art. 13), and may ask for a box to be ticked before it is sent. One brick for every site and bundle, Base\Form\Type\PrivacyType, which ContactType adds through three options:

$form = $forms->createNamed('contact', ContactType::class, $message = new ContactModel(), [
    'phone' => true, 'subject' => false, 'attachments' => false, 'buttons' => false, 'trap' => true,
    'privacy' => '@messages.contact.privacy',              // its text links {url}, the privacy page
    'privacy_parameters' => ['url' => $this->generateUrl('app_legal')],
    'privacy_consent' => true,
]);

{{ form_row(form.message) }}
{{ form_row(form.privacy) }}   {# the notice, then the box when asked #}

Any other form - a quote request, an application, a registration - adds the same field rather than its own checkbox and sentence:

$builder->add('privacy', PrivacyType::class, [
    'notice' => '@forms.privacy.notice',   // or the bundle's key, or false
    'notice_parameters' => [],
    'consent' => true,
    'consent_label' => '@forms.privacy.consent',
    'consent_message' => 'privacy.consent_required',
]);

The field is not mapped: the model keeps the message, not the tick (read it with $form->get('privacy')->get('accept')->getData() if it must be kept). The notice is printed by omnibase's form theme (block base_privacy_row: a div.form-privacy holding p.form-privacy-notice, then the box) as HTML, since it is a translation the site wrote. The default texts exist in English and French (forms: privacy.notice, privacy.consent); a site in another language, or with other words, gives its own keys.

Pictures: |picture

<img src="{{ post.cover|picture(640) }}">   {# an upload, resized; a URL or /path as is; else public/assets/<it> #}

Texts rewritten in the back office

Base\Entity\Layout\TextOverride (table layoutTextOverride): a key, a domain, a language and the new text. Base\Translation\OverridingTranslator decorates the translator (between omnibase's and Symfony's): a rewritten key wins over translations/, ICU syntax included. The texts are cached (the application's cache.redis pool when it has one, else cache.app) and the cache is emptied when one is saved. The screen is omnibase/admin's "Textes du site" (Base\Admin\Controller\Crud\TextOverrideCrudController).

A text written in the editor: |wysiwyg

A field edited with omnibase's editor (WysiwygField, EditorJS) stores a JSON document, {"blocks": [...]}; a field edited with Quill stores HTML. |wysiwyg prints either:

{{ page.content|wysiwyg|raw }}
{{ page.content|wysiwyg({headings: 3, semantics: true, media: {storage: 'local.public'}})|raw }}
{{ page.content|wysiwyg({hydrate: false})|raw }}        {# the HTML alone #}

The blocks of an EditorJS document are rendered on the server (Base\Service\Model\Wysiwyg\EditorJsRenderer): paragraph, header, list (nested, ordered, checklist), quote, image, embed, table, code, delimiter, warning / alert, raw, link, attachment. The page reads without any script, and so does a crawler. (It used to print an empty <div data-edjs="…"> that only the editor's script could fill: a site that does not load that script on its public pages showed nothing.)

A block's text keeps the editor's inline HTML (bold, links, marks, mentions); tags outside that list, on… attributes and javascript: addresses are removed. In PHP: EditorJsRenderer::render($json) gives the HTML of a document (an e-mail, a feed, a search index).

A page's language

Base\Subscriber\LocalizerSubscriber decides it on each main request, in this order (LocalizerSubscriber::choose()):

1. the page's address, when its route has one language (/en/..., app_legal.de);
2. a signed-in member's own language (User::getLocale(), which a choice of language through /locale/{_locale} updates) - but while impersonating, the impersonator's choice (LANG) first;
3. the language the visitor's last page was shown in, or the one they chose (the LANG cookie, which each response keeps up to date);
4. on a first visit, the browser's (Accept-Language, among the site's languages);
5. the site's (framework.default_locale).

The request's, the translator's and the router's locale follow, and so does intl's default (\Locale::setDefault()), which NumberFormatter and IntlDateFormatter use when they are given no locale: an amount or a date prints in the page's language.

Signatures

A document sent to be signed - a lease, a quote, a surety - for any entity of the application, through omnisense/omnisign (Yousign, DocuSign, a DocuSeal instance of one's own): signed by the provider's e-mail or in the site's own page, followed until it is over, and once completed the signed document and its evidence kept in the site's private storage.

use Omnisign\Model\{Document, Envelope as Request, Field, File, Signer};

$envelope = $signatures->send($quote, new Request(
    'Devis D-2026-042',
    [new Document('quote', new File($pdf, 'devis-D-2026-042.pdf'))],
    [new Signer('client', 'Camille Érable', 'camille@erable.example')],
    [new Field('client', 'quote', page: 1, x: 72, y: 640)],
    embedded: true,                                    // signed in the site's page, no e-mail from the provider
));
return $this->redirect($signatures->signingUrl($envelope, 'client', $returnUrl));

$signatures->refresh($envelope);                       // on the way back - the provider's webhook does it too
$signatures->signed($envelope);                        // the signed PDF, once completed
$signatures->evidence($envelope);                      // its audit trail or certificate
$signatures->of($quote);                               // the envelopes about the quote, newest first

Only with the family

omnisense/omnisign is suggested, not required. Without it nothing of this exists in a site:

• Base\Service\Signatures is not registered;
• Base\Entity\Signature\Envelope is not an entity - no signature_envelope table, nothing in the site's schema, migrations or fixtures (its fields are those of the mapped superclass AbstractEnvelope, which has no table);
• POST /signatures/{gateway}/webhook answers 404.

With it: composer require omnisense/omnisign omnisign/docuseal (or omnisign/yousign, omnisign/docusign; not on Packagist yet: the vcs repositories of omnisense/omnibase's composer.json), register Omnisign\Bridge\Symfony\OmnisignBundle, configure a gateway, then make:migration and doctrine:migrations:migrate for the table:

# config/packages/omnisign.yaml
omnisign:
    gateways:
        contracts:
            factory: docuseal
            options:
                url: '%env(DOCUSEAL_URL)%'                 # https://sign.example.org/api
                api_key: '%env(DOCUSEAL_API_KEY)%'
                webhook_secret: '%env(default::DOCUSEAL_WEBHOOK_SECRET)%'

# config/packages/base.yaml
base:
    signatures:
        gateway: contracts        # null: the only gateway configured
        storage: ~                # null: the uploads' storage (base.uploader.storage, var/storage/uploads)

What an envelope keeps

The files are read back through signed() and evidence(); a site serves them to whoever may see them, with a signed link (Base\Service\DownloadLinks) or its own access check - the storage itself is out of public/.

Following it

• refresh() asks the provider where it stands (a page the signer comes back to, a command).
• The provider's webhook: POST /signatures/{gateway}/webhook (base_signature_webhook) - its signature checked by the gateway (webhook_secret, or the provider's own key), the envelope it names asked again. A callback whose signature does not hold is answered 400.
• Events (Base\Event\SignatureEvent), dispatched once each: SIGNED when a signer signed, then COMPLETED, DECLINED, EXPIRED or CANCELED; getSubject() gives the entity it is about. The application answers there: a quote accepted, a lease in force.

#[AsEventListener(event: SignatureEvent::COMPLETED)]
public function onSigned(SignatureEvent $event): void
{
    if ($event->getSubject() instanceof Quote) { ... }
}

remind() asks the provider to remind who has not signed; cancel() withdraws it.

Tests

tests/Service/SignaturesTest.php, in the harness (which installs omnisense/omnisign and omnisign/docuseal and registers a DocuSeal gateway): a lease sent for a member, signed in the page, followed to completion, its files kept and read back, its events, the webhook's signature - DocuSeal answering as an instance of its open-source edition answered (omnisign/docuseal's recorded answers). What a provider does for real is said in each gateway's documentation.

Front end

The same on every site: the year on two lines beside the pixel monkey (it dances on hover), Source Code Pro bold 18pt/21px, linking to https://www.glitchr.io. Its stylesheet (bundles/base/css/credits.css) is linked by the partial.

{% include '@Base/partials/_credits.html.twig' %}                                   {# black #}
{% include '@Base/partials/_credits.html.twig' with {color: 'white', outline: true} %}
{% include '@Base/partials/_credits.html.twig' with {mirror: true, rule: true, site_name: 'My site'} %}

The detail line (the address, the time the page took, the site's name) fades in while the signature is pointed at or focused, and is always shown without a pointer (@media (hover: none)). Filling it differently:

{% embed '@Base/partials/_credits.html.twig' with {color: 'black'} %}
    {% block credits_detail %}{{ parent() }}<span class="ga-credits-line" lang="de">Ein Apfel am Tag</span>{% endblock %}
{% endembed %}

The signature stands against the edge the site sets it on, whether its detail is shown or not: where the detail fades in and out (@media (hover: hover)) it holds no room and overflows on its own side. It is declared on the inner side: the default (detail on the left) for a signature on the right of its footer, mirror: true (detail on the right) for one on the left - else the detail opens outwards, over the page's margin. Without a pointer the detail is always shown and part of the block.

Nothing else is customisable: neither the font nor the colours.

Base.boot()

What every site's assets/app-defer.js repeated: Sticky.ready(), StickyStops.attach() and Transparent.ready() in that order, the back office as a website-in-website. The three come from @glitchr/flowjs (one library, one module per feature; the stops measure themselves again after each navigation). Install it from npm (yarn add @glitchr/flowjs) and import only the modules the site uses: Base.boot() starts a module only if its global is there, so a site that imports the navigation alone starts the navigation alone. The core's own bundle imports none of them - in particular not Ajaxer, which a site that sends named AJAX channels imports itself (import '@glitchr/flowjs/ajaxer').

The one module the core does import is the library's sixth, the cookies: base-async brings @glitchr/flowjs/cookie (the Cookie global, with flowjs's core) to every page, see Cookies below. The core's base-async runs before a site's entries and the library keeps the first Flow loaded, so a site takes the same @glitchr/flowjs as the core (^1.3.1 in its package.json, 1.3.1 or later in its yarn.lock): an older navigation or sticky module would otherwise run on the newer core.

import '@glitchr/flowjs/navigation';   // the modules the site uses: '/sticky', '/stops', '/navigation'
import Base from '../vendor/omnisense/omnibase/assets/boot.js';

Base.boot({
    nest: ['/admin*'],                                  // default
    stops: { reach: 140, settle: 320, duration: 700 },  // StickyStops' options; true: its defaults; false: none
    viewTransitions: false,
    exceptions: ['/agenda.ics'],                        // after /_*, /login*, /logout*, /register*, /locale/*, /connect/*
    current: '.site-nav a',                             // aria-current="page" follows the page
    transparent: { exit_duration: 380 },                // anything else for Transparent.ready(); false: not started
    sticky: false,                                      // Sticky.ready()'s options; false: not started
});

It also makes jQuery's closestScrollable safe, keeps the <style> blocks scripts inject into <head> across swaps (data-headlock), and sends a site page that lands inside the nest frame to the main window. The routes that open in the nest answer X-Transparent-Nest (omnibase/admin's NestHeaderSubscriber: every page under /admin, and any route with defaults: ['_nest' => true]).

media:play: one thing sounds at a time

A page may hold several players - the audio bar of omnibase/music, the video player of omnibase/video, a film in its card, a third-party embed, a plain <audio>. They share nothing but this contract:

1. a player that starts sounding dispatches media:play on document, with detail: { player, kind?, id?, … } - player is any object that is this player and no other;
2. a player that hears media:play from another player pauses itself.

No queue, no common state, no interface to implement: each player keeps its own. media.js (no dependency) is those two lines written once:

<script src="{{ asset('bundles/base/js/media.js') }}" defer></script>

import '../vendor/omnisense/omnibase/assets/media/media.js';     // bundled: the same script, window.MediaPlay

const leave = MediaPlay.join(player, () => player.pause());      // 2. paused when another starts
MediaPlay.announce(player, { kind: 'audio', id: track.id });     // 1. when this one starts
leave();                                                         // the player is destroyed
MediaPlay.current;                                               // the player that sounded last, or null

A script that does not load media.js takes part with the event alone:

document.dispatchEvent(new CustomEvent('media:play', { detail: { player: me } }));
document.addEventListener('media:play', (event) => { if (event.detail.player !== me) pause(); });

Plain elements need nothing. An <audio> or a <video> that starts with its sound on announces itself (detail.player is the element, kind its tag), and is paused when another player starts. A muted one - a hero's silent loop, a preview on hover - neither announces nor is paused; unmuted while playing, it announces itself then. data-media-play="off" on an element, or on anything around it, leaves it out (a sound effect; an element driven by a player that calls announce() itself).

A third-party player that cannot be paused (an embed without an API) is removed, or its frame reloaded, by the function given to join(); a player whose pause fails does not keep the others from pausing.

Stimulus poll

Ask a JSON address every few seconds and react when a value grows - a kitchen board, a queue.

// assets/bootstrap.js
import Poll from '../vendor/omnisense/omnibase/assets/controllers/poll_controller.js';
app.register('poll', Poll);

<div data-controller="poll" data-poll-url-value="{{ path('app_kitchen_state') }}"
     data-poll-key-value="latest" data-poll-since-value="{{ latest }}"
     data-poll-chime-value="true" data-poll-awake-value="true"
     data-action="poll:change->board#show">
    <button data-action="poll#arm">Activer les alertes</button>
    <button data-action="poll#silence">Vu</button>
</div>

The answer must hold the compared field ({"latest": 42, ...}). On a larger value: poll:change (detail: the answer), the class is-ringing, and with chime three notes every two seconds until poll#silence. arm() is the touch browsers ask before a page may make sound; it also keeps the screen on (awake). A hidden page is not polled.

Nothing from elsewhere

A page of a site loads its scripts, stylesheets and fonts from the site itself: no CDN sees the visitor (tests/Http/NothingFromElsewhereHttpTest reads the contact page of the harness - which links base and form as a site's layout does - and what its files pull in).

The editor's code blocks (editorjs-code-highlight) are coloured by highlight.js's default theme. The package's own bundle @imports it from cdnjs.cloudflare.com, and injects it with its styles on every page the editor's script is on - every page with a form. That @import is dropped at build (assets/loaders/no-remote-import.js); the theme is the bundle's copy, bundles/base/css/highlight.js/default.css (highlight.js 11.6.0, BSD 3-Clause, its licence beside it as LICENSE.txt), linked by the editor's script once, and only on a page that shows an editor or a block of code.

The emoji picker (EmojiPickerType, entry form.emoji, picmo) fetched its emojis and their labels from jsDelivr. They are the bundle's copy: bundles/base/emoji/<locale>/data.json and messages.json (emojibase-data 17.0.0, MIT, its licence beside them as LICENSE.txt), in English, French, German and Japanese - the page's <html lang> picks, English otherwise. form-type-emoji.js fetches them on the first click on a field and gives them to the picker, which then fetches nothing; what remains of picmo's own fetching is pointed at the same copy at build (assets/loaders/local-emoji-data.js). The harness's /fields carries one.

The JavaScript dependencies

yarn.lock names every package the bundles are built from, and make assets installs those alone (yarn install --frozen-lockfile): from a clean copy it rebuilds bundles/base byte-identical to what is committed. To take newer packages: ALLOW_ASSETS_UPDATE=1 make assets, then commit the lock with the bundles it built. Node 24 or later (select2's engines).

Cookies

base-async imports @glitchr/flowjs/cookie: the Cookie global on every page (Cookie.set(group, name, value, expires), Cookie.get(), Cookie.cookies, Cookie.local, Cookie.session, Cookie.use(), see the library's docs/cookie.md). It replaces @glitchr/cookie, whose methods and localStorage keys (cookie/<GROUP>) it keeps: a site drops @glitchr/cookie from its package.json and, if it imported it itself, imports nothing in its place.

What is written goes through it, so that the visitor's answer decides (omnibase/consent declares the categories and shows the panel; without that bundle a group is written until Cookie.setConsent(false, group) refuses it):

| USER/LAST_VISIT | the server, when a template asks app.site.is_newcomer() - not for a visitor who refused USER (Base\Security\CookieAnswer::refused('USER') reads the answer the script keeps in the cookie cookie-consent) | USER |

The server reads the others and writes none of them: User::getCookie('timezone') is LOCATION/TIMEZONE, else USER/INFO's; getCookie('country') is read from that zone. A script of a site writes its own the same way (Cookie.set('USER', 'THEME/MODE', mode, ...), or Consent.cookie(group, name, value, expires)), never with document.cookie: what is written behind Cookie is neither kept from being written after a refusal nor known to the detailed section.

Redirections

The addresses a site no longer answers, and where they lead now: the pages of a site taken over (/produit/enseigne-lumineuse/ → /savoir-faire/enseigne), a page renamed. One row each in Base\Entity\Layout\Redirection (table layoutRedirection), written in the back office (omnibase/admin's "Redirections" screen), by fixtures or by an import.

public function __construct(private Redirections $redirections) {}   // Base\Service\Redirections

$this->redirections->add('/produit/enseigne-lumineuse/', '/savoir-faire/enseigne');          // 301
$this->redirections->add('/soldes', '/boutique', Redirection::TEMPORARY);                    // 302
$this->redirections->add('/?p=123', '/actualites/ouverture');                                // a WordPress address
$this->redirections->add('/categorie-produit/*', '/savoir-faire/*');                         // everything beneath
$this->redirections->add('/charte', 'https://pano-group.com/charte', flush: false);          // another site; flushed by the caller

When

Only when a request ends in "not found" - no route matched, or a controller found no record (Base\Subscriber\RedirectionSubscriber, on the kernel's exception). A page the site answers is never redirected, whatever the table says, and costs no query. GET and HEAD only: a form sent to an old address is not replayed elsewhere.

Which

A source is stored as its path (Redirection::normalize(): no host, no trailing slash, no fragment), so a whole address pasted from the old site is fine. The one written for the address with its query comes first, then the one for its path, then the longest prefix.

The case of an exact source is the database's to judge: with MySQL's default collation /Produit/Enseigne is /produit/enseigne and is redirected (the row was found, then refused for its case: the address answered 404); on a case-sensitive database (SQLite, a _bin collation) only the same letters match. A prefix (/categorie-produit/*) is compared letter for letter everywhere.

The target is a path of the site or a whole address. When the source has no query and the target none either, the visitor's query follows (?utm_source=…).

What it keeps

status (301 by default: search engines move what they know of the old address to the new one; 302 for a detour that will not last), enabled, hits and lastHitAt (counted at each redirection, in UTC): the back office shows which old addresses are still visited, and which can go.

A site that updates omnisense/omnibase gets the table on its next migration. Until then nothing is redirected and nothing fails.

PDF responses

Base\Response\PdfResponse answers an HTML page as a PDF: an invoice, a rent receipt, a quote. It renders with Dompdf, a suggested package - omnibase does not require it:

composer require dompdf/dompdf

Without it, PdfResponse throws a LogicException that says so (Try running "composer require dompdf/dompdf"), where PHP used to stop on Class "Dompdf\Dompdf" not found.

use Base\Response\PdfResponse;

return new PdfResponse($this->renderView('invoice.pdf.twig', ['order' => $order]));

return new PdfResponse($html, 200, [
    'filename' => 'facture-2026-041.pdf',
    'stream' => ['Attachment' => true],            // downloaded, not shown in the browser
    'options' => ['defaultPaperSize' => 'a4'],     // Dompdf's options
    'Cache-Control' => 'private, no-store',        // anything else is a header
]);

$pdf = PdfResponse::render($html);                 // the PDF as a string: an e-mail attachment, a file to keep

The PDF is the response's content

The PDF is in getContent(), with Content-Type: application/pdf and a Content-Disposition; the kernel sends it like any response. (It used to be sent by Dompdf's stream() from the constructor: headers and bytes went out before the kernel answered, a test could not read the response, a listener could not touch it.)

Remote resources are off

isRemoteEnabled is false by default: an <img>, a stylesheet or a font at an http(s) address is not fetched, and is left out of the PDF. The page often carries what a visitor typed (a name, an address, a message), and fetching what it names from the server is a request forgery (SSRF).

• images: embed them, <img src="{{ logo|embed_base64 }}">;
• styles: in a <style> of the page; fonts: Dompdf's own (DejaVu, Helvetica, Times) or files installed with Dompdf's font loader;
• a page that names only addresses you wrote yourself may turn it back on: ['options' => ['isRemoteEnabled' => true]].

A template that linked a web font (<link href="https://fonts.googleapis.com/…">) now prints in the fallback font until it does one of the above.

E-mails

omnibase's frame

@Base/notifier/email.html.twig is the frame of omnibase's e-mails (Inky, styles inlined). A notification renders it with its own context; a plain TemplatedEmail extends it and gives nothing but its blocks:

{# templates/email/appointment.html.twig #}
{% extends '@Base/notifier/email.html.twig' %}
{% block subject %}{{ 'booking.email.subject'|trans({date: date}) }}{% endblock %}
{% block content %}<p>{{ 'booking.email.lead'|trans }}</p>{% endblock %}

$mailer->send((new TemplatedEmail())
    ->to($client->getEmail())
    ->htmlTemplate('email/appointment.html.twig')
    ->context(['date' => $date]));

• Every variable has a default: importance, markdown, raw, content, action_url, action_text, exception, footer_text. (The frame used to stop on "Variable importance does not exist" outside a notification.)
• Blocks: subject, title, style, header, lead, content, action, exception, footer, footer_content.
• The logo is optional: the header block prints one only when there is one - the logo variable of the context, else the back office's setting (base.settings.logo.email, then base.settings.logo). A site without a logo sends its e-mails without one.

A site with its own frame (templates/email.html.twig, as the scaffold copies) keeps it: omnibase's own templates extend email.html.twig, which is the site's when it has one.

The subject is written in the template

{% block subject %} of a TemplatedEmail's template is the message's subject (Base\Subscriber\TemplatedEmailSubjectSubscriber, before the body is rendered): rendered with the e-mail's context, tags removed, entities decoded. It was only printed in the body, and the message left without a subject.

A subject set in PHP wins - ->subject('Rappel') - and is handed to the template as the subject variable, which the frame prints as its title and lead instead of the block.

A notification and its e-mail

Base\Entity\User\Notification is what a notification is - subject, content, importance, channels, recipients, context, templates - and its sending through omnibase's notifier (send(), sendBy(), sendAdmins()). What needs Symfony is Base\Bridge\Symfony\NotificationMessages' (plan "omnibase agnostique", step C3f): the e-mail of asEmailMessage() (Twig's NotificationEmail, the uploaded attachments embedded, the HTML rendered), render()'s Response (renderHtml() is the HTML alone), and the error an ExceptionEvent or a FlattenException carries made the content. The entity's methods are those of before and answer the same; it names nothing of the framework (Symfony's Notifier is a standalone component). addAttachment() takes a \SplFileInfo; the e-mail embeds the uploaded files (UploadedFile), as it did.

Sitemap

/sitemap.xml and /sitemap.txt (app_sitemap) list the pages a site wants indexed. Base\Service\Sitemapper builds the list at each request, in two passes.

Pages without a parameter: #[Sitemap]

use Base\Attributes\Attribute\Sitemap;

#[Route('/agenda', name: 'agenda_index')]
#[Sitemap(priority: 0.8, changefreq: 'weekly')]
public function index(): Response

Every route whose action carries the attribute is listed (registerAttributes()), once per locale. A route with a parameter is listed too when its requirement spells its values out ({extension} with xml|txt): one page per value.

Pages of records: SitemapEvent

A route open to any slug or id is the application's - or the bundle's - to enumerate, from a listener:

#[AsEventListener(event: SitemapEvent::BUILD)]
final class SitemapListener
{
    public function __invoke(SitemapEvent $event): void
    {
        foreach ($this->posts->findAllPublished() as $post) {
            $event->getSitemapper()->register('blog_post', ['slug' => $post->getSlug()], $post->getUpdatedAt()?->format('c'));
        }
    }
}

The route's action still carries #[Sitemap]: the attribute says the page belongs in the sitemap, with which priority; the listener says which pages there are. registerUrl('/blog/petit-cours') does the same from an address.

A page that cannot be listed is left out, never fatal

register() and registerUrl() do not throw. A page is left out, and the reason logged once per request (warning, Sitemap: page left out, ...), when:

• the route does not exist;
• the address, parameters filled in, matches no route;
• the route's action carries no #[Sitemap] - no #[Sitemap] on "App\Controller\BlogController::post" (route "blog_post").

The last one used to throw SitemapNotFoundException: a listener registering a route nobody had declared put the whole /sitemap.xml - every other page with it - in 500. The fix is still to add the attribute; the log says where. A route whose controller is given as an array ([Controller::class, 'method']) or a closure is read without failing as well.

The attributes of a class are read once and kept with the container's cache (var/cache/<env>/pools/simple/, Base\Attributes\AttributeReader): a #[Sitemap] just added is not seen until that cache is rebuilt. When the page stays out after a cache:clear, delete var/cache/<env> and warm it again.

Configuration reference

Everything under the base: key of config/packages/base.yaml, as Base\DependencyInjection\BaseConfiguration declares it, with its type, its default and what reads it. The values are processed once, when the container is built, by Base\DependencyInjection\BaseExtension::load().

How the values are read

BaseExtension does not hand the processed tree to services one by one: it sets every node as a container parameter named after its path, base. and the keys joined by dots (AbstractBaseExtension::setConfiguration()). An array is set both whole and leaf by leaf: base.time_machine.excludes is the list, base.time_machine.excludes.0 its first entry. The code reads them through Base\Service\ParameterBagInterface ($parameterBag->get('base.uploader.storage')), %base.download_links.ttl% in a service definition, or Base\Contract\Runtime::parameters() where there is no container (an entity's getter).

Under Symfony the parameter bag is Base\Service\HotParameterBag: the settings stored in the database are laid over the container's parameters (see The parameters and the settings over them). A path the configuration does not declare reads as null.

The smallest configuration

The harness's application (docker/app/config/packages/base.yaml) runs on this:

base:
    parameter_bag:
        use_hot_bag: true
        use_setting_bag: true
    database:
        use_custom: true
    router:
        use_custom: true
    attributes:
        use_custom: true
    twig:
        use_custom: true
        use_form2: true
        use_bootstrap: true
        editor:
            storage: "local.wysiwyg"
    uploader:
        storage: "local.uploads"
    site:
        index: demo_index

The four use_custom flags and the two parameter_bag flags default to null (off): a site that leaves them out runs without omnibase's router, Twig loader, attribute reader and Doctrine features, without the settings stored in the database, and without those settings laid over the parameters (HotParameters reads the configuration whether the overlay is on or not). The storages are Flysystem storages of the site's own (config/packages/flysystem.yaml).

Dumping the tree

bin/console config:dump-reference base dumps it, and debug:config base the site's values (BaseExtension::getConfiguration()). The tree below was dumped in the core's harness with Symfony's reference dumper, from this script (the image's vendor, the core mounted over its copy):

<?php
// dump.php
require '/srv/demo/vendor/autoload.php';

use Symfony\Component\Config\Definition\Dumper\YamlReferenceDumper;

echo (new YamlReferenceDumper())->dump(new Base\DependencyInjection\BaseConfiguration());

docker run --rm --network none \
    -v "$PWD":/srv/demo/vendor/omnisense/omnibase:ro -v "$PWD/var/scratch":/scratch:ro \
    --entrypoint php omnisense/omnibase-harness:latest /scratch/dump.php

The full tree, with its defaults

The options read by nothing are deprecated (excluded_fields, share, access_restriction.redirect_on_deny, site.maintenance.exception, uploader.warmup, files.storage, images.autorotate, images.disable_profiler, images.warmup, images.formats, extension.logging_default_expiry): a site that sets one gets Symfony's deprecation notice, and they go at the next major.

twig.default_path is the package's own templates/ wherever Composer put it: /srv/demo/vendor/omnisense/omnibase/templates is the harness's.

base:

    # Automatically clear cache in case of integrity issue
    autoclear:            true

    # The persistence: doctrine or eloquent (null: the only one installed; required when both are)
    persistence:          null
    database:

        # Fallback warning disable in case there is no fallback
        fallback_warning:     true

        # Use custom database settings
        use_custom:           null
        excluded_fields:

            # Defaults:
            - id
            - locale
            - translatable
    share:

        # Prototype
        -
            id:                   ~
            url:                  ~
    user:

        # Default throttling time between two tokens received
        token_default_throttling: 180

        # Allow using a token sent by email
        login_with_token:     false

        # Property used to identity user
        identifier:           email

        # Threshold considering user as inactive ("active delay" is expected to be lower than "online delay")
        active_delay:         60

        # Threshold considering user as offline
        online_delay:         300
        notifications:

            # Time before erasing data if read
            expiry:               '+30 days'
        register:

            # Administrator check required
            autoapprove:          false

            # Administrator are notify when someone register
            notify_admins:        false
    access_restriction:

        # Redirection in case of access restriction
        redirect_on_deny:     null

        # Access to public visitors
        public_access:        true

        # Access to users
        user_access:          true

        # Access to administrators
        admin_access:         true
        firewalls:

            # Default:
            - main

        # Routes (regular expressions on their names) no access restriction stops, and the referrer never remembers: the sign-in pages, the language switch, the UX endpoints.
        route_exceptions:

            # Default:
            - /^(?:locale_|ux_|user_|security_)/
        exceptions:

            # Prototype
            -
                locale:               null
                env:                  null

                # Regex 
                host:                 null

                # Regex 
                path:                 null

                # Regex 
                domain:               null

                # Regex 
                subdomain:            null

                # Regex 
                scheme:               null
    site:

        # Website home page
        index:                app_index
        maintenance:

            # Maintenance redirection
            redirect_on_deny:     security_maintenance
            exception:

                # Prototype
                code:                 ~

            # Maintenance lock file location
            lockpath:             '%kernel.project_dir%/public/maintenance.lock'
    router:

        # Use custom router
        use_custom:           null

        # Allow accessing by
        ip_access:            false

        # Restrict to permitted hosts
        use_fallbacks:        false

        # Fallback warning disable in case there is no fallback
        fallback_warning:     true
        host_fallbacks:

            # Prototype
            -
                locale:               null
                env:                  '%env(APP_ENV)%'
                reduction:            null

                # Sub-domain
                subdomain:            []

                # Machine name
                machine:              []

                # Domain
                domain:               []

                # Port number
                port:

                    # Default:
                    - 80

                # Base directory
                base_dir:             /
    translator:

        # How the site addresses people (docs/20-architecture/politeness.md): a text asked without a level of its own is taken in its "._plain", "._polite" or "._formal" variant when the catalogue has one (formal falls back on polite), else as it is. Unset: the texts as they are written.
        politeness:           null # One of null; "plain"; "polite"; "formal"
    parameter_bag:

        # Use setting bag from database
        use_setting_bag:      null

        # Use hot bag parameter rewriting
        use_hot_bag:          null
    notifier:

        # Enable mailer
        mailer:               true

        # Do not allow sending email until loopback is removed
        technical_loopback:   true
        technical_recipient:

            # Technical contact email
            email:                null

            # Default phone number
            phone:                null

        # Administrators receiving notifications
        admin_role:           ROLE_EDITOR
        test_recipients:

            # Default:
            - @localhost$
        options:

            # Prototype
            -
                channel:              ~
                markAsRead:           ~
    spam:

        # AKISMET API Key
        akismet:              ''
    time_machine:

        # Default compression algorithm
        compression:          gzip

        # Default time limit before deleting
        time_limit:           '+30 days'

        # Default compression algorithm
        max_cycle:            -1

        # Directory the snapshot is staged in before transfer (defaults to the kernel cache directory)
        snapshot_dir:         null

        # Paths left out of the application tarball
        excludes:

            # Defaults:
            - ./vendor
            - ./node_modules
            - ./var/cache
            - ./var/log
            - ./var/coverage
            - ./var/phpunit
            - ./.git
    icon_provider:

        # Default icon provider class
        default_adapter:      Base\Service\Model\IconProvider\Adapter\FontAwesomeAdapter
    uploader:

        # Automatic image uploader warmup
        warmup:               true

        # Upload storage location
        storage:              null
        formats:

            # Prototype: Specific formats
            -
                class:                ~
                property:             ~
                width:                ~
                height:               ~
    files:
        storage:              null
    images:
        max_resolution:       Base\Imagine\Filter\Basic\Definition\UltraHighDefinitionFilter
        autorotate:           true
        debug:                false
        disable_profiler:     true
        max_quality:          1
        timeout:              60
        enable_webp:          true
        no_image:

            # Prototype: Replacement image
            -
                extension:            ~
                path:                 ~
        fallback:             false
        warmup:               true
        formats:

            # Prototype: Specific formats
            -
                class:                ~
                property:             ~
                width:                ~
                height:               ~
    paginator:

        # Range around the current page
        page_range:           1

        # Number of element per page
        page_size:            10

        # Default parameter name in route
        page_parameter:       page

        # Default template used to display pages in sliding control
        default_template:     '@Base/paginator/sliding.html.twig'
    obfuscator:

        # Compression level
        level:                -1

        # Use uuid shortening
        uuid:                 6ba7b811-9dad-11d1-80b4-00c04fd430c8

        # Compression encoding
        encoding:             null

        # Decoding max length
        max_length:           0

        # Compression algorithm
        compression:          'null'

        # Identifier-map storage directory; must survive cache:clear/deploys or previously-issued short URLs become permanently unresolvable
        cache_dir:            '%kernel.cache_dir%'
    twig:
        breakpoints:

            # Prototype
            -
                name:                 ~
                media:                ~
        themes:
            audiences:

                # Prototype
                name:
                    age:                  null
                    icon:                 null
            widths:

                # Prototype
                name:
                    icon:                 null
                    class:                null

            # Default audience key among valid audiences
            default_audience:     null
            events:

                # Prototype
                name:
                    begin:                null
                    end:                  null
                    priority:             0
                    icon:                 null
            modes:

                # Prototype
                name:
                    class:                null
                    icon:                 null
                    prefers:              null
            filters:

                # Prototype
                name:
                    icon:                 null
                    filter:               null
        script_attributes:
            defer:                false
            async:                false

            # Scripts run in the order of the page: a file named -async is loaded defer. The core's base-async sets window.jQuery, which the site's entries read as an external; false brings back async, with no guarantee that it runs first.
            ordered:              true
        link_attributes:
            defer:                false
            async:                false

        # Use base filesystem loader
        use_custom:           null

        # Use custom base form style
        use_form2:            true

        # Include EA form style
        use_ea:               true

        # Use bootstrap style in forms
        use_bootstrap:        true

        # Autoappend required dependencies in html content
        autoappend:           true

        # Default twig path: the templates/ of this package, wherever Composer installed it (vendor/omnisense/omnibase, a path repository, a checkout)
        default_path:         /srv/demo/vendor/omnisense/omnibase/templates
        form_themes:

            # Default:
            - ./form/form_div_layout.html.twig
        editor:
            storage:              null
        paths:

            # Prototype
            -
                path:                 ~
                namespace:            ~
    attributes:

        # Use custom attribute reader
        use_custom:           null
        paths:

            # Default:
            - %kernel.project_dir%/src/Attribute
    security:
        two_factor:

            # Roles whose holders must have a second factor (directly or through the role hierarchy), e.g. [ROLE_STAFF]. Empty: the administrator's "mandatory for everyone" setting alone decides. A later definition (when@dev, when@test, another file) replaces the list, it does not add to it.
            required_roles:       []

            # Whether the enrolment prompt offers a "not now" (kept for the session). False: an account a second factor is required of is sent back to the prompt on every page until it has one.
            postpone:             true
    demo:

        # The DSN of the production database ("mysql://host:3306/name"; user and password are not compared). The demo environment refuses to start on it - and refuses to start while this is unset.
        production_database:  null

        # The super-administrator's password in the demo environment: a secret (DEMO_SUPERADMIN_PASSWORD). Unset or empty: no account whose roles reach ROLE_SUPERADMIN can sign in there.
        superadmin_password:  '%env(default::DEMO_SUPERADMIN_PASSWORD)%'

        # The roles that open the back office. In the demo environment an account whose roles reach one of them is not offered to visitors - neither in the banner nor on the sign-in page - and signs in with base.demo.admin_password or not at all. Empty: the back office is as public as the rest of the demonstration.
        admin_roles:

            # Default:
            - ROLE_ADMIN

        # The password of the back office's accounts in the demo environment: a secret (DEMO_ADMIN_PASSWORD), given to whoever is shown the back office. Unset or empty: no account whose roles reach base.demo.admin_roles can sign in there.
        admin_password:       '%env(default::DEMO_ADMIN_PASSWORD)%'

        # Identifiers of declared demonstration accounts this site leaves out.
        exclude:              []
        reset:

            # Directories demo:reset empties before it reloads the fixtures: the files visitors sent to a storage of the application's own.
            purge:                []

            # The fixture groups demo:reset loads (doctrine:fixtures:load --group). Empty: every fixture.
            groups:               []

            # Whether demo:reset deletes the uploaded files no row names any more (uploader:entities --delete-orphans).
            orphans:              true
    opening_hours:

        # The timezone the hours are given in.
        timezone:             Europe/Paris

        # "HH:MM": past it, orderDay() is the next open day. Null: the day itself until it closes.
        cutoff:               null

        # The usual week until one is saved (hoursWeekDay): ISO day (1 = Monday) => [["09:00", "13:00"], ...].
        week:                 []
    local_business:

        # The schema.org type: LocalBusiness, or one of its kinds (Restaurant, Store, Dentist, ProfessionalService...).
        type:                 LocalBusiness

        # Null: the site's title (base.settings.title).
        name:                 null

        # Null: the site's home address.
        url:                  null

        # Null: the setting base.settings.phone.
        telephone:            null
        email:                null

        # A path under public/ ("assets/ico/android-chrome-512x512.png") or an address.
        image:                null

        # "€€", "10-50 €"...
        price_range:          null
        address:
            street:               null
            postal_code:          null
            locality:             null
            region:               null

            # ISO 3166-1 alpha-2: FR.
            country:              null
        geo:
            latitude:             null
            longitude:            null

        # The business elsewhere: its Facebook, Instagram, LinkedIn pages.
        same_as:              []
        area_served:          []

        # Any other schema.org property, merged as it is: {parentOrganization: {"@type": Organization, name: PANO}}.
        extra:                []
    guard:

        # The captcha: a gateway of omnishield.gateways. Null: omnishield.challenge.gateway when omnisense/omnishield is installed; false: none.
        challenge:            null

        # The captcha shown to a visitor who refused the third party the captcha reaches (consent): a gateway that reaches nobody, ALTCHA.
        fallback:             null

        # The lists asked about whoever submits (IP address, e-mail, name): gateways of omnishield.gateways - disposable, stopforumspam.
        reputation:           []

        # The classifier of what is written (SpamChecker): a gateway of omnishield.gateways. Null: Akismet with the key api.spam.akismet (base.spam.akismet) when omnishield/akismet is installed.
        classifier:           null

        # A list or a classifier that does not answer: the form goes on (accept) or is refused (reject). The captcha's is omnishield.challenge.unreachable.
        unreachable:          accept # One of "accept"; "reject"

        # Seconds between a guarded form being shown and sent: faster is a robot. 0: not checked.
        min_delay:            3

        # Failed sign-ins from an address before the sign-in form asks the captcha too. 0: never.
        sign_in_after:        3

        # Refused tries of a guarded form from a visitor (address, else session; 15 minutes) before its captcha is shown and asked. 0: always shown. A form sets its own with the option guard.captcha_after.
        captcha_after:        3
    signatures:

        # The gateway envelopes go through: one of omnisign.gateways. Null: the only one configured.
        gateway:              null

        # The private Flysystem storage the signed documents and their evidence are kept in. Null: the uploads' (base.uploader.storage).
        storage:              null
    comments:

        # Seconds between a comment form being opened and sent: faster is a robot.
        min_delay:            4

        # Seconds between two comments from the same address.
        flood_interval:       60
    vault:

        # #[Vault]: without the environment's key pair (bin/console secrets:generate-keys), store a secured field in clear instead of refusing it. Off: the save fails with VaultKeyNotFoundException.
        allow_plaintext:      false
    download_links:

        # Seconds a signed download link stays valid.
        ttl:                  600
    extension:

        # Max number of revision for a given entity
        max_revisions:        5

        # Time a trashed entity is kept before the purge may delete it for good: a relative date PHP reads ("+7 days", "+1 month"); a bare number is a number of days
        empty_trash:          '+7 days'

        # Default logging expiry
        logging_default_expiry: 180
    screens:

        # The version of the front end that renders the screens (omnibridge/react's X-Omnibridge-Version): a front end of another version reloads the page whole. Null: none checked.
        version:              null

Top level

database

share

A list of {id, url}. Deprecated, read by nothing: the sharing buttons come from the adapters tagged base.service.sharing (Base\Service\Model\Sharing\SharingAdapterInterface).

user

access_restriction

Who may see the site, checked by Base\Security\Voter\AccessVoter (see Routes and access).

site

router