Repository navigation
Resolve website images through one shared helper - #15061
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. |
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.
Follow-up to #15053 and #15032. The listing feed image size lookup missed the
project.dirjoin (#15032) because the same resolve-and-size logic was written by hand in three places, and the per-item copy had the join while the feed-level copy did not. #15053 settled which base each image source resolves against and moved the path half intoprojectRelativeHref. The URL check, the project join and theimageSizecall were still repeated.resolveProjectImage(image, projectDir, documentDir)inwebsite-shared.tsnow does all three: it builds the project relative href withprojectRelativeHref, skips the size lookup for web URLs (a URL joined onto a Windows path makesstatthrow, #15022), and reads the size from the project file otherwise. The feed-level image, the per-item feed image andimageMetadatacall it.URL building stays at the call sites,
absoluteUrlfor feeds andjoinUrlfor page metadata. The helper adds no error handling, soimageSizeread and decode errors propagate as before.imageMetadatadrops itspathfield, which nothing read.The one output change is in the feeds. Relative paths now go through
joinlike page metadata images already did, so./feed.pnggiveshttps://example.com/feed.pnginstead ofhttps://example.com/./feed.png, andimg//feed.pnggives/img/feed.png. Paths starting with/keep their href as written. Images outside the project are not supported input and have no handling.render-listing-feed-imagegains a local per-item image in its fixture (image: ../feed.png) and asserts itsmedia:content. Per-item local images had no rendered check, and that assertion passes on the base commit as well.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.