- How do I install Options for Laravel in a Laravel application?
- Install it with Composer using roundly-consulting/options-for-laravel. Laravel package discovery should register the service provider and facade; because options are database-backed, follow the README for any publish or migration step, then run your migrations.
- Which Laravel and PHP versions does Options for Laravel support?
- The supported Laravel and PHP versions are defined in the package's composer.json, so check that file rather than assuming continuity. Release 1.1.2 is a patch in the 1.1.x line and should remain semver-compatible, but patch releases can occasionally tighten constraints. Confirm the matrix before upgrading a production app.
- How do I store and retrieve an option using the facade or helper API?
- Use the provided facade or helpers to set an option and read it back anywhere in the app. Values are persisted in the database, so they survive requests and deployments, and reads benefit from cached lookups. Keep writes going through the package API so cached values stay consistent.
- Does Options for Laravel cache option lookups, and how do I avoid stale values?
- Yes, Options for Laravel caches lookups so repeated reads do not hit the database each time. Use the package's set, update, and remove methods as the normal path for changing values. If you edit option rows directly in the database, clear the relevant cache or go back through the API.
- How do default and fallback values work when an option is missing?
- The get API supports default and fallback values, so a missing option returns the value you specify instead of null. That lets you ship sensible defaults without seeding every option up front. It is useful for optional admin settings or environment-specific overrides.
- Can I swap the configured options model for a custom subclass in tests?
- The package resolves its options model through configuration, which lets host applications bind or subclass a different model. In tests, configure that model before creating records so factories and relationships target the swapped class. Release 1.1.2 specifically fixes factory construction so it instantiates the configured class rather than a hardcoded one.
- What changed in version 1.1.2 for test factories?
- It corrects the package's test factory so that when your app swaps the configured options model, the factory builds the swapped class. There is no implied schema, migration, or public API change. If your tests depended on factories always returning the original model, review any assertions on class identity, table names, or relationship targets.
- Is upgrading to 1.1.2 safe for production Laravel apps?
- Yes, 1.1.2 is a patch-level behavioral correction confined to test-time factory construction, so production runtime behavior should be unchanged. Bump the constraint and run your full test suite; no application code changes are expected. Track the changelog for future patch releases because small packages can still change construction semantics.
- How should I test an application that uses Options for Laravel and a custom options model?
- Use Laravel's normal factory and HasFactory conventions, and configure any custom options model before creating records. Add a test that asserts the factory returns your swapped class, since that is the path fixed in 1.1.2. If you decorate factories with other test helpers, smoke-test that combination because it touches the same construction path.
- When should I use Options for Laravel instead of config files or another settings package?
- Choose a database-backed options package when settings need to be edited at runtime by admins without deploying config changes. Config files are simpler for static, deploy-time values, while heavier settings packages may add typed settings classes or schema conventions you do not need. Options for Laravel stays lightweight with get and set methods, persistence, cached lookups, defaults, and Laravel integration.