Repository navigation
Fix listing feed image size depending on the render directory - #15032
Merged
Merged
Conversation
createFeed passed the raw feed image (listing feed.image, document image, or website image) to imageSize, so a relative path resolved against the process cwd. Rendering a project from outside its directory (quarto render path/to/project) silently dropped <height>/<width> from the feed <image>, and a leading "/" path read from the drive root on every render. The feed <url> already treats the image as project-relative through absoluteUrl, and per-item images already join project.dir, so the size is now read from that same project file. Renders from the project directory produce the same output as before. The smoke test renders a fixture project from the tests directory and checks the listing option, the site image fallback and a leading "/" path.
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. |
4 of 5 tasks
cderv
added a commit
that referenced
this pull request
Oct 14, 2026
A file named next to a folder in a listing's `contents` was resolved against the process working directory. Rendering a site from any directory other than the listing page's dropped the file, or listed a same-named file from the cwd instead. Entries now resolve against the listing document's directory, as the lone-file form already did, with a real absolute path as fallback. - Skip `!` exclusion entries, the listing document itself, and files already included by the folder or glob match - Add `safeExistsFileSync` to `deno_ral/fs.ts` for the existence check - Cover the cross-directory case with a smoke test and fixture Fixes #15044 See #15032
2 of 5 tasks
cderv
added a commit
that referenced
this pull request
Oct 15, 2026
The feed-level listing image skipped the project.dir join that the per-item image had (#15032), because the same resolve-and-size logic was hand-written in three places. Move it into resolveProjectImage in website-shared.ts so the href, the URL check and the size lookup live in one place. - The helper builds the project-relative href and reads the pixel size from the project file. Web URLs get no size lookup and are not joined onto the project dir, since on Windows that makes stat throw (#15022). - The feed-level image, the per-item feed image and the page metadata image all call it. Relative feed image paths are now normalized like page metadata images: ./feed.png becomes /feed.png, and img//feed.png becomes /img/feed.png. Leading-slash paths keep their href as written. Images outside the project are not supported. Related to #15032 Related to #15022 See #15053
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 website project is rendered from outside its directory (
quarto render path/to/project), the listing feed<image>silently loses its<height>and<width>. Rendering the same project from inside its directory keeps them. A feed image written with a leading/(image: /feed.png) never gets them, whatever the directory.Found while reviewing #15026, but the bug predates it.
Root cause
createFeedpasses the feed image (listingfeed: image:, the documentimage, or the siteimage) unchanged toimageSize()inwebsite-listing-feed.ts, so a relative path is read from the current working directory instead of the project. The feed<url>for the same image is built project-relative withabsoluteUrl(), and per-item images in the same file already joinproject.dirbefore reading their size.Fix
The size is now read from
join(project.dir, image), the same project file the feed<url>points at. Rendering from the project directory gives the same output as before.The new smoke test renders a fixture project from the
tests/directory and checks the size for the listing option, the siteimagefallback and a leading/path.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.