Framework Settings Bundle Laravel Package

Getting Started

Reality check before you composer require: this is a Symfony bundle, not a Laravel package. It ships a Doctrine entity, a DI service, and (likely) Twig wiring — none of which Laravel will autoload or boot. With 1 star, 0 dependents, an archived repo, and a last release of March 2018, treat it as a reference implementation for a settings table, not a dependency you install into a Laravel app. The dependency cost alone (2018-era Symfony constraints vs. Laravel's Symfony 6/7 components) will usually make composer require fail outright.

If you still want to read it (recommended): clone the repo and open, in this order:

1. DependencyInjection/Configuration.php — what is actually configurable (entity class, cache, table name).
2. Resources/config/services.yml — the service ID and constructor args you'd inject.
3. Service/SettingsService.php (or similarly named) — the real public API: almost certainly get($name), set($name, $value), maybe has()/all().
4. Entity/Settings.php — the schema: typically id, name, value (and possibly type).
5. Resources/config/doctrine/*.orm.xml or entity annotations — mapping details, unique constraints on name.

Minimal Symfony steps (for context, not Laravel):

composer require sumocoders/framework-settings-bundle

// app/AppKernel.php (Symfony 2/3 era)
$bundles = [ new SumoCoders\FrameworkSettingsBundle\FrameworkSettingsBundle() ];

Then create the table — the bundle does not ship migrations you can trust in 2024+; generate one from the mapping (doctrine:schema:update --dump-sql, then hand-write a Laravel migration from that output).

First use case: application-level key/value settings edited by an admin — site name, contact email, "maintenance mode", an announcement banner. That is the entire scope of this bundle: a typed-ish key/value store with a service in front of it.

Laravel equivalent to start from today:

composer require spatie/laravel-settings

…or, if you only need a handful of values, a settings table plus a cached repository is ~60 lines and you own it. Use this bundle's SettingsService as the design sketch for that repository.

Implementation Patterns

Read-through cache (the core pattern to copy). The bundle's value is that you don't hit the DB on every get(). The service typically loads the full settings map once (per request, or into a cache pool) and serves get() from memory; set() writes through the entity manager and updates the in-memory map. Replicate this in Laravel:

class SettingsRepository
{
    private ?array $cache = null;

    public function all(): array
    {
        return $this->cache ??= Cache::rememberForever('settings', fn () =>
            Setting::pluck('value', 'name')->all()
        );
    }

    public function get(string $name, mixed $default = null): mixed
    {
        return $this->all()[$name] ?? $default;
    }

    public function set(string $name, mixed $value): void
    {
        Setting::updateOrCreate(['name' => $name], ['value' => $value]);
        Cache::forget('settings');
        $this->cache = null;
    }
}

Defaults live in config, DB overrides. Keep a config/settings.php with sane defaults and merge the DB values over it. This gives you a working app before anyone opens the admin screen, and it makes the settings list self-documenting. The Symfony bundle expects you to seed the table manually — don't; make defaults first-class.

Typed accessors. Store strings (that's what the old entity does) but never let raw strings leak into your app. Wrap with cast methods (getBool, getInt, getJson) or, better, spatie's typed settings classes where each setting is a declared property with a cast. "false", "0", and "" are the three values that will bite you.

Admin form pattern. Build one settings page with a FormRequest per group; on submit, loop the validated keys through set(). Batch the writes (single upsert + one cache invalidation) rather than N queries and N Cache::forget calls.

Feature flags. A features.* namespace in the same store works fine at small scale. If flags need targeting/percentages, this bundle (and a simple KV store) is the wrong tool — reach for a real flag service.

Multi-tenant. Namespace keys (tenant:{id}.site_name) or add a tenant_id column. The bundle has no concept of scope; if you adopt its schema as-is, you'll be retrofitting tenancy later.

Exposing to views. The bundle likely registers a Twig global. In Laravel use a view composer or a settings() helper backed by the cached repository — do not call the DB from Blade.

Porting checklist (Symfony → Laravel): entity → Eloquent model + migration; services.yml → service provider binding a singleton; Twig extension → helper/view composer; Doctrine cache → Laravel cache; Symfony config tree → config/settings.php.

Gotchas and Tips

• It will not install cleanly into a modern Laravel app. Laravel pulls Symfony 6/7 components; this bundle's composer.json targets Symfony 2/3 and PHP 7.x. Expect constraint conflicts, and do not --ignore-platform-reqs your way past them.
• Archived since 2018 = no security fixes, no PHP 8.2+ compatibility, no support. Anything you copy from it, you own forever. That's fine for a 100-line repository; not fine for a runtime dependency.
• No trustworthy migrations. Verify whether the repo ships a Migrations/ folder and whether it's Doctrine migrations (not Laravel). Hand-write the schema from the entity mapping, including the UNIQUE(name) index — the service's set() likely assumes upsert semantics.
• Everything is a string. Booleans read back as "1"/"0" or ""; if ($settings->get('maintenance')) is true for the string "false". Cast explicitly at the boundary.
• Cache invalidation is the whole ballgame. If you copy the read-through cache: forget on every write, and remember that queue workers, octane workers, and config:cache-style long-lived processes will hold stale values. Prefer Cache::rememberForever + explicit forget over request-scoped statics if you run Octane.
• Never store secrets here. Values are plaintext in the DB and often dumped into admin UIs and logs. API keys belong in .env/a secrets manager. If you must, encrypt the value column with Laravel's encrypted cast.
• Watch the admin surface. A generic settings editor invites users to break mail.from.address or a JSON blob with no validation. Validate per-key in the FormRequest; reject unknown keys.
• Debugging order for a Symfony install: bundle registered in the kernel → doctrine:schema:validate (mapping vs. actual table) → service ID exists in the container (debug:container) → cache cleared (cache:clear). Nine times out of ten it's the table not existing.
• Extension points worth stealing: the configurable entity class (lets you swap in your own model) and the service indirection (lets you decorate with caching/logging without touching call sites). Mirror both in your Laravel version — bind an interface, not a concrete class.
• Bottom line for a Laravel codebase: read it for the schema and the caching idea, then implement locally or use spatie/laravel-settings. There is no scenario where pulling a 2018 archived Symfony bundle into Laravel beats writing the 60-line repository.