Repository navigation
fix(website/listing): resolve category links to nearest parent listing - #14495
Merged
Merged
Conversation
Collaborator
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
When a post is included in multiple listings (for example a homepage that lists everything plus a blog listing under `blog/`), the category badges on the post page wired to the wrong listing href. The previous prefix walk in `findNearestParentListing` stripped the leading slash from the post path before comparing against listing pathnames that retained theirs, so no listing ever matched and the function returned `undefined`. The caller then fell back to `document.referrer` or `listingHrefs[0]`, neither of which tracks the post's actual position in the directory tree. Replace the walk with a longest-directory-prefix match anchored at path boundaries: each listing is reduced to its containing directory, and the deepest directory that prefixes the post's directory wins. The fallback to referrer and first listing is retained for posts that are not under any listing's directory. Closes quarto-dev#14493
mcanouil
force-pushed
the
fix/issue14493
branch
from
October 18, 2026 22:13
a310b0f to
cf66497
Compare
cderv
approved these changes
Oct 19, 2026
cderv
left a comment
Member
There was a problem hiding this comment.
Thanks! This looks good to me.
I'll push a small adjustment to the tests and resolve the changelog conflict with main before merging, so no need to push on your side.
The order of listings.json depends on how the site was rendered. On a Windows render, blog/archive.html came before blog/index.html, so the same-directory test passed without the tie-break between listings. Both cases now serve a fixed order with the blog listing before the archive, so each test fails without its fix whatever the render order. Also ignore *.quarto_ipynb in the fixture, which a render adds to its .gitignore.
# Conflicts: # news/changelog-1.11.md
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
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.
Description
When a post appears in more than one listing, its category links could point at the wrong one.
In #14493, a post under
blog/that the home page also lists linked its categories toindex.html#category=..., which does not filter anything.findNearestParentListingnever matched, because it compared a path without a leading slash against listing paths that have one.So the choice fell to the referrer, or to the first entry in
listings.json, whose order depends on how the site was rendered.It now keeps the deepest listing whose directory holds the post.
The listing the reader came from still wins when the nearest one is no more specific: the site root listing, or another listing in the same directory.
The referrer is compared by pathname and origin, so this also works on a site served under a subpath.
The Playwright tests serve
listings.jsonin two explicit orders, with the home page listing last and first, as the rendered order differs between machines.Each one fails without its fix in Chromium, Firefox and WebKit.
An axe scan of the test site finds the same issues with and without this change.
Fixes #14493
Checklist
I have (if applicable):
AI-assisted PR
Note: autonomous AI agents submitting PRs without human oversight are not permitted — see the Code of Conduct.