Derive page path prefixes from the root page, not the instance id - #286
Open
bbliem wants to merge 1 commit into
Open
Derive page path prefixes from the root page, not the instance id#286bbliem wants to merge 1 commit into
bbliem wants to merge 1 commit into
Conversation
resolve_url_path stripped `^/<instance-id>(-[0-9]+)?/` off a page's url_path, while resolve_page prepended the translated root page's url_path to the path it was handed. Both directions of the same round trip, taking the prefix from two different places, agreeing only while the root page's slug equalled the identifier -- an invariant nothing in the codebase maintained. When it broke, the front page kept resolving (its relative path is empty either way) while every child 404ed, which is what made both incidents read as a content problem rather than a routing one. The two conversions now live next to each other in pages/url_paths.py and both take the prefix from the root page's own url_path, so a slug that disagrees with the identifier can no longer separate them. The regex and its FIXME go with it, along with the special case for translated roots: their numeric suffix is now just a Wagtail sibling-uniqueness requirement, not something routing has to know about. _create_default_pages found the root page by `slug=self.identifier`, so a drifted slug meant it found nothing and built a second root page beside the real one. That orphan is what left augsburg-bisko with a duplicate, and what put a stale page in a position to hold the slug longmont needed. The lookup now keys on the root_page FK, which survives a rename, and falls back to the slug only for instances whose FK was never populated. _create_instance_root_page gets the same treatment; it used to add_child unconditionally on every sync. repair_instance_page_slugs keeps its reason to exist -- the revision pass, and slug hygiene -- but its docs no longer claim a mismatched slug breaks routing, because it no longer does. test_page_routing.py round-trips pages -> urlPath -> page(path:) through the real schema against a drifted slug, and fails on the previous resolvers.
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Codecov Report❌ Patch coverage is @@ Coverage Diff @@
## fix/repair-page-slugs-revisions #286 +/- ##
===================================================================
+ Coverage 56.99% 57.02% +0.03%
===================================================================
Files 357 358 +1
Lines 52684 52707 +23
Branches 8151 8159 +8
===================================================================
+ Hits 30026 30056 +30
+ Misses 20338 20329 -9
- Partials 2320 2322 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 2 files with indirect coverage changes 🚀 New features to boost your workflow:
|
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
1 participant
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.
resolve_url_path stripped
^/<instance-id>(-[0-9]+)?/off a page's url_path, while resolve_page prepended the translated root page's url_path to the path it was handed. Both directions of the same round trip, taking the prefix from two different places, agreeing only while the root page's slug equalled the identifier -- an invariant nothing in the codebase maintained. When it broke, the front page kept resolving (its relative path is empty either way) while every child 404ed, which is what made both incidents read as a content problem rather than a routing one.The two conversions now live next to each other in pages/url_paths.py and both take the prefix from the root page's own url_path, so a slug that disagrees with the identifier can no longer separate them. The regex and its FIXME go with it, along with the special case for translated roots: their numeric suffix is now just a Wagtail sibling-uniqueness requirement, not something routing has to know about.
_create_default_pages found the root page by
slug=self.identifier, so a drifted slug meant it found nothing and built a second root page beside the real one. That orphan is what left augsburg-bisko with a duplicate, and what put a stale page in a position to hold the slug longmont needed. The lookup now keys on the root_page FK, which survives a rename, and falls back to the slug only for instances whose FK was never populated. _create_instance_root_page gets the same treatment; it used to add_child unconditionally on every sync.repair_instance_page_slugs keeps its reason to exist -- the revision pass, and slug hygiene -- but its docs no longer claim a mismatched slug breaks routing, because it no longer does.
test_page_routing.py round-trips pages -> urlPath -> page(path:) through the real schema against a drifted slug, and fails on the previous resolvers.