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"],"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 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\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 ( 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
The 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
\/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.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