i am having exactly the same issue also.
however, i am part way through analysing it and resolving it. a number of issues/bugs determined so far – albeit they may be peculiar to my particular environment.
issues found so far:
1) i was using the ‘advanced exporter for wp wpmu’ plugin (http://wordpress.org/extend/plugins/advanced-export-for-wp-wpmu/) to export posts from wp (mu) V2.7 to WP 3.3.1.
selecting only ‘posts’ to export prevented it from exporting ‘attachments’. (selecting export ‘all’ did export some attachments, but bombed out since my database was too big, leaving a corrupt/truncated export file – again, no error messages were produced)
solution: i modified/extended the plugin to enable export of ‘attachments only’.
(i will post details of my fix up on the relevent plugin page when i can).
2) from my old WP installation had ‘some’ attachments with relative url’s producing export tags of the form:
<wp:attachment_url>files/2009/12/myfile.jpg</wp:attachment_url>
note: no leading ‘/’ character
whereas most others had explicit url’s of the form:
<wp:attachment_url>http://mysite.com/files/2009/12/myfile.jpg</wp:attachment_url>
during subsequent these are picked up my wordpress-importer.php function process_attachment which mis-treats the first kind and as a result fails to load image files in from the remote url (which is malformed).
as i recall, no error message is returned (unless you turn debug on).
solution here:
file: wordpress-importer.php
lines: around 821
changed from:
...
if ( preg_match( '|^/[\w\W]+$|', $url ) )
$url = rtrim( $this->base_url, '/' ) . $url;
...
changed to:
...
if (!(stripos($url,'http://') === 0 || stripos($url,'www.') === 0)) {
if (strpos($url,'/') === 0) {
$url = rtrim( $this->base_url, '/' ) . $url;
} else {
$url = $this->base_url . $url;
}
}
...
– this seemd to work (mostly) – in that it actually loaded in my attachment image files from the remote server and showed them in the media library.
3) image url’s within post content are still not getting converted properly to the new paths. (although, curiously anchoe links sorounding the image tags do get converted).
this is the bit i am trying to fix at present.
part of the problem is that i am having to load my content in many small batches; the plugin runs a function backfill_attachment_urls intended to update any urls in content, BUT, the array it uses to do the mapping from old url to new url is ONLY created when importing attachments – thus is sensitive to the order in shiich i run my batches.
an additional problem i’ve spoted (i think): around line 849 of wordpress-importer.php, function process_attachment (again), currently reads:
...
// remap resized image URLs, works by stripping the extension and remapping the URL stub.
if ( preg_match( '!^image/!', $info['type'] ) ) {
$parts = pathinfo( $url );
$name = basename( $parts['basename'], ".{$parts['extension']}" ); // PATHINFO_FILENAME in PHP 5.2
$parts_new = pathinfo( $upload['url'] );
$name_new = basename( $parts_new['basename'], ".{$parts_new['extension']}" );
$this->url_remap[$parts['dirname'] . '/' . $name] = $parts_new['dirname'] . '/' . $name_new;
}
...
– this is the bit concerned i think (when eventually i can work out how to make it run at the proper occassion/step in my batches).
one further problem here appears to be the call to pathinfo($url)
– pathinfo – requires a file path BUT here it is being passed a url – entrirely the wrong format/usage.
part of solution (i think) is to use the parse_url function FIRST, then pathinfo on only the relavent (path) element.
in the middle of modding/testing all this at present, but need some sleep first. will update here when i discover more.
hope this helps give someone else a head start.
a few words from the developer would be a great help at this stage – if he’s about?
