Weave Code
Tomato Settings Laravel Package
tomatophp/tomato-settings
A Laravel settings package for managing editable key-value configuration in the database, with a simple API for reading and updating app settings at runtime—ideal for dynamic options and admin panels.
Full Settings Generator / Manager with GUI
Frequently asked questions about Tomato Settings
- How do I install tomatophp/tomato-settings in a Laravel app?
- Install it with Composer using composer require tomatophp/tomato-settings, then publish any package migrations and config as documented and run php artisan migrate. Use the provided facade, helper, or repository API to read and write settings. Because release notes are thin, verify service provider registration and config keys after install, then smoke-test reads and writes in staging.
- Does tomato-settings support typed values and defaults for settings?
- The package is described as providing key-value settings with typed values and sensible defaults. In practice, define each setting's expected type and default explicitly in your settings taxonomy rather than relying on implicit casting. Test invalid and missing values so defaults remain deterministic across environments.
- Can I scope settings globally or per tenant or environment?
- The overview mentions global and scoped settings support, so you can model app-wide values and narrower scopes. The exact scoping dimensions, such as tenant, role, or environment, must be confirmed against the package API and schema before you design around them. Keep a repository wrapper so scope rules stay in your codebase.
- How does caching work and how do I avoid stale settings?
- Cached retrieval is a stated feature, but multi-server and queue-worker deployments can see stale values unless writes invalidate the relevant cache keys. Confirm the package's invalidation behavior and test it with your cache store, including Redis or database cache if used. Add deployment and write-path tests for settings updates.
- Is tomato-settings compatible with Laravel 10 or Laravel 11?
- The supplied context does not include a Laravel or PHP version compatibility matrix, so check the package composer.json and README before committing. It is a May 2024 v1.x release with low adoption, so validate it against your Laravel version in a branch. Do not assume long-term support for newer Laravel releases.
- Can I use tomato-settings with Filament or the TomatoPHP admin panel?
- It is a strong fit if you already use Filament or the TomatoPHP admin ecosystem, where settings CRUD and UI conventions can reduce custom admin work. If you use a different admin stack, expect to build your own settings UI and authorization around the package API. The package itself should be treated as the storage and retrieval layer, not the admin product.
- Is tomato-settings a good feature flag or secrets management alternative?
- No. It is an application-level settings manager for editable key-value configuration, not a cross-service feature-flag platform, experimentation system, or secrets manager. Use dedicated flag and secret-management services for targeting, high-QPS evaluation, audit-grade rotation, and encryption. Keep sensitive secrets outside the database settings table unless you have validated encryption and access controls.
- How should I structure settings access in application code to avoid lock-in?
- Wrap package calls behind your own settings repository or service so controllers, jobs, and Blade views do not call helpers directly everywhere. That abstraction lets you add validation, authorization, caching rules, and defaults in one place. It also preserves a migration path to an in-house table or another package if maintenance becomes a problem.
- What are the maintenance and production risks of using tomato-settings?
- The main risks are low adoption, thin maintenance signals, and the chance your team becomes the de facto maintainer if settings become business-critical. DB-backed settings exposed in an admin UI also need server-side authorization, audit logging, and careful exclusion of sensitive values. Cached reads add consistency risk across multiple app servers and workers, so test invalidation before rollout.
- How do I test settings changes and cache invalidation in Laravel?
- Test reads, writes, defaults, invalid values, and cache invalidation in feature tests that use your real cache driver where practical. Include a multi-process or queue-worker scenario if production runs more than one node. Also test authorization around any settings admin UI so ordinary users cannot change operational behavior.
Weaver
How can I help you explore Laravel packages today?