fix(SiteSearch): URL-mapped content renders same HTML for all contentlets due to page cache collision - #34879
Merged
Conversation
…ache collision for URL-mapped content (#34130) HTMLPageAssetAPIImpl.getHTML() never set WIKI_CONTENTLET_INODE, causing VelocityLiveMode to build identical cache keys for all contentlets of the same URL map content type — returning the first rendered HTML for all. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
gortiz-dotcms
approved these changes
Mar 11, 2026
dsilvam
approved these changes
Mar 13, 2026
spbolton
pushed a commit
that referenced
this pull request
Mar 24, 2026
…lets due to page cache collision (#34879) Closes #34130 ### Proposed Changes * Set `WebKeys.WIKI_CONTENTLET_INODE` in `HTMLPageAssetAPIImpl.getHTML()` method. `VelocityLiveMode.buildCacheParameters()` reads `WIKI_CONTENTLET_INODE` as a component of the page cache key. Since it was always null, every URL-mapped contentlet of the same content type produced an identical cache key — so the first contentlet's rendered page was cached and returned for all subsequent ones. With the fix in place, the page cache key is unique per contentlet, so there are not cache collision for different URL mapped items. * A new test method `urlMapGeneratesDifferentHTMLPerContentlet` has been added to `URLMapBundlerTest` class. The test that creates two URL-mapped contentlets with distinct field values, runs the bundler, and asserts each generated HTML file contains its own unique value. ### Checklist - [x] Tests Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
riccardoruocco
pushed a commit
to riccardoruocco/core
that referenced
this pull request
May 14, 2026
… URL 200-forwards (dotCMS#35696) (dotCMS#35704) ## What does this PR do? Fixes a page cache key collision where multiple vanity URL 200-forward requests routed to the same detail page all shared an identical cache key. The first request warmed the cache and every subsequent request — regardless of the actual incoming URL — received that cached response. Closes dotCMS#35696 ## Why is this a problem? `VelocityLiveMode.buildCacheParameters()` composed the cache key from `pageUrl` (the forwarded-to path), `pageInode`, `vanityUrlId`, etc. — none of which differ between `/store/123/acme/catalog/` and `/store/456/globex/catalog/` when both forward to the same page via the same vanity URL rule. On multi-node clusters with round-robin load balancing, different nodes cached different affiliates' content under the same key, causing wrong content on every other request for the full TTL duration (up to 1 hour). ## What is the fix? When `VANITY_URL_OBJECT` is present on the request and `isForward() == true`, include `RequestDispatcher.FORWARD_REQUEST_URI` as an `originalUri:` component in the cache key. This is the original browser URL set by Tomcat when CMSFilter forwards to VelocityServlet via `RequestDispatcher.forward()`. ```java String originalRequestUri = (request.getAttribute(VANITY_URL_OBJECT) != null && ((CachedVanityUrl) request.getAttribute(VANITY_URL_OBJECT)).isForward()) ? (String) request.getAttribute(RequestDispatcher.FORWARD_REQUEST_URI) : null; ``` Non-vanity pages and vanity redirects (301/302) are unaffected — `null` is filtered out of the key by `PageCacheParameters`. ## Relation to dotCMS#34879 PR dotCMS#34879 fixed the same collision class for URL-mapped contentlets via `WIKI_CONTENTLET_INODE`. The vanity URL 200-forward path was not addressed by that fix. ## Testing - New integration test: `VelocityLiveModeTest#vanityForwardDifferentOriginalUriProducesDifferentCacheKeys` - Verified locally against customer's dev environment (Freshdesk dotCMS#37004) — different affiliate URLs now produce different cache keys and serve correct content ## Checklist - [x] Tests added - [x] Existing tests pass - [x] No new public API changes (package-private visibility change on `buildCacheParameters()` for testability only)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #34130
Proposed Changes
WebKeys.WIKI_CONTENTLET_INODEinHTMLPageAssetAPIImpl.getHTML()method.VelocityLiveMode.buildCacheParameters()readsWIKI_CONTENTLET_INODEas a component of the page cache key. Since it was always null, every URL-mapped contentlet of the same content type produced an identical cache key — so the first contentlet's rendered page was cached and returned for all subsequent ones. With the fix in place, the page cache key is unique per contentlet, so there are not cache collision for different URL mapped items.urlMapGeneratesDifferentHTMLPerContentlethas been added toURLMapBundlerTestclass. The test that creates two URL-mapped contentlets with distinct field values, runs the bundler, and asserts each generated HTML file contains its own unique value.Checklist
This PR fixes: #34130