Cache Flush Bundle Laravel Package

Getting Started

Know what you're adopting first. Last tagged release is 2016-12-28, one star, zero dependents. This is a Symfony 2.x/3.x-era bundle. Before writing any code, confirm your Symfony version — if you're on 4.4+, cache:clear, cache:pool:clear and cache:pool:invalidate-tags already cover most of what this bundle does.

Minimal setup on a compatible (legacy) app:

composer require mmoreram/cache-flush-bundle

// app/AppKernel.php  (no Flex recipe exists — manual registration only)
$bundles = [
    // ...
    new Mmoreram\CacheFlushBundle\CacheFlushBundle(),
];

No configuration tree is typically required; the bundle ships a service and console command out of the box. Verify with:

bin/console list | grep -i cache
bin/console debug:container | grep -i cache_flush

Where to look first. The bundle is small enough to read end-to-end in one sitting:

1. DependencyInjection/ — is there a Configuration.php? If not, there's nothing to tune.
2. Resources/config/services.yml — the service ID you'll inject or decorate.
3. Command/ — the actual entry point; the command name and options are the whole public API.
4. composer.json — check the symfony/* and php constraints before assuming compatibility.

First use case. A deploy hook. After your release symlink flips, call the bundle's flush command so compiled container/annotation/routing caches don't serve stale code from the previous release. That's the sweet spot: a one-liner in Deployer/Capistrano instead of rm -rf var/cache/* followed by a prayer.

Implementation Patterns

Deploy-script invocation. Treat the command as an idempotent post-deploy step:

// deploy.php (Deployer)
task('deploy:cache_flush', function () {
    run('{{release_path}}/bin/console cache:flush --env=prod -vvv');
})->desc('Flush application caches');

Wrap it in your own app:deploy:post command rather than calling the vendor command name directly everywhere — it gives you a single seam to swap in native cache:clear later.

Programmatic flushing. Inject the flusher service into your own command or controller when you need invalidation tied to a domain event (content publish, import completion, config change):

public function __construct(private CacheFlusherInterface $flusher) {} // verify the real FQCN in services.yml

public function onContentPublished(ContentPublishedEvent $e): void
{
    $this->flusher->flush(); // keep this out of the request path
}

Prefer triggering from a console command or a queued message over doing it inline in a web request — flushing during a request is a latency and race-condition trap.

Compose, don't couple. Wire the flush into a kernel event listener or a messenger handler that runs after your write transaction commits. Never flush on kernel.request or per-entity save.

Environment separation. Only enable the bundle in prod and dev service definitions where it's actually needed; keep it out of test so your test suite doesn't nuke shared caches mid-run.

Fallback-first integration. Since the package is unmaintained, code against your own thin wrapper:

interface CacheInvalidator { public function invalidate(): void; }

with a bundle-backed implementation and a native-Symfony implementation. If the bundle breaks on a PHP upgrade, you swap one service definition.

Gotchas and Tips

Maintenance risk is the headline. 2016 last release, one star, no dependents means: no Symfony 4/5/6 support, likely no autowiring aliases, likely AppKernel-only registration, and probable deprecations or fatals on PHP 7.4+/8.x. Pin the exact version, run composer why-not symfony/framework-bundle and composer why-not php before adding it. Seriously consider copying the ~100 lines into your own src/ instead of taking the dependency.

cache:clear vs. flush is not the same thing. Flushing removes cached artifacts; it does not warm them. On a cold prod box always follow with bin/console cache:warmup. A flush-then-first-request pattern produces a thundering herd on large apps.

Permissions are the classic failure. Running the flush command as root in deploy creates root-owned cache files, and PHP-FPM (running as www-data) then fails to write. Run the command as the same user as the web server, or fix ownership afterwards. On shared/NFS filesystems, cache dir deletion races are common.

Opcache and APCu are invisible to this bundle. Clearing filesystem caches doesn't reset opcache or APCu. On deploy you still need opcache_reset() (via cachetool, a PHP-FPM reload, or opcache.file_cache clearing). If the bundle has an APC/APCu flusher, verify it actually reaches the FPM pool — CLI APCu is a separate segment and flushing from CLI does nothing for the web process.

Multi-node deployments. The bundle flushes the node it runs on. If you have three app servers, you need three invocations — one per host in your deploy playbook — or a fan-out through a queue. Don't assume a single flush propagates.

Debugging a missing command. If bin/console doesn't list it: bundle not registered in the kernel, or a symfony/symfony version constraint silently excluded it during composer update. Check composer show mmoreram/cache-flush-bundle and bin/console debug:container --tag=console.command.

Extension points are thin. With little or no configuration tree, the practical customization paths are (a) decorating the service via services.yml, (b) a compiler pass, or (c) forking. Because the bundle is tiny, forking into App\Cache\ is usually cheaper than fighting DI.

Audit for side effects before trusting it in prod. Read the command's execute() once. Some 2016-era flushers recursively delete directories derived from container parameters — confirm it never touches paths outside var/cache and that it respects kernel.cache_dir.