- How do I install Blogr in a Laravel application?
- Install the package with Composer, publish its configuration and migrations, then run the migrations against your application database. Blogr provides a FilamentPHP admin interface, so your Laravel app should already have a compatible FilamentPHP setup. After installation, verify the admin panel and public blog routes in a staging environment before deploying.
- Which Laravel and PHP versions does Blogr support?
- The provided overview does not pin exact Laravel or PHP version constraints, so check the package composer.json and README for the authoritative matrix. Blogr is Laravel-native and integrates with FilamentPHP, so your framework and Filament versions must both be compatible. Validate the package in staging against your Laravel version, PHP version, database driver, and cache driver before upgrading production.
- Does Blogr require FilamentPHP?
- Blogr provides a FilamentPHP admin interface for managing blog content, so FilamentPHP is part of the expected setup for the admin experience. Confirm the supported FilamentPHP version range in the package documentation before installing. The public blog side may be usable independently, but the full package workflow assumes Filament is available.
- How does Blogr handle Laravel config:cache and database-backed settings?
- Blogr overlays file-based configuration defaults with database-backed runtime settings. Version 2.6.1 fixes a config-cache interaction where stored overrides could be written into bootstrap/cache/config.php and then outrank the settings table. The fix keeps compiled configuration aligned with Laravel expectations: config:cache represents deploy-time configuration, not mutable database state. After upgrading, clear and rebuild Laravel caches and verify that database overrides still take precedence for real requests.
- Why do Blogr setting deletes or reset-to-file-values not work?
- This can happen if an older 2.6.x release wrote database overrides into bootstrap/cache/config.php, causing compiled configuration to outrank the settings table. Clear compiled configuration, run the relevant Laravel cache-clearing commands, and rebuild config:cache after upgrading to 2.6.1. In multi-node deployments, make sure every node or shared cache path is refreshed. Then retest deletion and reset-to-file-values behavior.
- Are Blogr runtime settings applied in queue workers and artisan commands?
- Version 2.6.1 applies database overrides for real requests rather than globally, so queue workers, artisan commands, and scheduled jobs may not see the same runtime settings as HTTP traffic. Use file-based configuration as the baseline for those contexts and pass explicit values where needed. Test your specific worker, scheduler, and console paths before relying on Blogr settings there.
- Is Blogr compatible with Laravel Octane?
- Long-running workers such as Laravel Octane should be restarted after deploying Blogr upgrades to avoid stale in-memory state. Because 2.6.1 changes when database-backed settings are applied and reads the settings list once per request, validate the behavior under your Octane request lifecycle. Clear caches, rebuild config:cache, and restart Octane workers as part of deployment.
- How should I deploy Blogr across multiple nodes?
- Deploy the updated Composer dependencies to every node, run any documented migrations once, and clear or rebuild Laravel caches consistently across the fleet. The reset-to-file-values path clears compiled configuration, but the provided context does not guarantee that it clears every node automatically. Coordinate cache clearing per node or via a shared cache path, and restart queue workers or Octane workers after deployment.
- What happens if the database is unavailable when Blogr boots?
- The provided context does not specify the exact failure behavior when the database is unavailable during request boot. Because 2.6.1 reads the settings list once per request, request startup may depend on database availability for database-backed overrides. Add health checks, keep safe file-based defaults, and test database-outage scenarios in staging before relying on Blogr in production.
- What should I test after upgrading to Blogr 2.6.1?
- Test config:cache generation, database override precedence, setting deletion, and reset-to-file-values behavior. Also cover artisan commands, queue workers, scheduled jobs, health checks, and Octane-style long-running workers, since 2.6.1 changes where overrides are applied. For multi-node deployments, verify cache clearing and compiled configuration refresh on every node. Include database-unavailable boot behavior if your application depends on runtime settings during requests.