fix(media): generate and render LQIP placeholders for production media - #1628
Conversation
Image dimensions and LQIP placeholders (blurhash, dominant color) were only generated for direct local-storage uploads. Signed-URL uploads, plugin ctx.media.upload(), and WordPress import produced records without them, so production (R2/S3) media had no placeholders. Route every server-side media-creation path through a shared enrichImageMetadata helper, cache the placeholders on the stored media value of content fields and on rich-text images, and render them in the <Image> component and portable-text image blocks.
🦋 Changeset detectedLatest commit: 0dcf6c3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
github-actions
Bot
added
review/needs-review
Scope checkThis PR changes 1,410 lines across 33 files. Large PRs are harder to review and more likely to be closed without review. If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs. See CONTRIBUTING.md for contribution guidelines. |
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/auth-atproto
@emdash-cms/blocks
@emdash-cms/cloudflare
@emdash-cms/contentful-to-portable-text
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/plugin-cli
@emdash-cms/plugin-types
@emdash-cms/registry-client
@emdash-cms/registry-lexicons
@emdash-cms/sandbox-workerd
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-field-kit
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
Overlapping PRsThis PR modifies files that are also changed by other open PRs:
This may cause merge conflicts or duplicated work. A maintainer will coordinate. |
![emdashbot[bot]](https://avatars.githubusercontent.com/in/3255304?s=60&v=4){kind=small}
There was a problem hiding this comment.
This is a focused, well-structured bug fix: it centralizes image metadata enrichment in enrichImageMetadata, routes the signed-URL confirm path, plugin uploads, WordPress imports, and REST uploads through it, and threads the resulting LQIP fields through the rendering and editor seams. The changeset and tests are sensible, and the approach fits EmDash's architecture.
However, the new helper forwards client-supplied width/height to generatePlaceholder as the OOM guard dimensions. generatePlaceholder was changed in this PR to trust caller-supplied dimensions instead of preferring header-derived ones, so a malicious client can claim a 1×1 image for a huge file and bypass the 32 MB decoded-size cap, causing the Worker/Node process to allocate an unbounded RGBA buffer and OOM. The REST upload (media.ts) and signed-URL confirm (confirm.ts) both pass browser/client dimensions as knownDimensions, so both paths are affected.
The fix is to server-read header dimensions for the OOM guard while still using the client dimensions for the stored record (so the EXIF-orientation fix is preserved). I’ve left a line-anchored suggestion on packages/core/src/media/enrich.ts.
No other blocking issues. The editor round-trips, component fallbacks, local-runtime embedding, and normalize backfill all look correct, and the tests cover the main happy paths. It would be good to add a unit test that exercises the guard with a small-bytes/large-dimensions fixture (or mocked dimensions), but the code fix is the important part.
enrichImageMetadata fed caller-supplied knownDimensions into generatePlaceholder's decoded-size cap. Since knownDimensions is decoupled from the buffer, a client could claim a tiny size for a huge image and bypass the guard, making the decoder allocate an unbounded RGBA buffer and OOM the runtime. Read header dimensions from the bytes that are actually decoded and use only those for the guard; keep knownDimensions for the stored record so the EXIF-orientation fix is preserved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
github-actions
Bot
added
review/needs-rereview
ascorbic
added
bot:review
There was a problem hiding this comment.
The previous review raised one blocking concern: the new enrichImageMetadata helper forwarded client-supplied width/height to generatePlaceholder as the OOM-guard dimensions, allowing a malicious client to claim a tiny size for a huge image and bypass the 32 MB decoded-size cap. That has been fixed.
In the current revision:
packages/core/src/media/enrich.tsnow reads header dimensions from the actual bytes once (readDimensions) and passes only those header dimensions togeneratePlaceholder.- Caller-supplied
knownDimensionsare used only for the stored record width/height, preserving the EXIF-orientation fix without affecting the decode guard. media.tsandconfirm.tsboth route through this helper, so neither path trusts browser/client dimensions for allocation.- A unit test was added that exercises the bypass: a 3000×3000 JPEG with client-supplied
1×1dimensions correctly gets skipped for LQIP while still recording the client dimensions.
I re-read the affected routes (media.ts, confirm.ts), the plugin upload seam (context.ts), WordPress import (media.ts), the local runtime, normalization, the rendering components, and the editor conversion code. No new blocking issues:
- Authorization and ownership checks in
confirm.tsare unchanged and run before any download. - The signed-URL read-back is capped at 8 MB before buffering, with a second in-memory size check.
- LQIP fields are correctly promoted to first-class fields on
MediaValue,MediaProviderItem, image embeds, and portable-text image blocks, withmetafallbacks for legacy snapshots. - Backfill via
normalizeMediaValueis gated to images and only consults the provider when LQIP is missing. - Tests cover the confirm read-back, REST upload, plugin upload, WordPress import, normalization backfill, and the OOM guard.
- The changeset and localization handling match the PR’s scope; no new user-facing admin strings were added.
Approving as the blocker is resolved and the rest of the change is sound.
emdash-cms#1628) * fix(media): generate and render LQIP placeholders for production media Image dimensions and LQIP placeholders (blurhash, dominant color) were only generated for direct local-storage uploads. Signed-URL uploads, plugin ctx.media.upload(), and WordPress import produced records without them, so production (R2/S3) media had no placeholders. Route every server-side media-creation path through a shared enrichImageMetadata helper, cache the placeholders on the stored media value of content fields and on rich-text images, and render them in the <Image> component and portable-text image blocks. * fix(media): use header dims, not client dims, for placeholder OOM guard enrichImageMetadata fed caller-supplied knownDimensions into generatePlaceholder's decoded-size cap. Since knownDimensions is decoupled from the buffer, a client could claim a tiny size for a huge image and bypass the guard, making the decoder allocate an unbounded RGBA buffer and OOM the runtime. Read header dimensions from the bytes that are actually decoded and use only those for the guard; keep knownDimensions for the stored record so the EXIF-orientation fix is preserved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
emdash-cms#1628) * fix(media): generate and render LQIP placeholders for production media Image dimensions and LQIP placeholders (blurhash, dominant color) were only generated for direct local-storage uploads. Signed-URL uploads, plugin ctx.media.upload(), and WordPress import produced records without them, so production (R2/S3) media had no placeholders. Route every server-side media-creation path through a shared enrichImageMetadata helper, cache the placeholders on the stored media value of content fields and on rich-text images, and render them in the <Image> component and portable-text image blocks. * fix(media): use header dims, not client dims, for placeholder OOM guard enrichImageMetadata fed caller-supplied knownDimensions into generatePlaceholder's decoded-size cap. Since knownDimensions is decoupled from the buffer, a client could claim a tiny size for a huge image and bypass the guard, making the decoder allocate an unbounded RGBA buffer and OOM the runtime. Read header dimensions from the bytes that are actually decoded and use only those for the guard; keep knownDimensions for the stored record so the EXIF-orientation fix is preserved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2 participants
What does this PR do?
Image dimensions and LQIP placeholders (blurhash, dominant color) were only ever generated for direct local-storage uploads. Every other server-side media-creation path produced records without them, so production media (R2/S3, which uses signed-URL uploads) silently had no placeholders and the
<Image>component had nothing to render before load.This routes the remaining server-side creation paths through a single shared
enrichImageMetadatahelper so records are populated consistently:ctx.media.upload()— enriches records created by plugins.The placeholders are then cached on the stored media value of content fields (alongside
width/height) and on images inserted into rich text, so the<Image>component and portable-text image blocks render a blur/color placeholder before the image loads — with no runtime lookup.No new public capability is added; this fills a gap in existing functionality (the LQIP/placeholder infrastructure already existed for local uploads) and makes the behavior consistent across paths.
Known limitations
jpeg-jsandupng-js(pure-JS, workerd-safe), which only cover JPEG and PNG. Other raster formats — WebP, AVIF, GIF, TIFF, etc. — upload normally and record their dimensions (read from headers viaimage-size, which understands far more formats), but ship without a blur/color placeholder;generatePlaceholderreturnsnullfor them and enrichment degrades gracefully. This is easy to miss because WebP is now a default output format for many tools. Broadening coverage to "any raster format the browser can render" would mean computing the LQIP client-side (canvas/createImageBitmap) and sending it through, on both the direct and signed-URL/confirm paths — deferred to a follow-up.Out of scope (intentionally)
$mediaenrichment. The seed loader's$mediareference path (packages/core/src/seed/) also creates media records and is not routed throughenrichImageMetadatahere. Wiring it up touches the seed download/apply pipeline and its fixtures, which is a separate change; leaving it out keeps this PR focused on the live upload paths. Existing seedwidth/heighthandling is unchanged.normalizeMediaValuepulls newer provider data), but no migration/backfill is included.Closes #
Type of change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges except in translation PRs — a workflow extracts catalogs on merge tomain. (n/a — no new user-facing admin strings)AI-generated code disclosure
Screenshots / test output
🤖 Generated with Claude Code