we are experiencing a caching-related bug when using the ‘disable block’ feature introduced in recent ACF Pro versions in combination with a Redis object cache (e.g. via the redis-cache plugin).
Setup:
– ACF Pro flexible content field with multiple layout blocks
– Page builder pattern: blocks are defined as reusable layouts (e.g. ‘text’, ‘gallery’)
– ‘text’ layout: single textarea field
– ‘gallery’ layout: repeater field containing an image and url field
– Redis object cache active on the production server
Page structure used for reproduction:
Row 0: text
Row 1: text
Row 2: gallery
Row 3: gallery
Expected behavior:
Disabling individual blocks (rows) should not affect the field data or row indices of remaining enabled blocks.
Actual behavior:
When one or both ‘text’ blocks are disabled, the row index resolution for subsequent ‘gallery’ blocks breaks — but only on servers with Redis object cache enabled. The issue does not reproduce in a local environment without object caching.
Reproduction cases:
– Disable row 1 (second text block): row 2 (first gallery) renders correctly; row 3 (second gallery) renders the data of row 2 instead of its own.
– Disable row 0 (first text block): both gallery blocks (rows 2 and 3) render incorrect or identical data.
Hypothesis:
The row index used for cache key generation is likely based on the absolute block position in the flexible content array. When a block is disabled and presumably skipped or removed from the active index, the cached field values for subsequent rows are retrieved using stale or shifted cache keys — resulting in wrong data being returned for those rows.
This suggests the cache key for flexible content sub-fields does not account for the disabled state of preceding blocks, causing an index mismatch between the cached entries and the actual rendered rows.
No issues observed without object cache (local environment, no Redis).
