Settings Bundle Laravel Package

Getting Started

The first thing a Laravel developer needs to internalise: swp/settings-bundle is a Symfony bundle, not a Laravel package. composer require swp/settings-bundle inside a Laravel app will drag in Symfony components and expect a container that Laravel never boots. There is no service provider, no facade, no config/settings.php in Laravel's shape. So "getting started" from a Laravel seat means one of two things:

1. You are actually in a Symfony codebase (SWP itself or a fork), where the bundle is designed to run.
2. You are reading it as a reference implementation for the "DB-backed settings" problem in a Laravel app.

If you are in Symfony (the intended environment):

• composer require swp/settings-bundle
• Register it in AppKernel::registerBundles() (or config/bundles.php on Symfony 4+).
• Import the bundle's config/routing per its README and run the Doctrine schema/migrations — settings are persisted as entities, so a table is created.
• Inject the settings manager/service into a controller or console command and start reading/writing values.

If you are in Laravel: do not install it. Treat it as a spec. The useful first use case it demonstrates is storing site-wide or per-namespace configuration (site name, feature toggles, editor defaults) that editors change without a deploy.

Where to look first in the repo: the bundle's Entity/, Repository/, and Manager/ (or Service/) directories, plus the DI extension class — that reveals the service IDs and the config tree you would mirror in config/ and a SettingsRepository.

Implementation Patterns

Manager-as-service (Symfony). The core pattern is a settings manager resolved from the container and injected into consumers. Reads/writes go through that service rather than touching the entity manager directly, so caching and type coercion happen in one place.

Namespace + key addressing. Settings are typically grouped by namespace (site, theme, or feature area) and addressed by key within that namespace. When you port this to Laravel, preserve that shape:

Schema::create('settings', function (Blueprint $t) {
    $t->string('namespace')->default('core');
    $t->string('key');
    $t->text('value')->nullable();
    $t->string('type')->default('string');
    $t->timestamps();
    $t->unique(['namespace', 'key']);
});

Read-through cache. The day-to-day win of a settings bundle is not the storage — it is that settings lookups are cheap. Wrap the repository in a Cache::rememberForever("settings:{$namespace}") layer and bust it on write. Without this, every page render hits the settings table several times.

Seeding defaults. Ship defaults in code/config and reconcile them into the DB on boot or via a command. This gives you sane behaviour on a fresh install and a migration path when a new key is introduced. In Laravel this is a SettingsSeeder plus a settings:sync artisan command.

Typed values. Values stored as text need coercion on read (bool, int, json). Centralise casting in the accessor so consumers never call (bool) on a string that might be '0'.

Integration tips for Laravel translation:

• Keep secrets and deployment-time config in .env / config/*.php. Put only editor-tunable values in the DB.
• Expose a Settings facade or a bound singleton (app(Settings::class)) so consumers mirror the Symfony injection pattern.
• If you have a Symfony and Laravel app side-by-side, read the same settings table from both — the namespace/key/value schema is portable even if the code isn't.

Gotchas and Tips

• It is a read-only subtree split. The repository is a mirror of a directory inside the main Superdesk Web Publisher repo. Pull requests and issues filed against swp/settings-bundle are not the source of truth — go upstream.
• Effectively unmaintained. Last release was 2018-06-08, with a single star and zero dependents. Treat it as archival: pin the version, and if you genuinely need it, vendor or fork it.
• PHP constraints. A 2018-era bundle targets PHP 7.x. Expect --ignore-platform-reqs gymnastics on PHP 8.1+ and test Doctrine compatibility carefully.
• Doctrine is baked in. The entities and repositories assume Doctrine ORM. Laravel's Eloquent will not map to them; the ORM boundary is the main reason this cannot be dropped into a Laravel app.
• Cache invalidation is the classic bug. "I changed the setting and nothing happened" is almost always a stale cache layer, not the database. Check the row first, then the cache, then the query log.
• Debugging recipe: query the settings table directly for the namespace/key you expect; if it is present, suspect cache; if absent, suspect a write path that swallowed an exception or a transaction that rolled back.
• Do not store secrets here. Settings surfaced in an admin UI are the wrong home for API keys and credentials — those belong in env/config.
• Extension points: if you need new value types or admin forms, the bundle's form/type classes are where you would extend it — but given its age and support status, extending it is usually more work than porting the ~200 lines of concept into your framework of choice.