- Can I install modera/config-bundle in a Laravel application?
- No, not as a drop-in Composer dependency. The bundle assumes Symfony bundle registration, service container wiring, and Doctrine mapping, none of which map cleanly onto Laravel's config repository or service providers. A Laravel-native settings layer is the practical route.
- What does modera/config-bundle actually do?
- It provides a Symfony bundle for storing configuration properties in a database and resolving them at runtime. Each property can have handlers for defaults, validation, and form metadata. The transferable idea is a layered resolver that checks a stored value, then deploy-time config, then a hardcoded default.
- Does modera/config-bundle support Laravel 10 or Laravel 11?
- No. The package is a Symfony 2/3-era bundle with its last release in July 2016, so it predates modern Laravel and PHP versions. It has no Laravel service provider, facade, or config integration. Do not expect compatibility with Laravel 10 or 11.
- Is modera/config-bundle still maintained?
- No. The repository is marked read-only, has one star and zero dependents, and its last release was 2016-07-21. There is no active maintainer, security response process, or community to absorb bugs. Treat it as prior art rather than a dependency.
- What is a good Laravel alternative for database-backed application settings?
- A small Laravel-native settings layer is usually the best fit: an Eloquent settings table, a cached resolver with an explicit fallback chain, validation on write, and encryption for sensitive values. Bind a Settings abstraction in a service provider so application code never depends on a vendor class. Packages exist, but the core pattern is small enough to own.
- How should I implement runtime-editable configuration in Laravel?
- Start with a ConfigRepository contract and an Eloquent-backed implementation. Resolve values in a fixed order: database override, then deploy-time config, then a hardcoded default. Add validation rules per key, cache resolved values, and invalidate the cache on write via events.
- Does modera/config-bundle encrypt sensitive configuration values?
- The bundle does not solve secret encryption for a Laravel context, and its design stores properties through Doctrine without Laravel's encryption facilities. If you need credentials or API keys in a database-backed settings store, use Laravel's encrypter and never expose decrypted values in logs or admin listings. Also consider keeping high-risk secrets in environment or vault infrastructure.
- Can modera/config-bundle handle per-tenant configuration overrides?
- There is no documented per-tenant scoping that maps to Laravel multi-tenancy patterns. The package's property model is generic, but tenant isolation, authorization, and cache keying would all need to be built. A Laravel-native design should include tenant ID in the storage schema and cache keys from day one.
- How should I test a Laravel-native settings repository?
- Test the resolver's fallback order with unit tests: database value wins, then deploy-time config, then the hardcoded default. Use an in-memory SQLite database for repository tests and fake the cache to assert invalidation on write. Also test validation failures and authorization around writes, because those are the paths most likely to break production.
- How do I migrate from modera/config-bundle to a Laravel settings approach?
- Run a short discovery spike to read the bundle's manager, resolver, and property-handler contracts. Extract the defaulting and validation semantics, then reimplement them behind a Laravel ConfigRepository with Eloquent persistence and cache invalidation. Only build import tooling if you actually have existing stored configuration data to move.