Download the PHP package fedale/setting-bundle without Composer

Fedale Setting Bundle

Multi-tenant application settings stored in the database and editable at runtime — not Symfony parameters compiled into the container.

• Per-tenant fallback: tenant N → tenant 0 (global) → caller-provided default.
• Layered PSR-6 cache, automatically invalidated on every write.
• Abstract storage (SettingStorageInterface): a Doctrine ORM bridge is included, but it can be swapped (API, file, Mongo, ...).
• Free-form keys: no closed set, any string is a valid key.
• Optional per-key value validation, opt-in and enforced on every write.

Installation

Register the bundle (Symfony Flex does it for you):

Configuration (optional, defaults shown):

Database schema

The bundle auto-registers the ORM mapping of the Setting entity; generate the migration in your app with php bin/console make:migration. Equivalent schema:

tenant_id = 0 holds the global default configuration; tenant_id > 0 holds the per-tenant overrides.

value is stored as a string; type (string|int|float|bool|json) drives the (de)serialization: scalars stay human-readable (123, not "123"), complex values are stored as JSON under type = 'json'.

Usage

Reading settings in Twig

When TwigBundle is installed, the bundle registers a setting() function. It is read-only — writes are done in PHP via SettingsManagerInterface::set().

Signature:

Examples:

Key points:

• The key is a free-form string — any setting created at runtime (including from an admin UI) is readable, with no registration required anywhere.
• The per-tenant fallback applies: current tenant first, then tenant 0 (global), finally the default you pass in the template.
• The function exists only if Twig is installed. In a Symfony app with TwigBundle that is already guaranteed; registration is conditional, see FedaleSettingBundle::loadExtension().

Multi-tenant: resolving the current tenant

When tenantId is not passed, the bundle uses TenantProviderInterface. By default (DefaultTenantProvider) the current tenant is always 0. Multi-tenant apps register their own implementation:

Custom storage

To use a source other than Doctrine, implement Fedale\SettingBundle\Contract\SettingStorageInterface and point fedale_setting.provider at the service id. Caching and the per-tenant fallback are still handled by the bundle.

Validating values

By default keys are free-form: any value is accepted. You can opt specific keys into validation, enforced at the single write choke point (SettingsManager::set()), so the rules hold no matter where the write comes from — a form, a CLI command or plain code. Keys without declared rules stay free-form.

Validation builds on symfony/validator (install it: composer require symfony/validator). Declare the per-key constraints by registering a service that implements SettingConstraintsProviderInterface; the bundle ships ArrayConstraintsProvider for the common static-map case:

Then enable validation, pointing it at the provider:

Now a write that breaks a rule throws SettingValidationException instead of persisting:

For dynamic rules (e.g. constraints stored in the database or computed per key), implement SettingConstraintsProviderInterface directly instead of using ArrayConstraintsProvider. Return [] for any key that must stay free-form:

With autowiring, just point constraints_provider at the class id:

How the validation flow fits together

1. SettingsManagerInterface::set($key, $value, ...) is called (form, CLI or code).
2. Before persisting, the manager calls the configured SettingValidatorInterface.
3. With validation enabled, ConstraintsSettingValidator asks your provider for the constraints of $key. No constraints → the value is accepted (free-form).
4. Otherwise the value is checked with symfony/validator; on failure a SettingValidationException is thrown and nothing is written.

This means the rules are enforced once, at the single write choke point, so you cannot bypass them by writing from a different entry point.

Cache

The settings.0 and settings.{tenantId} layers are cached separately and merged in memory on each read. A set() only invalidates the layer it touches: changing a global default (tenant 0) therefore propagates to all tenants by invalidating a single entry.

License

MIT.