>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3610368. --> Reported by: [mandclu](https://www.drupal.org/user/52136) Related to !14 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p><code>EventPlatformHeaderCtaBlock</code> renders content that varies based on the Event taxonomy term identified from the URL. To handle this, the block declares the <code>url.path</code> cache context, which is the standard best practice when content varies by URL.</p> <p>However, <code>url.path</code> is far more granular than this block needs. Drupal stores one render-cache variation per <strong>unique full path</strong>, so every distinct URL the block appears on gets its own cached copy &mdash; including deep event paths, non-event pages, and invalid/junk paths. In practice the block's content only differs by the identified Event term, which is derived from a path shaped like <code>/events/{event_name}...</code>. All other paths could share a single variation.</p> <p>The result is a large number of redundant, near-duplicate cache entries that waste storage and reduce cache efficiency, with no functional benefit.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Install Event Platform Helper and place the Event Platform Header CTA block.</li> <li>Enable a render cache debug header (e.g. set <code>http.response.debug_cacheability_headers: true</code> in <code>services.yml</code>).</li> <li>Visit several URLs where the block appears: multiple event pages (<code>/events/event-a</code>, <code>/events/event-b</code>), deep paths under one event (<code>/events/event-a/schedule</code>, <code>/events/event-a/speakers</code>), and several non-event pages.</li> <li>Observe that the block produces a separate render-cache entry for every unique path, even where the resolved Event term (and therefore the rendered CTA) is identical.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Introduce a custom cache context, <code>event_name</code>, that normalizes the request to a token rather than the raw path:</p> <ul> <li>URLs resolving to the same Event term share one variation (token <code>event:{tid}</code>).</li> <li>All non-event and invalid-event URLs collapse to a single shared <code>none</code> variation.</li> </ul> <p>This reduces the variation count from "one per unique URL" to "one per valid Event term, plus one."</p> <p>Components:</p> <ul> <li><strong>An <code>EventResolver</code> service</strong> (<code>EventResolverInterface</code> + implementation) that maps an event slug/path segment to its Event <code>taxonomy_term</code>, with per-request static caching and a persistent slug&rarr;tid map tagged <code>taxonomy_term_list:event</code>, so resolution is an in-memory lookup on a warm cache. This centralizes the term-resolution logic currently embedded in the block so both the rendered output and the cache token derive the event the same way.</li> <li><strong>An <code>EventNameCacheContext</code></strong> service (tagged <code>cache.context</code>, service id <code>cache_context.event_name</code>) that returns <code>event:{tid}</code> or <code>none</code>, and exposes <code>taxonomy_term_list:event</code> as cacheable metadata so adding/removing Event terms invalidates dependent entries.</li> <li><strong>Block changes:</strong> replace <code>url.path</code> with <code>event_name</code>. Because <code>BlockViewBuilder</code> establishes the block's render-cache keys from <code>getCacheContexts()</code> before <code>build()</code> runs in a <code>#pre_render</code> callback, a context bubbled up from the <code>build()</code> render array triggers a cache "redirect" (two backend reads per render). The context is therefore declared in <code>getCacheContexts()</code> rather than in the render array returned by <code>build()</code>. The block should also bubble the resolved term's own cache tags (<code>taxonomy_term:{tid}</code>) so edits to an event's content invalidate the stored markup.</li> </ul> <p>Because a cache context is evaluated on every request (including cache hits) to compute the cache key, <code>getContext()</code> is kept cheap via the resolver's static + persistent-map caching. Collapsing invalid slugs to <code>none</code> also prevents crawlers or malicious requests from inflating the variation count with garbage paths.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Confirm the Event vocabulary machine name and how the <code>{event_name}</code> path segment maps to a term (term name, dedicated slug field, or URL alias), and align the resolver's slug logic with the block's existing behavior.</li> <li>Add <code>EventResolverInterface</code>, <code>EventResolver</code>, and <code>EventNameCacheContext</code> with service definitions.</li> <li>Update <code>EventPlatformHeaderCtaBlock</code> to inject the resolver, declare <code>event_name</code> in <code>getCacheContexts()</code>, remove <code>url.path</code>, and bubble the resolved term's cache tags.</li> <li>Add kernel test coverage (token collapse for non-event and invalid paths, stable token across deeper paths under one event, distinct tokens per event, and presence of the <code>taxonomy_term_list:event</code> invalidation tag).</li> <li>Decide whether block content also varies by a second path segment (e.g. <code>/schedule</code> vs <code>/speakers</code>); if so, extend the token to include it.</li> <li>Manually verify via cache debug headers that deep paths under one event reuse the same cached block.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None.</p> <h3 id="summary-api-changes">API changes</h3> <p>Additive only. Introduces a new <code>event_platform_helper.event_resolver</code> service (<code>EventResolverInterface</code>) and a new <code>event_name</code> cache context (<code>cache_context.event_name</code>). The block no longer declares the <code>url.path</code> cache context, replacing it with <code>event_name</code>; this is an internal cacheability change with no change to the block's rendered output.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p>