fix(import): emit relative URLs from WordPress media import (#657)#673
Merged
ascorbic merged 1 commit intoemdash-cms:mainfrom Apr 27, 2026
Merged
Conversation
…ms#657) `/_emdash/api/import/wordpress/media` was building absolute URLs for imported media by reading `request.url`, unlike every other media endpoint which returns the relative `/_emdash/api/media/file/{key}` form. Two failure modes followed: 1. `INTERNAL_MEDIA_PREFIX = "/_emdash/api/media/file/"` is matched with `url.startsWith(...)` in `media/normalize.ts`, so an absolute URL fell through to the external-media branch and skipped the local provider's enrichment (dimensions, storage key, etc.). 2. The absolute URL was pinned to whatever origin `request.url` carried at import time. In dev this is whichever port Astro auto-selected (4322 when 4321 was busy), so later renders on 4321 got `ERR_CONNECTION_REFUSED`. Behind a reverse proxy the origin is the internal one rather than the public one. The fix follows option 1 from the issue: drop `baseUrl`, return the relative form, and remove the now-unused `requestUrl` parameter from `importMediaWithProgress`. The same fix applies to the `existingUrl` branch (content-hash dedup reuse).
🦋 Changeset detectedLatest commit: 2a98c0e The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 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 |
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/blocks
@emdash-cms/cloudflare
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@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-forms
@emdash-cms/plugin-webhook-notifier
commit: |
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes the WordPress media import API to return relative internal media URLs (consistent with the rest of core media endpoints), avoiding incorrect “external media” handling and origin/port pinning.
Changes:
- Update
/_emdash/api/import/wordpress/mediato emit/_emdash/api/media/file/{key}(relative) for both newly imported and dedup-reused media. - Remove the now-unused
request.urlparameter fromimportMediaWithProgress. - Add a changeset documenting the patch fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/core/src/astro/routes/api/import/wordpress/media.ts | Stops building absolute URLs from request.url; always returns relative internal media file URLs. |
| .changeset/fifty-moments-grab.md | Adds release note for the WordPress media import URL normalization fix. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+235
to
236
| const existingUrl = `/_emdash/api/media/file/${existing.storageKey}`; | ||
| result.urlMap[attachment.url] = existingUrl; |
There was a problem hiding this comment.
Consider adding a unit test to lock in the regression fix that this endpoint emits relative /_emdash/api/media/file/{key} URLs (both for dedup-reuse and newly uploaded media). The repo already unit-tests Astro route handlers by importing GET/POST directly (e.g. packages/core/tests/unit/astro/routes.test.ts), but there’s currently no coverage preventing this from drifting back to absolute URLs and breaking normalizeMediaValue’s internal-media detection.
Merged
0aveRyan
pushed a commit
to 0aveRyan/emdash
that referenced
this pull request
Apr 27, 2026
…ms#657) (emdash-cms#673) `/_emdash/api/import/wordpress/media` was building absolute URLs for imported media by reading `request.url`, unlike every other media endpoint which returns the relative `/_emdash/api/media/file/{key}` form. Two failure modes followed: 1. `INTERNAL_MEDIA_PREFIX = "/_emdash/api/media/file/"` is matched with `url.startsWith(...)` in `media/normalize.ts`, so an absolute URL fell through to the external-media branch and skipped the local provider's enrichment (dimensions, storage key, etc.). 2. The absolute URL was pinned to whatever origin `request.url` carried at import time. In dev this is whichever port Astro auto-selected (4322 when 4321 was busy), so later renders on 4321 got `ERR_CONNECTION_REFUSED`. Behind a reverse proxy the origin is the internal one rather than the public one. The fix follows option 1 from the issue: drop `baseUrl`, return the relative form, and remove the now-unused `requestUrl` parameter from `importMediaWithProgress`. The same fix applies to the `existingUrl` branch (content-hash dedup reuse). Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
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.
What does this PR do?
Fixes
/_emdash/api/import/wordpress/mediaso it returns the same relative/_emdash/api/media/file/{key}URL form every other media endpoint uses, instead of pinning an absolute URL built fromrequest.url.Two failure modes followed from the divergence (see #657):
INTERNAL_MEDIA_PREFIX = "/_emdash/api/media/file/"is matched withurl.startsWith(...)inpackages/core/src/media/normalize.ts, so absolute URLs fell through to the external-media branch and skipped the local provider's enrichment (dimensions, storage key, etc.).request.urlcarried at import time. In dev that's whichever port Astro auto-selected (4322 when 4321 was busy), so later renders on 4321 gotERR_CONNECTION_REFUSED. Behind a reverse proxy it pins the internal origin rather than the public one.The fix follows option 1 from the issue: drop
baseUrl, return the relative form, and remove the now-unusedrequestUrlparameter fromimportMediaWithProgress. TheexistingUrl(content-hash dedup reuse) branch gets the same treatment.Closes #657
Type of change
Checklist
pnpm typecheckpasses (packages/core; upstream/main has unrelated failures in packages/admin and packages/cloudflare)pnpm lintpasses (28 pre-existing diagnostics, none introduced by this change)pnpm testpasses (3 unrelated pre-existing test failures on upstream/main in auth/passkey-verify-route and invite)pnpm formathas been runpnpm locale:extracthas been run (if applicable)Note on tests: the route handler has no existing unit-test harness (the
wordpress-import.test.tsintegration test covers the CLI commands, not the HTTP route), andimportMediaWithProgressis not exported. Happy to add a targeted test if you'd like - the cleanest path is probably to export the helper or spin up a minimal route harness. Let me know which direction fits the codebase.AI-generated code disclosure
Screenshots / test output
N/A - change is URL format only.