Replies: 1 comment
-
|
Just opened a PR to fix this on future imports #325 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I’ve been testing the WordPress WXR file import from the admin panel and noticed that imported items are not preserving the source XML dates.
The WXR file contains both:
wp:post_datepubDateBut when importing from the admin UI, the resulting EmDash content does not preserve those values as
created_at/published_at. Instead, the imported item gets current-time timestamps.From tracing the code, this appears to be because the admin file-upload import flow goes through
packages/core/src/astro/routes/api/import/wordpress/execute.ts, which parses WXR directly and creates content, but does not persist the source timestamps unless explicitly threaded through.I also noticed that there is a WXR import source in
packages/core/src/import/sources/wxr.ts, and thatwxrPostToNormalizedItem()already mapspost_dateintodate. However, from what I can tell, that source is not actually used by the current admin file-upload import execution flow. It looks like the admin WXR path is still using its parsing/import logic in its own route instead of the shared wxr source.Possible approaches to resolve this:
post.postDateorpost.pubDatethrough tohandleContentCreateascreated_at/published_atso imported file-based WXR content preserves original timestampsanalyze/fetchContent) so the admin panel and any future import flows share the same normalization logic.wxr.tsis not currently used in the admin WXR file import flow?created_atANDpublished_atwhen importing from external sources? Or let EmDash handlecreated_atvalue as the date is was created upon import?Beta Was this translation helpful? Give feedback.
All reactions