Migravo WXR Media Migration

Änderungsprotokoll

1.2.2

• A relationship pointing at a post you have since trashed is now reported as that, instead
  of as definitely broken. The two need opposite responses — one says import the post type
  that is missing, the other says restore something from the trash — so naming the second as
  the first is worse than saying nothing.

  The „Skipped N stale/trashed reference(s)“ line existed for this and could never appear.
  It fires when the ID map holds an entry whose target is trashed, but the map is built from
  a query that excludes trashed posts, so the value fell through to the unresolved branch
  instead. There it was judged by what post currently holds that ID on this site — nothing,
  since the post was trashed rather than replaced — and „points at nothing“ reads as broken.

  Reproduced before the change: a post imported and then trashed gave skipped=0 and was
  counted among the definitely-broken. Afterwards, the same script on the same fixture gives
  skipped=1, one fewer definitely-broken, and no entry in the broken-reference list. What is
  stored does not change either way; the value was already left alone, and only the report
  was wrong.

  Costs one query per run, not one per value.

1.2.1

Dates. Three columns were being filled in by WordPress rather than read from the export,
and each was wrong in its own way.

• post_modified is now what the source says. It cannot be passed to wp_insert_post() –
  that function reads it from nowhere and decides for itself, writing the current time on an
  update and copying post_date on an insert – so it is written to the column afterwards,
  which is the only way there is. Anything ordered by „recently modified“ therefore described
  when the import ran, or repeated the publish date. Measured on a post last edited
  2026-05-06 and published 2019-01-02: it arrived dated 2019-01-02.
• post_date_gmt is taken from the export instead of being recomputed. Left out, WordPress
  derives it from post_date using the DESTINATION’s timezone – so migrating between two zones
  shifted every post’s UTC time by the difference while the local time looked untouched.
  Measured importing a UTC export into a UTC+7 site: every GMT column out by exactly seven
  hours. Feeds, the REST API and anything scheduling from GMT read that column.
• A draft no longer has its publish date reset when it is re-imported. wp_update_post()
  moves post_date to the current time for any draft whose GMT date is the unfixed-time
  sentinel, which is exactly what a WXR file holds for a draft. The rule exists so that saving
  a draft does not backdate it; an import is the opposite case, and edit_date is what tells
  core the date was chosen deliberately. This one predates 1.2.0 – it needs a draft AND a
  re-import to show at all, which is why it went unnoticed.

Checked against WXR generated by WordPress itself, on a first import and on a re-import, with
the destination in a different timezone from the export so that leaving a field out could not
accidentally produce the right answer. 16 comparisons across 4 posts: before, 10 wrong; after,
0.

1.2.0

Five fields the export carries were read by nothing, so an import produced a post that only
partly resembled the source. Each was checked against WXR generated by WordPress itself
rather than a file written by hand, and against real exports, on a first import and on a
re-import.

• Page hierarchy is rebuilt instead of flattened. wp:post_parent holds an ID belonging to
  the source site and was not being read at all, so every tree arrived flat — each child at
  the top level with nothing to say it had ever had a parent. On one real 153-item export
  that is 59 relationships lost in silence. Order in the file does not matter: a child that
  arrives before its parent is placed when the parent turns up, which is not a hypothetical —
  3 of those 59 appear before the parent they name. Verified with get_post_ancestors() and
  get_pages() on a three-level page tree, imported parent-first and child-first; before
  this, both came out with no ancestors at all and no children under the root.
• Loops are refused. WordPress does check for them, but its check begins „new post can’t
  cause a loop“ and returns — so a post created against a chain that is already looped is
  attached to it, and everything that walks ancestors then follows a line that never ends.
  Reproduced by looping two pages by hand and importing a third naming one of them.
• Image alt text comes across. _wp_attachment_image_alt appeared nowhere in the plugin, so
  every image arrived blank and the accessibility work done on the source site was lost in
  the move. It is written on the attachment item, which is not a post that gets imported, so
  it is collected during the pass that already reads those items. Alt text on this site is
  never overwritten — the export is authoritative about what the source said, not about what
  the destination has since decided — and images already in the library pick it up without
  being fetched again.
• Post password is imported. A protected post arrived public, with nothing to indicate that
  anything had been dropped.
• Comment status, ping status and sticky are imported, instead of falling back to this
  site’s defaults. Comment and ping are taken only when they read open or closed;
  comments_open() tests for the exact string, so any other value would behave as closed
  while claiming to be something else.
