Repository navigation
Fix website og:image using a data URI image joined to site-url - #15073
Merged
Merged
Conversation
When a website page sets no image, preview image discovery picked an inline data URI, such as the ORCID badge Quarto renders for an author with an orcid, and joined it to site-url. Since #15050 the image size is read from any path, so the data URI is also passed to stat and the render fails (os error 123 on Windows, os error 63 on macOS). Crawlers and feed readers fetch these images by URL, so a data URI is never usable there: - Discovery for og:image and twitter:image skips data URIs and moves on to the next image of the page or the site image. The named file pass never returns them, which is what the check added in 2023 ("Don't attempt to test data uris") meant to do. - A data URI set explicitly as a page, site or listing item image is ignored with a warning for social metadata and listing feeds. - projectRelativeHref leaves data URIs as is, so listing cards, which the browser displays, show them instead of a broken project path. Fixes #15055
When the first .preview-image was a data URI, querySelector stopped there, so a later marked image was never considered and social metadata fell back to the first local image or the site image. Also match the feed warning by its own text in the test: the looser pattern matched the social metadata warning of the same file too.
A data URI listing feed image was ignored with a warning, but the channel then had no image at all, while social metadata falls back to the next candidate. The feed now does the same: a data URI feed, listing page or site image is skipped for the next one, so a data URI feed image with a site image set still gives the channel an image. The smoke test now covers a data URI feed image and a data URI site image, the latter in its own project since the site image is project-wide. Without the site image check, that render fails with the stat error from the original report.
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
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 page sets no
image,og:imageandtwitter:imagecan end up as a data URI joined tosite-url, likehttps://example.com/data:image/png;base64,.... The ORCID badge rendered in the title block for an author with anorcidis the common trigger. Since #15050 reads the size of any image path, the same page now fails to render onmainwith astaterror on the data URI. The crash is not in a release, the wrong URL is older.Root cause
Two places treat a data URI as a file path:
discover-meta.tsreturns it. The check added in 2023 to not test data URIs against the named file regex returns them instead of skipping them, and the last resort pass only excludeshttp/httpsimages.imageMetadata,projectRelativeHref) only special-cases absolute URLs, so a data URI is resolved as a project path and joined tosite-url. Listing items usingprojectRelativeHrefgot/posts/data:...the same way.Fix
Crawlers and feed readers fetch these images by URL, so a data URI can't be used there:
image. Every image marked.preview-imageis now tried, not only the first one.imageis ignored with a warning for social metadata and listing feeds, and the next candidate is used.projectRelativeHrefleaves data URIs as is. Listing cards are displayed by the browser, so they keep showing them.Fixes #15055
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.