Reporting fix. A relationship pointing at a trashed post was counted as definitely broken\nrather than as a trashed reference \u2014 a wrong diagnosis, since the fix is to restore the post,\nnot to import a missing post type. Stored values are unaffected.<\/p>","1.2.1":"
Fixes three date columns the import was letting WordPress invent: last-modified became the\nimport time or the publish date, GMT times shifted by the destination's timezone offset, and\nre-importing a draft reset its publish date to today.<\/p>","1.2.0":"
Imported page trees were arriving flat: wp:post_parent was read by nothing, so every child\nsat at the top level. Image alt text, comment and ping status, sticky, and post password now\ncome across too \u2014 a password-protected post used to arrive public with nothing said.<\/p>","1.1.3":"
Fixes an image being matched to the wrong local file. Identification was by filename\nalone, so a source image at 2025\/06\/logo.png could resolve to a local 2024\/01\/logo.png \u2014\nthe wrong picture, silently, and the right one never downloaded. Matching is now on the\nupload path.<\/p>","1.1.2":"
Security fix: temporary import files sat at a predictable path protected only by an\n.htaccess, which nginx, LiteSpeed and IIS ignore \u2014 the export and every imported post\nwere readable by anyone during an import. The directory name is now random. Upgrading\nremoves the old one.<\/p>","1.1.1":"
Security fix: on 1.1.0 a media URL that redirected could reach an internal address,\nincluding the cloud metadata endpoint. 1.0.0 refused redirects and is unaffected.\nAlso fixes imports over an hour being deleted by the plugin's own cleanup.<\/p>","1.1.0":"
Imported the same file twice with 1.0.0? Check for duplicates: slugs with characters\nWordPress strips (such as a leading dollar sign) were not recognised, so re-imports made\nextra copies ending in -2. Sort by slug to find them. 1.1.0 cannot remove them.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3641959,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3641959,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3641959,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3641959,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.1.3","1.2.0","1.2.1","1.2.2"],"block_files":[],"assets_screenshots":[],"screenshots":[]},"plugin_section":[],"plugin_tags":[2211,87,84,4155,222667],"plugin_category":[50,59],"plugin_contributors":[275187],"plugin_business_model":[],"class_list":["post-349219","plugin","type-plugin","status-publish","hentry","plugin_tags-acf","plugin_tags-import","plugin_tags-media","plugin_tags-migration","plugin_tags-wxr","plugin_category-media","plugin_category-utilities-and-tools","plugin_contributors-dinhqui","plugin_committers-dinhqui"],"banners":{"banner":"https:\/\/ps.w.org\/migravo-wxr-media-migration\/assets\/banner-772x250.png?rev=3641959","banner_2x":"https:\/\/ps.w.org\/migravo-wxr-media-migration\/assets\/banner-1544x500.png?rev=3641959","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/migravo-wxr-media-migration\/assets\/icon-128x128.png?rev=3641959","icon_2x":"https:\/\/ps.w.org\/migravo-wxr-media-migration\/assets\/icon-256x256.png?rev=3641959","generated":false},"screenshots":[],"raw_content":"\n
Import an export into a new WordPress site and two things break that nothing in the box will fix for you.<\/p>\n\n
ACF Relationship, Post Object and Gallery fields stop working.<\/strong> They store post IDs, and the new site assigns different IDs, so every one of those fields now points at the wrong post or at nothing at all. Nothing reports it. The fields simply look empty, or worse, quietly reference unrelated content \u2014 and on a site built around related posts, professionals, case studies or products, that is most of the site.<\/p>\n\n Every image still lives on the old server.<\/strong> The core importer copies the references, not the files. The content looks fine right up to the day the source site is switched off.<\/p>\n\n Migravo fixes both, on a site that has already been imported or as part of importing it.<\/p>\n\n Upload the export from the source<\/em> site on the ID Map tab. Migravo matches each old post to its new one by slug, builds a map of old ID to new ID, then rewrites every relationship, post-object and gallery field on the site in one pass.<\/p>\n\n It sweeps the whole database rather than one post type, so both sides of a two-way relationship are repaired as long as both are present \u2014 the field on the Artist and the field on the Song are just two more fields to fix, and it does not matter which order you imported them in. Import one post type now and the other later, then run the repair again: the map keeps what it already knows and grows as you import.<\/p>\n\n It only rewrites values it can account for. A flat list of numeric IDs is remapped; an ACF Link field, a repeater row, a phone number that merely starts with digits, and any ID with no entry in the map are all left exactly as they were. An ID whose target has since been deleted is reported rather than written as a dead reference.<\/p>\n\n And it tells you what it could not fix, as a verdict rather than a guess.<\/strong> An ID it has no mapping for is left alone \u2014 correct in itself, but the field still points somewhere wrong and the number still looks like a valid ID, so nothing errors. Migravo checks each one against the field's own definition: ACF records which post types a Relationship or Post Object field may reference, so a During import, Migravo finds every media URL in the post content and the featured image, downloads each file from the source site into the Media Library, and rewrites the content to point at the local copy. Files are deduplicated by source URL and filename, so importing the same export twice does not produce a second copy of every image.<\/p>\n\n A WXR file says more about each post than its title and content, and a field that is read by nothing is a field that goes missing without a word. These now come across:<\/p>\n\n Each is applied only where the export actually states it. An empty tag is a statement \u2014 \"no password\", \"not sticky\" \u2014 and is honoured on a re-import; a tag that is not in the file at all says nothing, and nothing on this site is overwritten on the strength of it.<\/p>\n\n One limitation worth knowing.<\/strong> Posts are tied back to the source by the ID the export gives them, and that ID is not qualified by which site it came from. Import two different sites into one destination and a post from each can claim the same source ID; the hierarchy lookup then has two candidates and takes the most recent. This is inherent in what a WXR file records, not something the plugin can detect, and it applies equally to the relationship repair.<\/p>\n\n Use it \u2014 and then use this. The core importer creates the posts, which is the part that already works. What it has no concept of is what became of everything that referenced those posts by ID, or of the files they pointed at:<\/p>\n\n No, and deliberately not. If you can copy an entire site \u2014 database, uploads and all \u2014 a tool built for that is the right choice and this is not it.<\/p>\n\n Migravo is for the cases where you cannot: you have a WXR export and a destination that already exists, you are pulling a few post types across rather than cloning a whole site, or you are on the other side of an import that already happened and left broken relationships behind. The ID Map tab works on a site that was imported months ago by something else entirely.<\/p>\n\n Two things in a WXR file are deliberately not imported, and are not planned:<\/p>\n\n Run the core importer for either of those, then use this for the parts it leaves behind.<\/p>\n\n\n Yes, and that is the main reason the plugin exists. Those fields store post IDs, and the new site handed out different IDs, so the values that survived the import now point at nothing \u2014 or at whatever unrelated post happens to hold that ID.<\/p>\n\n Open the ID Map tab and upload the export from the source<\/em> site. Migravo matches every old post to its new one by slug, then rewrites every Relationship, Post Object and Gallery field on the site to the correct new IDs \u2014 every post type at once, so both directions of a two-way relationship are fixed provided both sides are on the site.<\/p><\/dd>\n Yes. The ID Map tab needs only the original export file and the site as it stands now; it does not care what performed the import or how long ago. If a migration left broken relationships behind months ago, this repairs them without re-importing anything.<\/p><\/dd>\n Remapped: flat lists of post IDs, which is how ACF stores Relationship, Post Object, Gallery and similar fields.<\/p>\n\n Left untouched: anything that is not a plain list of IDs. An ACF Link field (title\/url\/target), repeater rows, a value that merely starts with digits such as a phone number, and any ID with no entry in the map are all written back exactly as they were. An ID whose target has since been deleted or trashed is counted and reported rather than written as a dead reference.<\/p><\/dd>\n Standard WordPress eXtended RSS (WXR) \u2014 the same file produced by any WordPress site's Tools \u2192 Export.<\/p><\/dd>\n Yes, when \"Download Media\" is checked. It scans the post content and featured image for URLs on the source site's domain, downloads each into the Media Library, and \u2014 if \"Update URLs in Content\" is also checked \u2014 rewrites the content to point at the new local URLs.<\/p><\/dd>\n You choose per import: skip<\/strong> it, update<\/strong> its content and media in place, or replace<\/strong> it (delete the existing post and re-import fresh). Matching is by title + slug + post type.<\/p><\/dd>\n Almost certainly because that site is on a private network. Staging and development sites usually resolve to a private address (10.x, 172.16\u201331.x, 192.168.x), and the plugin refuses to fetch from those by default: an import file comes from outside your site, and blindly following the URLs inside it is how a server ends up reading its own internal services.<\/p>\n\n If you know the source site and want to allow it, name that one host:<\/p>\n\n Only the host you name is allowed. Loopback, link-local and every other private host stay blocked, and there is no setting in the admin screen to switch this on \u2014 it takes deliberate code on your own site.<\/p><\/dd>\n Yes \u2014 a site selector appears wherever it's relevant (import, ID map, ACF field lookup) so you can target any site in the network without switching your admin session.<\/p><\/dd>\n An hourly cron job ( A relationship pointing at a post you have since trashed is now reported as that, instead\nof as definitely broken. The two need opposite responses \u2014 one says import the post type\nthat is missing, the other says restore something from the trash \u2014 so naming the second as\nthe first is worse than saying nothing.<\/p>\n\n The \"Skipped N stale\/trashed reference(s)\" line existed for this and could never appear.\nIt fires when the ID map holds an entry whose target is trashed, but the map is built from\na query that excludes trashed posts, so the value fell through to the unresolved branch\ninstead. There it was judged by what post currently holds that ID on this site \u2014 nothing,\nsince the post was trashed rather than replaced \u2014 and \"points at nothing\" reads as broken.<\/p>\n\n Reproduced before the change: a post imported and then trashed gave skipped=0 and was\ncounted among the definitely-broken. Afterwards, the same script on the same fixture gives\nskipped=1, one fewer definitely-broken, and no entry in the broken-reference list. What is\nstored does not change either way; the value was already left alone, and only the report\nwas wrong.<\/p>\n\n Costs one query per run, not one per value.<\/p><\/li>\n<\/ul>\n\n Dates. Three columns were being filled in by WordPress rather than read from the export,\nand each was wrong in its own way.<\/p>\n\n Checked against WXR generated by WordPress itself, on a first import and on a re-import, with\nthe destination in a different timezone from the export so that leaving a field out could not\naccidentally produce the right answer. 16 comparisons across 4 posts: before, 10 wrong; after,\n0.<\/p>\n\n Five fields the export carries were read by nothing, so an import produced a post that only\npartly resembled the source. Each was checked against WXR generated by WordPress itself\nrather than a file written by hand, and against real exports, on a first import and on a\nre-import.<\/p>\n\n Security:<\/p>\n\n Housekeeping:<\/p>\n\n Every item below was reproduced before it was fixed, and the same test was run again\nafterwards. Two of them were found only because the plugin was pointed at real exports\nrather than a test site.<\/p>\n\n Security:<\/p>\n\n Reliability:<\/p>\n\n Interface:<\/p>\n\n Tested against a real 52 MB \/ 5,179-post WXR export. Every item below is a problem that\nexport exposed.<\/p>\n\n Reliability:<\/p>\n\n Data integrity:<\/p>\n\n Removed a \"sync two-way relationships\" step that wrote back more than it should. After\nrepairing a relationship it also wrote the reverse link onto each post the field pointed\nat, storing it under the same field name. That name belongs to the forward field, which is\nusually restricted to the post type on the other side, so the reverse values it wrote sit\nin a field that does not accept them \u2014 the same thing this plugin's own check reports as\n\"points at the wrong kind of post\". It did this whether or not the field asked for a\ntwo-way relationship, which ACF has its own setting for, and it wrote no field-key row\nbeside the value, so the result depended on some field group happening to apply to that\npost. Nothing replaces it: repairing relationships sweeps every post type in one pass, so\nboth sides are fixed whenever both are present. Values an earlier version wrote are left\nexactly as they are \u2014 they are stored under a real field's name and cannot be told apart\nfrom relationships you set yourself, so removing them is a decision only you can make.<\/p><\/li>\n Re-importing the same file no longer creates duplicate posts. Slugs containing\ncharacters WordPress strips (for example a leading \"$\") were stored differently from\nwhat the file said, so \"Skip\" could not recognise those posts and made a second copy of\neach one on every import. The example export contained 112 such slugs.<\/p><\/li>\n Interface:<\/p>\n\n Media download:<\/p>\n\n Housekeeping:<\/p>\n\nRepairing relationships<\/h4>\n\n
practice_areas<\/code> field declared as accepting service<\/code> while holding an ID that is a trade_report<\/code> here is broken as a matter of fact. Those are reported as broken and listed first, with how many fields hold each ID and what it actually is. Values that match the type the field accepts are marked as almost certainly already repaired, so re-running the tool does not raise false alarms. Import the missing post type and run it again; the map grows as you import, so order does not matter.<\/p>\n\nRe-hosting media<\/h4>\n\n
What else the export carries, and what arrives with it<\/h4>\n\n
\n
wp:post_parent<\/code> holds an ID from the source site, so it means nothing here until it is translated \u2014 and an untranslated one is why imported trees arrive flat, every child at the top level. Order in the file does not matter: a child that arrives before its parent is placed when the parent turns up.<\/li>\npost<\/code> \u2014 the one type WordPress reads that list for.<\/li>\nThe rest of a real migration<\/h4>\n\n
\n
Security<\/h4>\n\n
\n
import<\/code> capability.<\/li>\n$wpdb->prepare()<\/code>.<\/li>\nwxmi_allow_private_media_host<\/code> filter \u2014 see the FAQ.<\/li>\nallowed_classes => false<\/code>).<\/li>\nWhy not just use the core WordPress Importer?<\/h4>\n\n
\n
Is this a full-site migration tool?<\/h4>\n\n
\n
\n
\/wp-content\/plugins\/<\/code>.<\/li>\n\n
My ACF Relationship fields are empty after importing \u2014 can this fix it?<\/h3><\/dt>\n
Can I use it on a site that was already imported by something else?<\/h3><\/dt>\n
Which field types get remapped, and which are left alone?<\/h3><\/dt>\n
What XML format does this accept?<\/h3><\/dt>\n
Does it download media from the old site automatically?<\/h3><\/dt>\n
What happens if a post already exists?<\/h3><\/dt>\n
No media was imported from my staging site \u2014 why?<\/h3><\/dt>\n
add_filter( 'wxmi_allow_private_media_host', function ( $allow, $host ) {\n return 'staging.example.com' === $host ? true : $allow;\n}, 10, 2 );\n<\/code><\/pre>\n\nDoes it work on Multisite?<\/h3><\/dt>\n
What if a scheduled cleanup is needed?<\/h3><\/dt>\n
wxmi_cleanup_temp_files<\/code>) removes temporary uploaded XML\/cache files older than one hour, in case an import session is abandoned partway through.<\/p><\/dd>\n\n<\/dl>\n\n\n1.2.2<\/h4>\n\n
\n
1.2.1<\/h4>\n\n
\n
1.2.0<\/h4>\n\n
\n
wp:post_parent<\/code> holds an ID belonging to\nthe source site and was not being read at all, so every tree arrived flat \u2014 each child at\nthe top level with nothing to say it had ever had a parent. On one real 153-item export\nthat is 59 relationships lost in silence. Order in the file does not matter: a child that\narrives before its parent is placed when the parent turns up, which is not a hypothetical \u2014\n3 of those 59 appear before the parent they name. Verified with get_post_ancestors()<\/code> and\n get_pages() on a three-level page tree, imported parent-first and child-first; before\nthis, both came out with no ancestors at all and no children under the root.<\/li>\n_wp_attachment_image_alt<\/code> appeared nowhere in the plugin, so\nevery image arrived blank and the accessibility work done on the source site was lost in\nthe move. It is written on the attachment item, which is not a post that gets imported, so\nit is collected during the pass that already reads those items. Alt text on this site is\nnever overwritten \u2014 the export is authoritative about what the source said, not about what\nthe destination has since decided \u2014 and images already in the library pick it up without\nbeing fetched again.<\/li>\nopen<\/code> or closed<\/code>;\n comments_open() tests for the exact string, so any other value would behave as closed\nwhile claiming to be something else.<\/li>\n1.1.3<\/h4>\n\n
\n
1.1.2<\/h4>\n\n
\n
\n
wxmi<\/code> prefix now do: the filter\n migravo_allow_private_media_host is now wxmi_allow_private_media_host<\/code>, and the main\nclass is WXMI_Media_Migration<\/code>. Nothing outside the plugin can have been relying on\neither \u2014 this is its first release under this name.<\/li>\n_wxmi_old_post_id<\/code> meta written beside it already\nrecorded the same thing per post, and the map is assembled from both, so nothing is\nlost \u2014 verified by importing the same export with the option emptied and confirming\nrelationships still remapped to the same ids.<\/li>\n<\/ul>\n\n1.1.1<\/h4>\n\n
\n
\n
\n
1.1.0<\/h4>\n\n
\n
\n
\n
\n
wxmi_allow_private_media_host<\/code> filter \u2014 which is what makes migrating from\na staging site possible without weakening the default for everyone else.<\/li>\n<\/ul>\n\n\n
1.0.0<\/h4>\n\n
\n