Weave Code
Tomato Settings Module Laravel Package
tomatophp/tomato-settings-module
A Laravel settings module for the Tomato PHP ecosystem, providing a centralized interface to manage application settings and configuration values. Likely integrates with Filament admin panels for editing settings at runtime and storing them in the database.
Full Settings Generator / Manager with GUI
Frequently asked questions about Tomato Settings Module
- How do I install tomatophp/tomato-settings-module in a Laravel application?
- Install it with composer require tomatophp/tomato-settings-module, then publish the package config and migrations, run php artisan migrate, and clear config and cache. Because it is a TomatoPHP module, check whether the service provider pulls in registry or Filament dependencies before installing it in a plain Laravel app. Pin the exact v1.0.0 tag rather than a caret constraint until you have reviewed composer.json and the release diff.
- Do I need Filament to use this settings package?
- A meaningful share of the package value is its Filament admin resource for editing settings, so an API-only or Blade-only stack gets less out of it. The service provider may also hard-depend on TomatoPHP registry or admin classes, which determines whether partial adoption is possible. Inspect the provider and composer.json before assuming you can use the database layer on its own.
- Which Laravel and PHP versions does tomato-settings-module support?
- Version 1.0.0 declares its constraints in composer.json, and those constraints are the source of truth over any README compatibility table. The package targets the TomatoPHP ecosystem, which generally assumes Laravel 10 or 11 with Filament, so verify against your actual PHP minor and Filament major. Do not infer support from the vendor's other packages.
- How are settings stored and how is the cache invalidated?
- The package uses a database-backed key/value settings table with a Filament CRUD layer on top. Cache invalidation behaviour at v1.0.0 is not documented in the release notes, so confirm whether writes clear a shared cache store or only the local node. On multi-node deployments a per-node cache can silently diverge from the table.
- Can I store sensitive or encrypted settings with this package?
- Encryption at rest is not documented for v1.0.0, so treat stored values as plaintext until you verify otherwise in the code. If you need secrets, keep them in environment variables or a dedicated secrets manager, or add an encrypted cast yourself. Never assume the admin UI redacts values in the underlying database.
- Does tomato-settings-module support typed values or per-tenant settings?
- The documented shape is a general key/value settings store, and typed casts or tenant scoping are not called out in the v1.0.0 release. The schema is effectively an internal detail, so inspect the published migration before designing around it. If you need per-tenant overrides, plan to add a tenant column or scope yourself.
- Is v1.0.0 production-ready and what is the maintenance risk?
- v1.0.0 is the first tagged release and the available release artifact is thin, with no migration notes or explanation of what 1.0.0 means here. The package is also single-maintainer and coupled to the fast-moving Filament release cadence. Pin the exact tag, read the diff, and treat major-version bumps as unverified until a 1.1.x line exists.
- How does tomato-settings-module compare to spatie/laravel-settings?
- Spatie's package is a code-first, typed settings approach with settings classes and no admin UI, while this module is database-first with a Filament GUI. Choose this one if you want runtime editing by non-developers inside a TomatoPHP or Filament panel. Choose a code-first package if you want settings versioned in Git and no extra admin surface.
- How do I migrate existing config and env values into the settings table?
- Map every key you plan to move, and explicitly keep anything read during bootstrap, before the database connection is available, in config or env. Write a one-way export script from day one so the decision stays reversible. Test queue workers and scheduled jobs, which may boot before migrations or read stale cached values.
- How should I test settings changes safely in production?
- Test in a scratch app that matches your production PHP and Filament versions, using RefreshDatabase to verify migrations and a cache fake to check invalidation. In production, clear config and cache after writes and confirm all nodes share the same cache store. Avoid settings-driven changes that only take effect after a redeploy.
Weaver
How can I help you explore Laravel packages today?