• An empty tag and a missing tag are told apart, which only shows on a re-import. Empty is
  the export saying „no password“, „not sticky“, and is applied; a tag absent from the file
  says nothing, and nothing here is overwritten on the strength of it. Real exports exist
  that omit these fields entirely — two items from one were imported, given a password by
  hand, and re-imported, and the password was gone.
• Importing an export twice under different titles no longer leaves the second hierarchy in
  halves. Where two posts on this site both claim the same source ID, the most recent is
  taken, and a child that had to settle for an older copy is moved when its real parent
  arrives — scoped to the import in progress, so the earlier tree is not pulled apart to
  build the new one.

1.1.3

• An existing image is now identified by where it sits, not by what it is called.
  Matching was on the bare filename, and WordPress only keeps filenames unique inside one
  month folder — so a site with any history has /2024/01/logo.png alongside
  /2025/06/logo.png, and logo.png, banner.jpg and hero.jpg are exactly the names that
  repeat. Reproduced with two such images: asking for the 2025 one returned the 2024 one,
  and the right one was then never downloaded, because the import believed it already had
  it. The wrong picture, with nothing reported. Matching is now on the upload path —
  2025/06/logo.png — compared for equality against what WordPress records for each file.
  This is the case the plugin is written for, a destination that already holds media, and
  not an edge case.
• A match found that way is no longer written back as if it were fact. The old code
  stamped its guess onto the attachment, so the next lookup accepted it without
  re-examining and a wrong match could never correct itself. That record is now written in
  one place only, after a file has genuinely been downloaded from that URL.
• When media download is switched off, the filename is still used, but only after the path
  has been tried and found nothing. In that mode the user has said the files are already
  on the site, so a missed match means no image at all rather than a re-download — an
  imperfect match beats a missing one there, while a right answer still wins wherever both
  are available.
• Removed the Screenshots section from this file. It described two screenshots that were
  not shipped.
