Laravel config cache guard voor shared hosting

Wanneer een configuratiewijziging na deployment niet zichtbaar is, controleer je eerst de normale Laravel-configuratiecache en de werkelijk gebruikte runtime. Een fallbackpackage is geen vervanging voor een correcte deployment en moet binnen zijn gedocumenteerde beperkingen gebruikt worden.

Diagnosevolgorde: bevestig welke release en omgeving actief zijn, controleer hoe configuratie geladen wordt en volg de gecontroleerde cacheprocedure. Gebruik env-aanroepen niet als willekeurige runtimeconfiguratie buiten de daarvoor bedoelde configuratiebestanden.

• Scheid configuratiecache, routecache, viewcache en gewone applicatiedata.
• Controleer packagegedrag en compatibiliteit in de officiële repository vóór gebruik.
• Bewaar werkende publicaties en diagnoseer zonder geheimen of volledige environment-output te publiceren.

• Bron en verdere uitleg
• Laravel audit en technische hulp

Laravel wordt sneller wanneer configuratie en routes gecachet worden. Maar die deployment caches vragen discipline: als `.env`, `config/*.php` of `routes/*.php` wijzigt en de cache niet opnieuw gebouwd wordt, kan productie blijven draaien met oude waarden of oude routes.

`codegenie-be/laravel-config-cache-guard` is bedoeld als klein vangnet voor eenvoudige Laravel productieomgevingen. De actuele versie bewaakt zowel config cache als route cache en laadt automatisch via Composer. Het blijft een fallback, geen vervanging voor een goede deployment pipeline.

Waarom Laravel oude deployment cache blijft gebruiken

Na `php artisan config:cache` leest Laravel configuratie uit `bootstrap/cache/config.php`. Na `php artisan route:cache` leest Laravel routes uit een gecachet routebestand. Die bestanden zijn snel, maar ze veranderen niet vanzelf wanneer je bronbestanden wijzigt.

Wijzig je daarna bijvoorbeeld `APP_URL`, mailinstellingen, een feature flag of een routebestand, dan moet de relevante cache opnieuw gebouwd worden. De beste release-stap blijft dus expliciet:

Waarom dit vaak gebeurt op shared hosting

Op shared hosting of bij FTP-deployments is er niet altijd SSH, CI of een betrouwbare post-deploy hook beschikbaar. Bestanden worden geupload, maar artisan commands draaien niet altijd automatisch mee.

• Een `.env` waarde wordt apart via het hostingpaneel aangepast.
• Config- of routebestanden worden via FTP vervangen zonder artisan stap.
• Een deployment uploadt alleen gewijzigde bestanden.
• De applicatie blijft bereikbaar, maar gebruikt nog oude deployment cache.

Wat de package nu doet

De guard wordt niet meer handmatig in `public/index.php` geplaatst. De package gebruikt Composer `autoload.files`, waardoor de guard geladen wordt zodra Laravel `vendor/autoload.php` vereist en nog voordat `bootstrap/app.php` de applicatie opstart.

Daardoor kan de package vroeg controleren of bronmetadata veranderd is. Hij kijkt naar metadata van onder meer `.env`, optioneel `.env.{APP_ENV}`, `config/**/*.php`, `routes/**/*.php`, `bootstrap/app.php` en een bestaande `RouteServiceProvider` wanneer die aanwezig is.

Het belangrijke detail: de package leest geen `.env` secrets uit. De check gebruikt metadata zoals timestamps, bestandsgrootte en inode-informatie om te bepalen of de cache nog past bij de bronbestanden.

Hoe repair werkt

Als config cache bestaat en de config-signature wijzigt, probeert de guard met een file lock `php artisan config:cache` te draaien. Als route cache bestaat en de route-signature wijzigt, probeert hij `php artisan route:cache` te draaien.

Wanneer `exec()` en een PHP CLI binary beschikbaar zijn, kan dat al gebeuren voordat Laravel volledig bootstrapt. Dat is de meest directe weg: de request gaat verder met verse deployment cache.

Wanneer `exec()` niet beschikbaar is, gebruikt de package een veiligere fallback. Stale config cache wordt verwijderd, stale route cache wordt omzeild via een signature-based route cache path, en er wordt een interne pending marker geschreven.

Daarna boot Laravel zonder de oude deployment cache. Na de huidige HTTP-response kan de service provider de pending marker verwerken met Laravel's eigen `Artisan::call()`. Er is dus geen publieke repair-URL, token, queue, Redis of cron nodig.

Wat bewust niet automatisch gebeurt

• De package leest, logt of bewaart geen `.env` waarden.
• De package gebruikt geen Redis, queue, worker, cron, database of publieke repair endpoint.
• De package draait niet op elke request een rebuild.
• De package start route caching niet automatisch wanneer je app nog geen route cache gebruikt.
• De package draait geen `cache:clear`, `optimize:clear`, `view:clear` of `event:clear`.
• De package vervangt geen bewuste deployment pipeline.

Installatie

Voor nieuwe installaties volstaat Composer en een statuscheck. De oude installatiestap die een require-regel in `public/index.php` plaatste, is niet meer nodig.

Heb je een oudere versie gebruikt, dan kan `public/index.php` nog een legacy require-regel bevatten. Die lijn is idempotent, maar overbodig. Verwijder ze handmatig of laat de package ze opruimen:

Wanneer je dit wel en niet gebruikt

Gebruik de package vooral als extra veiligheidslaag bij shared hosting, FTP-deployments of kleine Laravel productieomgevingen waar post-deploy artisan stappen niet altijd gegarandeerd zijn. Voor shared hosting blijft dit een fallback zonder verplichte Redis, queue, worker of cron.

Gebruik ze niet als excuus om deployment hygiene los te laten. In een volwassen pipeline blijft de betere aanpak: build artifacts voorbereiden, `config:cache` en waar passend `route:cache` bewust draaien, smoke tests uitvoeren en deployment-evidence bewaren.

Praktische codevoorbeelden

php artisan config:cache
php artisan route:cache

composer require codegenie-be/laravel-config-cache-guard
php artisan config-cache-guard:status

php artisan config-cache-guard:install --remove-legacy --dry-run
php artisan config-cache-guard:install --remove-legacy

Samenvatting

Stale deployment cache is lastig omdat de site vaak blijft werken, maar niet met de configuratie of routes die je verwacht. De actuele `codegenie-be/laravel-config-cache-guard` bewaakt config cache en route cache vroeg via Composer autoload en kan op shared hosting terugvallen op interne auto-repair via `Artisan::call()`.

Voor productie blijft het uitgangspunt hetzelfde: gebruik de guard als fallback safety net, niet als vervanging voor een gecontroleerde releaseflow.