Backend Tools Settings Bundle Laravel Package

Getting Started

First, orient yourself correctly: there is no Laravel package here to install. modera/backend-tools-settings-bundle is a Symfony 2/3-era bundle (DI extension + compiler pass + a Sonata-style controller), last tagged 2016-06-10, published READ-ONLY, with 0 stars and 0 dependents. Do not expect composer require modera/backend-tools-settings-bundle to resolve against a Laravel 10/11/12 app — its constraints pin PHP 5.6/7.0-era code and symfony/* ^2.8|^3.0, and its compiler pass touches Definition APIs that were removed in Symfony 4. Running it on Laravel is not an integration problem, it's a rewrite.

Where to look first (source, not docs). There is no README-level documentation. Read in this order:

1. The bundle class (ModeraBackendToolsSettingsBundle::class) — see what it registers into the kernel and what services it exposes.
2. The DI extension / compiler pass — this is where modules "tag" their settings providers; that tag is the whole contract.
3. The Settings service/registry interface — the method(s) a module implements to contribute a section.
4. The controller + routing for the Backend / Tools → Settings screen — this shows how registered sections are rendered.

Your first (and probably only) use case on Laravel: clone the pattern, not the code. Spend 30 minutes reading the source to understand the registration contract, then build a native Laravel equivalent:

// app/Contracts/SettingsSection.php
interface SettingsSection {
    public function key(): string;      // 'mail', 'billing'
    public function label(): string;    // "Email"
    public function view(): string;     // Blade view name
    public function rules(): array;     // validation rules
}

Bind a SettingsRegistry singleton in a service provider, populate it from config('settings.sections'), and render one admin page that loops over them. That is the entire value proposition of this bundle, translated to Laravel primitives, and it's a day of work — roughly the same effort as getting the original to boot on a 2016 stack.

Do this before writing code: confirm whether the project is actually on a legacy Modera/Symfony stack (in which case this is plumbing you inherit, not a choice) or a Laravel app (in which case the answer is "reference only, do not vendor"). Those two paths diverge completely and should not be conflated.

Implementation Patterns

Since you will almost certainly be re-implementing the pattern rather than depending on the bundle, these are the patterns the source demonstrates, expressed as what you'd build in Laravel.

1. Registry + tagged contributions (the core contract). The bundle's model: a host exposes a named section; modules register a panel into it. Native Laravel analogue:

// AppServiceProvider::register()
$this->app->singleton(SettingsRegistry::class, function ($app) {
    $registry = new SettingsRegistry();
    foreach (config('settings.sections', []) as $class) {
        $registry->register($app->make($class));
    }
    return $registry;
});

Tag sections via a config array (simple, works with config:cache) or use Laravel's tag()/tagged() container bindings if you want discovery without a config file. Config-array is the more cache-friendly, more debuggable choice.

2. Thin controller, one Blade page, section partials. Mirror the bundle's single "Backend/Tools → Settings" screen. One route, one controller (index + update), one Blade layout that @includes each section's view. Sections own their form fields and validation rules; the registry owns ordering and visibility.

3. Per-module validation, host-owned persistence. The bundle is a UI/registration layer — it does not persist, validate, encrypt, audit, or scope settings. In Laravel, put those in the section contract (rules()) and a SettingsStore service (a settings table with key/value/type, or use spatie/laravel-settings if you want typed, cacheable settings out of the box). Keep the registry and the store separate so you can swap either.

4. Authorization at the section level. The original hangs off an admin-adjacent "Backend / Tools" menu, which is a real privilege-surface concern. In Laravel, give each section a Gate/Policy check (Gate::allows('settings.update', $section->key())), gate the route, and don't assume "admin" covers it — payment, auth, and integration credentials deserve their own abilities.

5. If you are on legacy Modera/Symfony and must consume the bundle. Register it in AppKernel, ensure modera/backend-tools-bundle is present, and let downstream modules tag their providers via the compiler pass. Wrap it behind your own SettingsProvider interface immediately so no application code imports Modera classes — this is what makes a later replacement (native registry, or a move to Laravel) cheap. Then treat it as a known migration-debt item with an owner and a removal date.

6. Sequencing that actually works. Spike (half a day: does the container even compile on your PHP/Symfony?) → build the adapter seam → migrate one real settings section end-to-end as the reference → only then decide whether to onboard the rest or retire it. Do not onboard every module before one section has proven the path.

Gotchas and Tips

The Laravel gotcha is the whole assessment. Symfony bundles do not map onto Laravel service providers without a rewrite: compiler passes have no equivalent, services.xml isn't a thing, and the Sonata-style admin controller isn't a Blade component. There is no shim that makes this a "Laravel package" — anyone proposing it as one is confused about the ecosystem.

Composer will fight you even on Symfony. Expect the install to fail on php and symfony/* constraints. --ignore-platform-reqs may get composer install to finish; it will not make the code run on Symfony 4+. Budget a real spike day before committing to anything, and don't read a successful composer install as a green light.

Container compile failure is the highest-risk failure mode. Because the integration is a compiler pass, a framework upgrade can break the entire app boot — not just the settings screen. That failure blocks every deploy, which is why this pattern's unmaintainedness compounds quickly. Keep it behind an adapter so it fails in isolation, not at php artisan (or bin/console) time.

Silent settings loss is the second. Provider registration order and cache warmup affect what renders. Build a health check (a route or artisan command that asserts every registered section resolves) rather than discovering gaps after a deploy.

No persistence, validation, crypto, RBAC, multi-tenancy, or audit trail. The bundle exposes sections; it is not a settings engine. If your PRD includes encrypted secrets, per-tenant overrides, typed schemas, or change history, none of that comes with this — decide explicitly whether you're building it in Laravel (spatie/laravel-settings covers typed storage and caching; auditing and RBAC are yours) or deferring it.

Config cache vs. dynamic registration. If you mirror the config-array registry, remember php artisan config:cache freezes settings.sections. Use a config array rather than runtime registration so this is predictable; if you need plugin-style discovery, use tagged() and document that it bypasses config:cache semantics.

Debugging tips. If you fork/consume the original: log what the compiler pass registers (debug:container --tag=… on Symfony), read the DI extension before the controller, and set APP_DEBUG/kernel.debug=true so container rebuilds surface errors during development rather than in production deploys.

Extension points you'll likely want beyond the original. Add per-section ability checks, a SettingsStore contract so tests can fake persistence, and a SectionRendered/SettingsUpdated event so other modules can react (e.g. re-warm caches after a mail setting changes). None of these exist upstream; they're the "own it" part of the build.

Bottom line for day-to-day work: treat this repository as a reference design document, not a dependency. Read it for the registration contract, then spend a sprint building a native Laravel registry with a thin contract (key, label, view, rules), authorization per section, and a swappable storage layer. That gives you the bundle's only durable idea — one discoverable settings hub — with none of the 2016 Symfony baggage, and leaves an adapter-shaped seam so the decision is reversible.