Filament Record Settings Laravel Package

Getting Started

Install the package via Composer, then publish its config and migrations using php artisan vendor:publish (use --force only when you intend to overwrite existing files). Run php artisan migrate.

Where to look first: the README sections added in v1.0.1 cover defaults order, glorand defaults, create vs edit filling, array keys, no-policy behaviour, and --force. The CHANGELOG documents the policy and validation fixes.

First use case: define a settings class (or use the package’s built-in settings) and update it through the package’s settings action rather than writing your own update logic. The action handles authorization via an updateSettings policy check and validation. A minimal controller method might call the action’s update method with the request data.

Implementation Patterns

• Use the settings action in controllers and form requests. It centralises policy checks and validation, so you don’t repeat them.
• If you need custom authorization, you can still call ->authorize() yourself before invoking the action. As of v1.0.1 the action’s internal updateSettings policy check survives your own ->authorize() call.
• For dynamic fields, use ->recordSetting() on the action. Validation failures from glorand $settingsRules now appear under the corresponding field, so standard Laravel error display works.
• When building create vs edit forms, follow the README’s guidance on filling behaviour. The action distinguishes between creating and editing settings, and defaults are applied in a documented order.
• Store settings that contain arrays and access them by array key as described in the README. This avoids surprises when merging defaults or validating nested values.
• Use the --force flag when republishing config or migrations after an upgrade, but only when you are prepared to overwrite local changes.

Gotchas and Tips

• Policy checks: The action’s updateSettings policy check is now compatible with your own ->authorize() calls. If you previously worked around double-authorization, you can remove that workaround. If no policy is defined, review the README’s “no-policy behaviour” section before relying on the action.
• Validation display: Glorand $settingsRules failures on ->recordSetting() fields are shown under the field in v1.0.1. Make sure your Blade template uses the correct error bag and field names.
• Defaults order: The order in which defaults are applied (package defaults, glorand defaults, class defaults) matters. Read the README’s “defaults order” and “glorand defaults” sections to avoid unexpected values.
• Array keys: When settings contain arrays, use consistent keys. The README explains how array keys are merged and validated.
• --force: This flag overwrites published files. Use it deliberately, especially in production.
• Debugging: If authorization or validation behaves unexpectedly, check the v1.0.1 CHANGELOG entries—they describe the exact fixes for policy checks and field-level validation errors.