Blogr Laravel Package

Getting Started

This package lets you keep Laravel configuration values in the database and override the file-based config at runtime. The v2.6.1 release is a bug-fix release focused on making that override safe under php artisan config:cache; there are no new APIs to learn, but there is an important operational behavior change.

Start by:

1. Install and publish the package assets:

   composer require <vendor>/<package>
   php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>"
   

2. Run the published migration:

   php artisan migrate
   

3. Open the package config file in config/ and define the settings you want to be editable. These file values are the defaults and the fallback when no database override exists.
4. Seed or create a setting through the package’s model/facade/UI, then read it with normal Laravel config access:

   config('app.some_setting');
   

The first practical use case is editable application settings: site name, feature flags, mail-from addresses, third-party keys, or per-environment toggles that operations teams need to change without a deploy. Put safe defaults in the config file, let the database hold overrides, and read everything through config() in your application code.

Look first at:

• the published config file, to understand which keys are overridable;
• the settings table/migration, to see the stored shape;
• the package service provider, to confirm when overrides are applied;
• bootstrap/cache/config.php after running config:cache, to confirm your file defaults are what got compiled.

Implementation Patterns

File defaults plus database overrides. Treat the config file as the source of truth for defaults and the database as the override layer. Do not put environment-specific secrets only in the database if your deploy process expects them in config files. This package is best for values that are safe to persist and change at runtime.

Read through config(), not the package model. In application code, prefer:

config('services.third_party.key');

rather than querying the settings table directly. That keeps call sites identical to normal Laravel config usage and lets the package apply its override logic in one place.

Use it behind a settings screen or admin command. A common workflow is to expose only a whitelisted set of keys in an admin UI, validate writes against the config file’s known keys, and provide a “reset to file values” action. The v2.6.1 release specifically fixes reset behavior: reset now clears the compiled configuration so file values are served immediately.

Deployment workflow with config caching. In production, continue to use:

php artisan config:cache

The correct model after v2.6.1 is:

• config:cache compiles the file-based defaults;
• database overrides are applied at runtime for real requests;
• stored settings are no longer frozen into bootstrap/cache/config.php.

This means you can safely use config:cache and still edit settings without rebuilding the cache.

Tests. Use RefreshDatabase for the settings table and clear config cache state between tests if you assert on compiled config. If your test suite runs config:cache, assert that database overrides are visible in HTTP/request contexts, not necessarily in every console context.

Feature flags. For lightweight flags, define defaults in config:

// config/features.php
return [
    'new_checkout' => false,
];

Then store an override and read:

if (config('features.new_checkout')) {
    // ...
}

Keep flag names stable and avoid deleting config keys that still have database rows; clean up both sides.

Queues and commands. If settings affect background jobs, verify them explicitly in a queue-worker context. The v2.6.1 fix scopes overrides to real requests so they cannot be baked into the compiled config. Do not assume a console command sees the same overridden values as an HTTP request without testing it.

Gotchas and Tips

config:cache used to freeze database settings into the compiled config. Before v2.6.1, running php artisan config:cache booted the application, applied database overrides, and wrote those values into bootstrap/cache/config.php. The compiled file then outranked the table, so deleting a setting or pressing “reset to file values” appeared to do nothing until the next cache rebuild. If you are upgrading, run:

php artisan config:clear
php artisan config:cache

once after deploying v2.6.1 so any previously frozen values are removed from the compiled file.

Stored settings are no longer baked into the compiled configuration. This is the intended behavior, but it is a behavioral change. If you previously relied on bootstrap/cache/config.php containing the database values, that will no longer be true. Runtime requests apply overrides; the compiled file contains file defaults.

Settings are read once per request. The package now avoids a persistent cache entry for the settings list. That prevents a stale cache from being repopulated with values read just before a save, which could keep a deleted setting alive. The trade-off is that you should not expect cross-request cache invalidation semantics; each request reads the current state from the database (memoized for that request). If you write a setting and immediately read it in the same request, verify the result in your application flow.

Reset clears compiled configuration. “Reset to the file values” now clears the compiled config cache as part of the reset. That is what makes the file values visible immediately, but it also means the next request may run without bootstrap/cache/config.php until it is rebuilt. In production, plan for that: either accept the temporary uncached state or rebuild config cache as part of your operational runbook.

Do not cache settings yourself. Avoid wrapping config('...') reads in your own long-lived cache if the value is meant to be editable. The package’s per-request read model is designed to avoid stale values; an application-level cache can reintroduce the same class of bug.

Watch console and queue contexts. The fix applies overrides “for real requests only” so that config:cache cannot capture them. If your settings must influence queue workers, scheduled commands, or other long-running console processes, test those entry points directly. Long-running workers may also need a restart or explicit refresh strategy after settings change.

Debugging checklist.

• Confirm the row exists in the settings table.
• Run php artisan config:clear and inspect bootstrap/cache/config.php only after a fresh config:cache.
• Check whether the key is present in the published config file; many packages only override known keys.
• Confirm you are reading the same config key the package writes.
• In HTTP vs. console contexts, compare config('your.key') output to isolate request-scoping behavior.

Extension points. Use the package’s config file to define the overridable key list, use model events or an admin controller for validation, and keep a small service/action class around writes and resets so you can audit changes. If you need encrypted settings, cast them in your own model layer or store encrypted values before handing them to the package; do not assume the package encrypts arbitrary values.

Upgrade risk is low but operational. v2.6.1 is a patch-level bug fix, not an API-breaking release. The main risk is assuming the old compiled-config behavior still applies. Clear and rebuild config cache after upgrading, and re-test any reset workflow and any queue/command path that depends on overridden settings.