- Can I install matthimatiker/opcache-bundle in a Laravel application?
- No, not usefully. It is a Symfony bundle that registers services, compiler passes, a Profiler DataCollector, and Twig toolbar templates through FrameworkBundle, none of which has a registration path in Laravel. Composer will either fail to resolve or force an untenable downgrade, because the bundle's symfony/* constraints target the Symfony 2.x/3.x era while Laravel 9+ requires Symfony 6.x/7.x. At best you get an inert vendor directory.
- What does this Symfony OPcache bundle actually do?
- It wraps PHP's native OPcache functions, exposing cache status and reset operations through Symfony services and console commands. From that raw data it derives hit rate, memory used and free, cached and wasted script counts, and restart counters. It also registers a DataCollector into the Symfony Profiler with a Twig toolbar panel. The genuinely reusable part is the small framework-agnostic logic around opcache_get_status() and opcache_get_configuration().
- How do I clear OPcache in Laravel without installing this package?
- Call opcache_reset() directly from an Artisan command, a deployment script, or a guarded route. Always check opcache_get_status(false) first, since opcache_reset() is a no-op or blocked when OPcache is disabled or opcache.restrict_api is set. Keep the reset behind auth and a local-only environment check so it is never publicly reachable.
- How do I check OPcache status and hit rate in Laravel?
- Use opcache_get_status(false) to get memory usage, cached and wasted script counts, hit rate inputs, and restart counters, and opcache_get_configuration() for the directive values. Wrap those calls in a small singleton repository class and optionally expose them through a route, a Blade partial, or a Debugbar collector. There is no need for a third-party runtime dependency; these are native functions available on PHP 8.1+.
- Why does php artisan opcache:status show an empty or missing cache?
- CLI and FPM run separate PHP processes with separate OPcache instances, so Artisan, queue workers, and web requests each report their own cache. You will only see CLI-side data when opcache.enable_cli=1 is set. Also, opcache_get_status() returns false when OPcache is disabled and is blocked entirely by opcache.restrict_api, so your UI must degrade gracefully rather than throw.
- Which Laravel and PHP versions is this bundle compatible with?
- None directly, because it is not a Laravel package and declares Symfony 2.x/3.x constraints that conflict with Laravel 9+ on Symfony 6.x/7.x. The collector also predates PHP 7.4 preloading and PHP 8 JIT, so its memory accounting and key assumptions may misreport on modern runtimes. Target Laravel 10 or 11 on PHP 8.1+ only after porting the logic to native function calls.
- Is it safe to expose OPcache status and statistics in production?
- Risky by default. The panel exposes absolute filesystem paths of cached scripts, OPcache configuration directives, and the memory layout, which is a security review item rather than a feature. Restrict any such view to the local environment, behind authentication and environment middleware. If fleet-wide visibility is needed, use an APM tool with a support contract instead.
- How do I add OPcache metrics to Laravel Debugbar or Telescope?
- Write a custom collector rather than adding a dependency. For Debugbar, implement BarCollectorInterface and read from a singleton repository that wraps opcache_get_status(false); for Telescope, register a watcher that records the same array. Most Laravel estates already run one of these, so the OPcache panel becomes a small addition alongside queries and request data.
- How much effort is porting this bundle's OPcache logic to Laravel?
- Roughly one to three days for a mid-level engineer. The steps are: vendor in the collector extraction logic as an internal class, the MIT license permits this if you retain attribution; register a ServiceProvider binding a singleton status repository; expose it via a local-only authenticated route, Blade view, or Debugbar collector; add an opcache.enable guard with a graceful disabled state; and document the CLI versus FPM divergence.
- Is this package maintained, and what are the alternatives?
- It is effectively abandoned: around 22 stars, zero dependents, and no release cadence, so assume no security response and no PHP 8.3/8.4 hardening. For application performance visibility, Tideways, Blackfire, and New Relic offer supported coverage that OPcache counters cannot match. In a Laravel context this package is a feature to reimplement, not a dependency to adopt.