• Post content containing „]]>“ is no longer mangled. A CDATA section cannot hold that
  sequence, so an exporter meeting one has to break out and back in — WordPress writes
  „]]]]><![CDATA[>“ — and an XML parser rejoins the halves. Reading the file with a regular
  expression did not, so those six characters were stored as though the author had typed
  them. Any post quoting XML, a regular expression or a code sample was affected, silently.
  Checked against a real XML parser on all 5,179 items of a real export: 36,253 fields
  compared, no differences.
• Values held outside CDATA now have their XML escapes decoded, so „Tom &amp; Jerry“
  reads as „Tom & Jerry“. Nothing in the import path reads such a field today, because
  WordPress wraps everything carrying text in CDATA; this is so that the next field that
  does read one does not inherit the problem.
• Importing with media download switched off now reports what it did. That route sets a
  featured image from a file already in the library, and it was the one media path that
  said nothing at all – a post that should have had an image and did not get one looked
  exactly like a post that never wanted one. Images attached this way are counted as
  already in the library, since nothing is transferred, and a post whose image this site
  does not have is now listed. Measured against the database on the same run: what the
  screen reports and what was actually attached now agree.
• The plugin no longer loads itself on front-end requests. Every hook it registers is an
  admin screen, an admin-ajax action or the cleanup cron, none of which can fire for a
  visitor, yet all eleven were being registered on every page view. This is tidiness
  rather than speed – the work avoided measures at 0.0092 ms and no query – but eleven
  fewer entries in the hook table is worth having.
• Every message the plugin shows can now be translated. Twenty-four of them — everything
  from „No file uploaded“ to „Import cache not found“ — were returned as bare English
  strings that never passed through WordPress’s translation layer, so a translated site
  showed them in English no matter what. Confirmed by marking every string that goes
  through that layer and watching the responses: none of them did before, all of them do
  now.

1.1.2

Security:

• Files written during an import are no longer readable by anyone who asks. They were
  placed in a fixed uploads/wxmi-temp/ protected by an .htaccess containing „deny from
  all“ — which is Apache configuration. nginx, LiteSpeed and IIS do not read .htaccess at
  all, so on any of them there was no protection, and the accompanying index.php only
  prevents a directory listing, not a request for a file whose name is already known. The
  names were known: the uploaded export is wxmi__.xml and each parsed
  post is items_/.txt, so on a normal site the first one is items_1/0.txt —
  nothing to guess. Confirmed on nginx: that URL returned the file’s contents without
  logging in, as did the export. The directory now carries a random 128-bit component in
  its name, which is the only defence that does not depend on the web server; the
  .htaccess and index.php are still written as a second layer. Upgrading removes the old
  directory.

Housekeeping:

• Two names that did not use the plugin’s wxmi prefix now do: the filter
  migravo_allow_private_media_host is now wxmi_allow_private_media_host, and the main
  class is WXMI_Media_Migration. Nothing outside the plugin can have been relying on
  either — this is its first release under this name.
• The ID map option is no longer rewritten once per imported post. It was read,
  re-serialised and written back for every post, to add one entry: on one site that is
  4,881 entries at 74.8 KB with autoload off, so roughly 45 seconds and 189 MB of writes
  across a 5,179-post import. The _wxmi_old_post_id meta written beside it already
  recorded the same thing per post, and the map is assembled from both, so nothing is
  lost — verified by importing the same export with the option emptied and confirming
  relationships still remapped to the same ids.

1.1.1

Every item below was reproduced before it was fixed, and the same test was run again
afterwards. Two of them were found only because the plugin was pointed at real exports
rather than a test site.

Security:

• A media URL that redirected was followed wherever it led. 1.1.0 blocked the cloud
  metadata address 169.254.169.254 when the import file named it directly, then allowed
  redirects to be followed — and the check that catches that address ran only on the URL
  from the file, never on a redirect target. What guarded the hops was WordPress’s own
  wp_http_validate_url(), which rejects loopback and private ranges but allows link-local.
  So a public URL returning a 302 to the metadata endpoint was fetched: measured, it
  produced a connection error rather than a refusal, meaning the request left the machine.
  On a host where that address answers, the response — instance credentials — would have
  been stored in the media library. Every hop is now checked by the same rule as the first.
  Following redirects at all is what made this reachable, so it is worth saying plainly
  that 1.0.0, which refused them outright, was not exposed to this.

Reliability:

• An import running longer than an hour was destroyed by the plugin’s own cleanup, in two
  independent ways, either of which was enough. The transients holding the cache location
  and the attachment and author maps expired after an hour, and the hourly cron deleted
  any cache directory older than an hour — and nothing had written to that directory since
  the upload, so an import three hours in looked exactly as abandoned as one given up on
  at the start. Both were reproduced in isolation. The cache directory is now touched on
  every post imported, so „abandoned“ is measured from the last request instead of from
  the upload; the transients last a day; and the cron reaps at twelve hours.
• A failed write to the item cache is now reported. The result of that write was discarded,
  so when it failed — a full disk, a permissions change — the upload still answered success
  and still listed every post it had found, because that list comes from parsing the XML
  and not from what reached disk. The run only came apart later, at import, blaming the
  export: „Content, title, and excerpt are empty.“

Interface:

• The ACF field mapping row appeared for some sites and not others, with nothing to
  explain it. Field keys were matched against a hexadecimal pattern, which only fits the
  keys ACF generates for itself in the admin UI. A field declared in PHP or in
  hand-written JSON normally carries a readable key — field_practice_areas — and every one
  of those failed the test, leaving the list empty and the row hidden. Across the 1,974
  distinct field keys on one machine the old pattern matched 1,229 of them, and 15% of
  field groups were entirely unmatched, meaning importing that post type offered nothing
  to map at all.
• „Media downloaded“ now says what actually happened. It was one number that answered
  neither question it was asked. It missed the featured-image-field route entirely — that
  branch reported neither successes nor failures, so an import driven by that setting
  finished reporting 0 whether every image had arrived or none had; measured on a 47-item
  export, 47 images downloaded and the screen said 0. And „downloaded“ was never what it
  counted: files already in the library counted too, so a second import of the same export
  reported a large figure while transferring nothing. It now reads „Media attached: 47
  (47 uploaded, 0 already in library)“, and failures from that route are listed with the
  field they came from.
• A featured-image URL is kept when its download fails. It used to be discarded either
  way, so a failure left no thumbnail and no record of what the image should have been.

1.1.0

Tested against a real 52 MB / 5,179-post WXR export. Every item below is a problem that
export exposed.

Reliability:

• Large files no longer exhaust memory. Parsing an upload made five passes over the whole
  document, holding it and a match array of every item at the same time — roughly 8x the
  file size at peak, enough for a host to kill the process before PHP could report
  anything. It now streams the file one item at a time: the 52 MB export peaks at 4 MB
  and parses in about 44 seconds.
• Failed posts are retried instead of being lost. A brief server hiccup used to lose every
  post whose request was in flight — 790 posts in one run — while the screen still said
  „Import Complete!“. Transport failures are now retried up to three times with a growing
  delay, which recovered all but 11 of those posts on the same data.
• Posts that still fail are reported and can be retried. The import summary lists them and
  offers a retry button; the parsed data is kept on the server so retrying does not mean
  uploading again.
• Stopping an import no longer discards it. Pressing Stop used to make resuming impossible
  — while closing the browser did not — so stopping properly was penalised. Reopen the
  page and the import offers to continue where it left off.

Data integrity:

• Relationship repair now reports what it could not fix, and says which of those are
  definitely broken. An ID with no mapping was left alone and never mentioned, so a field
  could still point at the wrong post with nothing to indicate it — the number looks like a
  valid ID, so nothing errors. Each one is now checked against the field’s own definition:
  ACF records which post types a Relationship or Post Object field accepts, so a value of
  another type is wrong as a matter of fact and is reported as broken, while a value of an
  accepted type is marked as almost certainly already repaired. On one real site this
  identified 1,240 broken references across 964 fields that had previously gone unmentioned.
• Where a post came from is now recorded on the post itself, not only in one option. The
  map can be rebuilt from the database, so it survives clearing it and no longer depends
  on still having the export file.

• Removed a „sync two-way relationships“ step that wrote back more than it should. After
  repairing a relationship it also wrote the reverse link onto each post the field pointed
  at, storing it under the same field name. That name belongs to the forward field, which is
  usually restricted to the post type on the other side, so the reverse values it wrote sit
  in a field that does not accept them — the same thing this plugin’s own check reports as
  „points at the wrong kind of post“. It did this whether or not the field asked for a
  two-way relationship, which ACF has its own setting for, and it wrote no field-key row
  beside the value, so the result depended on some field group happening to apply to that
  post. Nothing replaces it: repairing relationships sweeps every post type in one pass, so
  both sides are fixed whenever both are present. Values an earlier version wrote are left
  exactly as they are — they are stored under a real field’s name and cannot be told apart
  from relationships you set yourself, so removing them is a decision only you can make.

• Re-importing the same file no longer creates duplicate posts. Slugs containing
  characters WordPress strips (for example a leading „$“) were stored differently from
  what the file said, so „Skip“ could not recognise those posts and made a second copy of
  each one on every import. The example export contained 112 such slugs.

• Relationship remapping and the ID map now find those posts too. They were previously
  reported as missing, and their relationships were left pointing at the old site’s IDs.
• Remapping relationships no longer scans the whole postmeta table in one query. It works
  in pages, so the operation stays within limits on large sites.

Interface:

• Updated admin scripts now reach the browser. The script URL never changed between
  releases, so browsers kept running the cached older copy and fixes appeared to have no
  effect.
• The results panel no longer announces „Import Complete!“ for an import that was stopped
  or that lost posts.

Media download:

• Media now downloads from source sites that redirect. Redirects were refused outright,
  so an http-to-https redirect — near universal — failed every download with an error the
  user could do nothing about. Following them is no less safe: the internal-address check
  is re-applied to each redirect, so a public URL still cannot be used to reach an
  internal one.
• Importing no longer stalls waiting for shared images. When one image was already being
  fetched, the import slept up to ten seconds for it — and since a single image is often
  reused across many posts, several imports could be asleep at once and exhaust the
  server’s PHP workers, taking the whole run down. The wait is now about a second.
• Cloud metadata addresses are blocked. WordPress’s own URL check rejects loopback and
  private ranges but allows 169.254.169.254, the address AWS and Azure serve instance
  credentials on, so an import file could have had that response stored in the media
  library. Link-local and reserved addresses are now rejected too.
• AVIF images are imported. The patterns that scan post content for media listed every
  other web image format but not AVIF, so an AVIF image was never even found, let alone
  downloaded – its URL was left pointing at the source site with nothing reported.
• A source site on a private network can be allowed on purpose, one host at a time, with
  the new wxmi_allow_private_media_host filter — which is what makes migrating from
  a staging site possible without weakening the default for everyone else.

Housekeeping:

• Deactivating the plugin now removes its temporary files. Previously it only cancelled
  the hourly cleanup task, so anything left over from an abandoned or failed import — the
  uploaded file plus one cache file per item — stayed in the uploads folder with nothing
  left to reclaim it.
• Deleting the plugin now removes what it stored under its own name: the accumulated post
  ID map, the record it keeps on each imported post, the source URL noted against each
  downloaded attachment, its transients, and the temporary folder — around 4,600 rows on one
  real site. On Multisite this runs for every site. Imported posts, media and field values
  are yours and stay; the plugin only cleans up its own bookkeeping.

1.0.0

• Initial release.