Filament Dynamic Settings Page Laravel Package

Getting Started

composer require ibrahim-bedir/filament-dynamic-settings-page
php artisan vendor:publish --tag="filament-dynamic-settings-page-migrations"
php artisan migrate

Optionally publish the config (--tag="filament-dynamic-settings-page-config") to change the settings table name, cache key prefix, or storage driver.

Register the package's page (or plugin) in your Filament panel provider:

->plugin(\IbrahimBedir\FilamentDynamicSettingsPage\FilamentDynamicSettingsPagePlugin::make())

or, if you are extending the base page manually, add your page class to ->pages([...]).

Create a settings page by extending the package's SettingsPage base class and defining the form schema with Filament components (TextInput, Toggle, Select, FileUpload, etc.). Each field's name becomes the persistent settings key. Load the panel and navigate to the registered page — you should see a single "Save" action that persists the form state to the settings table.

First use case: global, non-tenant application settings — site name, logo, support email, feature toggles, SEO defaults. This is the package's sweet spot; anything more relational (per-user preferences, per-team config) needs extra scoping work (see below).

Implementation Patterns

• Group by domain, not by type. Use Filament Tabs or Section components to break settings into "General", "Mail", "Branding", "Integrations". The package stores keys flat, so grouping is purely presentational — keep naming prefixes (mail.from_address, branding.logo) consistent so lookups stay predictable.
• Read settings via the provided helper/service, not by querying the table directly. Wrap access in a small app-level service (app(SettingsService::class)->get('mail.from_address', $default)) so tests can swap the implementation and you can add casting/caching in one place.
• Cache aggressively. Settings are read on nearly every request but written rarely. Cache the whole bag under a single key and bust it in the page's afterSave hook (or an observer on the model). A Cache::rememberForever + explicit forget on write is usually enough.
• Type the values explicitly. Booleans, arrays (from CheckboxList / Repeater), dates, and file paths all come back as JSON-decoded scalars or strings, not necessarily the type you expect. Add a cast map in your accessor service rather than relying on the storage layer.
• Seed defaults in a seeder that mirrors the schema's default values. This keeps fresh environments and CI from rendering empty forms and makes the "reset to defaults" behavior trivial to implement.
• Authorize access. Override canAccess() / canViewAny() on your page so only admins see it in the navigation. It is easy to forget because the page auto-registers.
• Per-tenant / per-team settings are not a first-class feature. If you need them, key your values by a tenant id prefix (tenant.42.branding.logo) and gate reads through a resolver that prepends the current tenant. Do not try to add a tenant_id column to the published migration without also patching every read path.

Gotchas and Tips

• Filament version pinning. The last tagged release is June 2023, right around the Filament v3 launch window. Check composer.json constraints before installing in a v3 or v4 panel; if it only declares ^2.0 or ^3.0, you may need --with-all-dependencies and manual verification. Do not assume forward compatibility.
• Maintenance risk. 27 stars, a single maintainer, no release in over a year. Treat this as a vendored dependency: pin the exact version, and be prepared to fork if a Filament upgrade breaks Form or Page APIs. The migration and one page class are small enough to inline into your app if you want to drop the dependency later.
• Migration collisions. The published migration creates a settings table; if you already use spatie/laravel-settings, filament-spatie-settings, or a hand-rolled settings table, rename via the config before migrating. Two packages writing to settings with different column shapes is a painful debug.
• Cache staleness is the #1 bug. Saving in the panel updates the DB but not your cached bag unless you wire the invalidation. Symptom: "I changed the logo and it didn't update until I ran php artisan cache:clear." Add the forget call in the same request as the save.
• File uploads leak. Uploaded logos/favicons are stored on the configured disk but the old file is not deleted on replace. Add cleanup in a beforeSave or model observer, and configure a dedicated disk/folder so cleanup is bounded.
• Validation only runs on the settings page. Values written via seeders or console commands bypass the form's ->rules(). If a downstream service trusts the value shape (e.g. an enum or a URL), re-validate at the consumption site or add a custom cast that throws.
• config:cache interaction. If the package reads config at boot for cache prefix or table name, run php artisan config:clear after editing published config or your changes will appear to have no effect in local dev.
• Extension point: override the base page's getFormSchema(), getSettingsKey() (if present), and the save/reset action methods rather than editing vendor files. That keeps forks to a single page class when the package falls behind Filament.