Redis Config Laravel Package

Getting Started

oro/redis-config is a small OroPlatform package whose sole job is to register Redis-backed cache adapters as Symfony cache pools so OroPlatform's cache layer can use Redis instead of the filesystem. It is not a general-purpose Redis client wrapper; it is a configuration shim between OroPlatform's cache manager and Symfony's symfony/cache (typically via predis/phpredis).

Where to look first

1. README.md and the package's Resources/config/oro/packages.yml (or bundles.yml, depending on how it registers itself) — this tells you the package name and how OroPlatform discovers it.
2. The DI extension / service definitions (Resources/config/services.yml or DependencyInjection/*Extension.php) — this shows the service IDs of the Redis cache adapters and the config keys they consume.
3. Any Tests/Unit/DependencyInjection fixtures — usually the shortest path to learning valid config shapes.

Minimal steps to a working setup

composer require oro/redis-config
php bin/console cache:clear --env=prod

Then in your OroPlatform config/config.yml (or app/config/config.yml on older versions) point the relevant cache backend at Redis:

framework:
    cache:
        pools:
            oro.cache.provider:
                adapter: cache.adapter.redis
        default_redis_provider: 'redis://127.0.0.1:6379/0'

Ensure Redis is reachable (redis-cli ping → PONG) and that you have either the redis PHP extension or predis/predis installed.

First use case

The most immediate win is swapping OroPlatform's app cache (annotations, config metadata, Doctrine result cache) off the filesystem so that a multi-node deployment shares a single cache tier. Start by validating a single pool — e.g. oro_cache_doctrine_* — before moving all pools to Redis.

Implementation Patterns

Per-pool rollout. Rather than forcing every cache pool onto Redis at once, target pools individually. This is the safest pattern for an initial adoption because it isolates failures and lets you benchmark before scaling up:

services:
    oro.cache.redis_provider:
        class: Symfony\Component\Cache\Adapter\RedisAdapter
        arguments: ['@redis.connection', 'oro:app:']

Environment-driven DSNs. Keep the Redis URL out of committed YAML. Use an env var and reference it in default_redis_provider: '%env(REDIS_URL)%'. This is essential because the package predates Symfony's cache.adapter.redis_tag_aware and doesn't ship first-class credential handling.

Separate logical databases or key prefixes per environment. Because OroPlatform shares the Redis instance across dev/test/prod, use database indexes or a namespace prefix (oro::{env}::) so cache:clear in dev doesn't nuke production metadata. Symfony's cache.adapter.redis accepts a namespace argument for exactly this.

Wiring into Oro's cache manager. OroPlatform resolves cache pools via its cache manager configuration (oro.cache.manager). If the package exposes a Redis-capable manager pool, register it there rather than overriding framework cache directly:

oro_cache:
    manager:
        pools:
            my_custom_pool:
                provider: redis

Integration with Doctrine / annotations. Once Redis is the provider, configure Doctrine's result cache explicitly:

doctrine:
    orm:
        result_cache_driver:
            type: service
            id: oro.cache.redis.provider

Testing locally. Run a disposable Redis with docker run --rm -p 6379:6379 redis:7-alpine. Because the package was last released in 2020, always verify against the Redis version your OroPlatform install targets — protocol differences between Redis 5 and 7 (e.g. HELLO, RESP3) can surface with older predis versions.

Gotchas and Tips

Maintenance status is the biggest risk. Last release was 2020-08-14, and the dependency is pinned against whatever Symfony cache version OroPlatform shipped then. Before adopting, run composer why oro/redis-config and composer update --dry-run to confirm it resolves cleanly against your current symfony/cache and OroPlatform version. If symfony/cache has moved past the package's allowed constraint, you may end up forcing a version conflict.

License ambiguity. The repo reports NOASSERTION. Oro packages are typically OSL-3.0; confirm this with legal before shipping to a commercial customer. A missing license header is common in Oro's older packages.

Cache clear semantics. cache:clear is not a Redis FLUSHDB unless you wire it that way. OroPlatform's cache warmer populates namespaced keys; a manual FLUSHDB will desync the container cache and can force a full rebuild in production. Prefer namespaced pools with per-pool clear() over global flush.

Serialization mismatches. If different PHP versions or nodes write to the same Redis key with different serializers (e.g. one using igbinary, another using plain serialize), you get unreadable cache hits and silent misses. Pin serializer in the adapter config and verify consistency across the fleet.

Connection handling. predis opens a new TCP connection per request unless you use a persistent connection or the phpredis extension. On high-traffic Oro instances this is a real cost; prefer phpredis (the redis PHP extension) when available and set timeout/read_write_timeout conservatively.

Debugging tips.

• redis-cli --scan --pattern 'oro*' | head to see what the package is actually writing.
• redis-cli MONITOR on a staging box to catch unexpected key churn during a page load.
• If cache misses are mysteriously high, check that your default_redis_provider DSN's database index matches what the app actually reads from — a common off-by-one when /0 vs /1 is set in different config files.

Extension points. The package's DI extension is the natural override point. If you need custom TTLs or a different Redis client, define your own service extending RedisAdapter (or implementing AdapterInterface) and alias it over the ID the package registers. Prefer this over forking the package, since the upstream is dormant and your patch won't be merged.

When not to use it. If your OroPlatform deployment is single-node with modest traffic, the filesystem cache is fine and you gain nothing but a new failure mode (Redis availability) by introducing this package. Reserve it for multi-node or high-write scenarios where a shared cache tier is actually required.