[6.x] Invalidate old static cache entries on entry URL changes - #15021
Merged
Merged
Conversation
mynetx
force-pushed
the
fix/static-cache-old-slug
branch
from
July 22, 2026 07:01
b159368 to
26faed9
Compare
Contributor
Author
|
Rebased onto 6.x to resolve the conflicts. Since |
The invalidator only built URLs from the entry's current state, so after a slug change the previously cached page kept being served at the old URL. Rebuild the old URI from the original slug and invalidate it, along with anything cached beneath it (descendants, mounted collections). In background recache mode the old URLs are invalidated rather than refreshed, since they no longer resolve and could never be recached. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mynetx
force-pushed
the
fix/static-cache-old-slug
branch
from
September 15, 2026 21:13
26faed9 to
3abeb77
Compare
Member
|
This is "kinda" okay. It only solves the issue when a slug changes though. Other entry data can be in its url, and if that's the case and one of those values changes, you have the exact same bug. I'm looking into a better solution. |
getOldEntryUrls() only checked whether slug changed, so entries whose
route references other fields (eg. {year}/{month}/{day} from the date,
or a custom field) left stale cached pages when slug stayed the same.
Now every dirty route identifier is checked, and its original value is
substituted when rebuilding the old URL.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… handling
getOldEntryUrls() compared its rebuilt old URL (via site()->url(), which
is relative on a default install) against the entry's current
absoluteUrl(), so the equality guard could never match and the old-vs-new
comparison silently degraded to invalidating URLs unnecessarily. Build
from site()->absoluteUrl() instead so both sides are comparable.
Also handle a literal {date} route identifier (not just {year}/{month}/{day})
by returning a Carbon instead of the raw dirty-state string, and pass the
original Carbon's timezone into createFromFormat() instead of assuming the
app timezone.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Member
|
Pushed changes and updated the PR description. Thanks! |
jasonvarga
changed the title
jasonvarga
changed the title
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
2 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.
When a static-cached entry's route changes — slug, date, or any other field the route references — the cache for the old URL was never invalidated . The old cached response kept being served instead of a redirect to the new URL.
This rebuilds the old URL from whichever route fields actually changed (via
UrlBuilder, so it works with any route shape) and invalidates it, plus an/old-url/*wildcard so pages cached beneath it (children of a renamed parent, mounted collections) are cleaned up too. In background recache mode, old URLs are invalidated rather than refreshed, since they no longer resolve.Fixes #14876