Laravel Settings Laravel Package

Getting Started

Begin by installing the package via Composer (composer require qcod/laravel-settings) and publishing its config and migration files (php artisan vendor:publish --tag=settings-config and php artisan vendor:publish --tag=settings-migrations). Run the migration to create the settings table. After setup, start using the package immediately:

// Set a value
Settings::set('app.name', 'My Awesome App');

// Get a value (with optional default)
$appName = Settings::get('app.name', 'Default Name');

// Or use the global helper (if registered)
settings()->set('maintenance.mode', true);
$maintenance = settings()->get('maintenance.mode', false);

The default implementation stores settings in the settings table with key, value, and optional section columns. Start with simple scalar values (strings, ints, bools), then explore structure support (see Implementation Patterns).

Implementation Patterns

• Section-based organization: Group related settings under sections for clarity and isolation:

  Settings::set('mail.sender_name', 'Support', 'mail');
  Settings::get('mail.sender_name'); // null — must specify section or use `section()` scope
  Settings::section('mail')->get('sender_name'); // 'Support'
  

• Defaults via get(): Use fallbacks for graceful handling of missing keys, especially during deployments or new tenant onboarding.
• Caching strategy: Enable caching in config/settings.php (default: file driver), then clear cache only when needed:

  // Clear all settings cache
  app(\Qcod\Settings\SettingsManager::class)->flush();
  

• Admin panel integration: Use in form requests or controllers to persist user-facing config without redeploy:

  public function update(Request $request)
  {
      Settings::set('site.twitter_handle', $request->input('twitter'));
      Settings::set('site.enable_comments', $request->filled('comments'));
      return back()->with('success', 'Settings saved.');
  }
  

• Multi-tenant support: Leverage the optional tenant_id column (add to migration) to isolate settings per tenant in SaaS apps.

Gotchas and Tips

• Serialization caveats: Complex types (arrays/objects) are automatically serialized. When retrieving, ensure type consistency — Settings::get('some.array') will return a deserialized array, not a JSON string. Avoid storing closures or resources.
• Missing helper registration: The settings() helper isn’t auto-bootstrapped unless settings.php config includes it. Add 'helpers' => true in config if you rely on the global helper.
• Cache key collisions: Caching uses keyed prefixes like settings:global:. In multi-tenant apps, double-check that tenant-scoped settings are correctly isolated—don’t share DB between tenants without tenant_id.
• Migration customization: The provided migration uses a generic value column (TEXT). If storing large JSON blobs (e.g., API configurations), alter the column to LONGTEXT or JSON (MySQL 5.7+) for performance.
• Event-driven cache invalidation: Set up observers on your Setting model (or hook into Settings::updated) to fire custom events for cache warming or sync to external systems (e.g., Redis, Consul).
• Debugging tips: Enable debug in config to log all get/set operations, and run php artisan settings:clear to reset the cache cleanly. Use Settings::all() for quick inspection of current state.