ornicar/apc-bundle
Ornicar APC Bundle integrates Alternative PHP Cache (APC) with Symfony applications, providing cache services and tools to store, retrieve, and clear cached data. It helps speed up PHP apps by reducing repeated computations and database queries.
Start by reading the one-line description again: this is a Symfony bundle, explicitly unmaintained, and points to smart-core/accelerator-cache-bundle as its successor. From a Laravel developer's perspective, that's the headline. There is no Laravel integration path here — no service provider, no config/cache.php driver, no facade. Leveraging it "day-to-day" in a Laravel app really means not putting it in a Laravel app.
The only honest getting-started path is for a legacy Symfony 2.x codebase you've inherited and are trying to keep alive:
composer require ornicar/apc-bundle — expect this to fight modern Symfony/PHP constraints; the bundle targets ~2.x.app/AppKernel.php:
new Ornicar\ApcBundle\OrnicarApcBundle(),
php -m | grep apc). This is APC, not APCu — they share a name prefix and almost none of the same story on PHP 7+.Resources/config/services.xml after install. That file, plus the DI extension, is effectively the entire package. Inject the service it declares rather than calling apc_*() in your code.First use case: the bundle exists to register a configured cache service in Symfony's container so controllers and services can fetch()/save() without hardcoding extension calls, or so Doctrine's ApcCache adapter gets a wired-up implementation. If you want a "first win," it's injecting that service into whatever consumed apc_fetch() previously.
Where to look first: the DI extension and services.xml. If the service you want isn't declared there, there is nothing else to learn — this is a registration wrapper, not a library with an API.
For a Laravel project, the first stop is config/cache.php and the Cache facade. If you have an APCu-shaped requirement, target a maintained PSR-6/PSR-16 adapter or a small custom store — not this bundle.
public function __construct(Cache $cache) { $this->cache = $cache; }
apc_fetch() sprinkled through controllers is the thing that makes migration painful later.catalog.v3.product.42 and bump the version segment to invalidate a whole slice at deploy time.save($key, $value, $ttlSeconds) maps directly to apc_store. There is no default TTL, no tag invalidation, no "forget" cascade — you own expiry.Doctrine\Common\Cache\Cache if you can. If surrounding code already speaks the Doctrine cache interface and uses the APC driver, keeping that contract means your eventual swap to AcceleratorCacheBundle or symfony/cache is a config change, not a refactor.AppCache interface (or a tiny class) that owns every apc_* call. That single seam is the whole migration path later and costs nothing today.CacheWarmer is a natural place to precompute data on deploy — but only if CLI and FPM actually share the cache (see Gotchas).Cache::extend() driver or bind a PSR-16 adapter, and treat anything APC-shaped as a single-node fallback behind Cache::store('array') semantics. Do not add this bundle to a Laravel composer.json.smart-core/accelerator-cache-bundle (APCu) or symfony/cache directly.apc.enable_cli=1 is required for console commands and warmers to populate the same cache the FPM worker reads. This is the #1 "the cache is always cold" bug with this bundle. Confirm before you build around it.php.ini. FPM pool config and CLI config often differ. Verify apc.enabled, apc.shm_size, and apc.enable_cli with phpinfo() per SAPI — not just in the shell.CacheItemPoolInterface. You get array-style fetch/store/delete. Any framework-native abstraction you want must be your own thin adapter.apc_store starts failing under churn, you're hitting apc.shm_size/apc.ttl limits and fragmentation. Watch apc.php stats before chasing it in application code.cache:clear that touches this.CompilerPass or an alias in app/config/services.yml. Use that — do not edit the vendor copy.AcceleratorCacheBundle stays a clean swap.How can I help you explore Laravel packages today?