Laravel Simple Setting Laravel Package

Getting Started

• Requirements for v1.3.0 are Laravel 11 and a newer PHP (8.2+). This is the only substantive change in the release — everything else is Dependabot noise (GitHub Actions bumps). The public API is unchanged from v1.2.0, so this is a compatibility decision rather than a feature upgrade.
• composer require elipzis/laravel-simple-setting then publish and run the migration:

  php artisan vendor:publish --tag=setting-migration   # or --provider="ElipZis\Setting\SettingServiceProvider"
  php artisan migrate
  

  Publishing the config (config/setting.php) is worth doing up front so table name, model binding and caching options are explicit in your repo rather than package defaults.
• First use case: a small settings table of key/value pairs for site-wide toggles and editable copy — maintenance banners, feature flags, contact details, default pagination size — read through the Setting facade:

  use ElipZis\Setting\Facades\Setting;
  
  Setting::set('site.maintenance', true);
  Setting::get('site.maintenance', false); // second arg as default
  Setting::has('site.maintenance');
  

• Before writing any code, read the migration stub and the Setting model. The stored value column type and any casting behaviour determine how you'll handle booleans, arrays and numbers, and that shapes everything downstream.

Implementation Patterns

• Namespace your keys. The package has no concept of groups or scopes beyond what you encode in the key. Adopt a dotted convention early (billing.currency, mail.from_address, features.new_checkout) and use a small Settings wrapper class or enum of known keys so typos don't silently return defaults.
• Wrap the facade behind your own service. A thin App\Support\Settings class with typed accessors (bool(), int(), array()) keeps the package dependency in one place and gives you a migration path off it later.

  class Settings
  {
      public static function bool(string $key, bool $default = false): bool
      {
          return filter_var(Setting::get($key, $default), FILTER_VALIDATE_BOOL);
      }
  }
  

• Seed defaults via a seeder, not at read time. Calling Setting::set() lazily on first read races under concurrency and pollutes the table with half-configured rows. Put initial values in a SettingSeeder and only read with defaults in application code.
• Expose writes through a form request + explicit allow-list. Never bind arbitrary request keys to Setting::set() — a hidden input in an admin form shouldn't be able to overwrite billing.secret. Validate against your known-key enum, then write in a loop.
• Cache aggressively at the app layer if reads are hot. Settings are frequently read in service providers, Blade layouts and middleware — i.e. many times per request. Wrap reads in Cache::rememberForever() keyed per setting and clear on write. If the package itself offers caching in config/setting.php, enable it, but verify it is invalidated on set()/remove() before trusting it.
• Bootstrapping in providers. Because settings are DB-backed, reading them inside register() will break on a fresh install (no table yet) and during migrate. Read them in boot() and guard with Schema::hasTable('settings') or a try/catch if you must touch them early.
• Testing. Use RefreshDatabase and seed the settings your test needs in setUp(). Since reads are cached, call Cache::flush() in tearDown() or per test, otherwise leakage between tests produces confusing failures.
• Multi-tenant workaround. If you need per-tenant settings, the simple path is a key prefix (tenant.{id}.feature) rather than schema changes; a tenant_id column would require forking the model and migration.

Gotchas and Tips

• Laravel 11 / PHP bump is the breaking point. If your app is still on Laravel 10 or PHP 8.1, pin "elipzis/laravel-simple-setting": "^1.2" and skip v1.3.0 entirely — there is nothing to gain from the upgrade other than the framework bump. Check composer.json in the release to confirm the exact constraints before upgrading in a shared codebase.
• Direct DB writes bypass any package cache. If an ops script or a second app writes to the settings table, the package (and your wrapper cache) will keep serving stale values. Treat Setting::set()/remove() as the only write path, or add an explicit cache-bust hook.
• null vs false vs "0". The value column is typically a string column, so Setting::get('flag', false) can return the string "0", which is truthy in a naive if. Always cast on read; the typed wrapper above is not optional if you store booleans.
• Arrays, objects and enums need serialisation. Decide once: either json_encode on write and json_decode on read, or don't store them at all. Mixed conventions across a team lead to values that decode for one key and not another.
• Check the column length. If value is a VARCHAR(255), long JSON blobs, HTML snippets or API keys will silently truncate (or throw, depending on strict mode). Publish and adjust the migration to text early — altering it later on a large table is annoying.
• Config caching surprises. php artisan config:cache freezes the config values, so changing the table name via env at deploy time requires a cache clear. Same for any cache TTL settings.
• Deleting a key doesn't restore a default. Setting::remove() removes the row; subsequent get($key, $default) returns your default, which may differ from the value the app ran with before. Fine, but be deliberate about it in migrations of settings.
• Extension points are limited by design. The package is a thin model + facade. For anything richer (typed settings, groups, per-tenant scoping, audit trail) you're better off writing a small repository around the Setting model and using the package only for the storage/migration than trying to extend its internals — especially given the release cadence here is dependabot-driven.