Migravo WXR Media Migration

Changelog

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.