Importer does not replace image URLs

[felixarntz]

When I imported a bunch of posts with images in them, the importer only replaced the URLs of the anchor tag that referenced the images. It did however not replace the src attribute of the actual image tag, causing these images to be loaded from their old location.

It should probably try to replace the image URL, at least if the requested image size is available after the import. I personally even think it should always replace the URL - if the original image size is not available after the import, let's use the one that's most appropriate. Old URLs should probably not remain anywhere in the posts.

[rmccue]

Can you try setting the aggressive_url_search option to true in the WXR_Importer constructor? This does a much more aggressive regex search through your content for the old URLs, but could potentially corrupt your data.

[jahir07]

its cant import image file..showing "Failed to import Media"

[swissspidy]

@jahir07 Could you please open a separate issue for this as it's unrelated to this one? Thanks.

@felixarntz Have you had the chance to try the aggressive_url_search option?

[daviedR]

+1 for this!

This happens because the new Importer doesn't change GUID of the imported posts. It's mentioned on WordPress Importer v2 discussion.

On import, the GUID of the attachment is changed to the new attachment URL. In the past, the GUID has been used by both WordPress core and plugins for the attachment URL, but this is now regarded as bad practice, and is avoided wherever possible. The Importer however doesn’t reflect these changes in attitude, as it still changes the GUID to avoid references to the old URL. This makes repeating an import (such as resuming an import, or doing a partial update) impossible, as there’s now no ID to cross-reference between the two. Removing the GUID change means we can easily check if an attachment has been imported already. The downside is that plugins still using the GUID may break; this needs to be fixed in the plugins in question, as the GUID is already an unreliable reference to the image.

The problem is: we are theme authors and want to give our users the real "one click demo import" and this plugin does well on it. But it's a bit inappropriate if the imported data on user's site still use our original media file URL. The imported media files are unused.

I think, it's better if you create a filter on your plugin, based on this comment: https://make.wordpress.org/core/2015/11/18/wordpress-importer-redux/#comment-28438

The filter should return true by default. As that is the normal behavior we expect as a user.

[rmccue]

@daviedR For the admin UI, the options passed in are filterable.

The GUID for attachments shouldn't be used as the actual URL for anything (get_attached_file() is the new-style API, and the data is stored in the _wp_attached_file meta item). For your demo import, you could change the GUIDs in your demo file to be actual UUIDs instead to make this clear?

Also, if you spot a plugin using the GUID for the URL, let's try and fix that plugin. Let me know if you see one using it. :)

[daviedR]

Hi @rmccue ,

Yeah, I am using 3rd party plugin, named One Click Demo Import. It uses your WordPress Importer v2. But it seems they only partially include your WordPress Importer v2 (as a vendor).

The plugin idea is combining your WordPress Importer v2 feature with Widgets Importer and Customizer Importer. Users could get the same demo data looks for just one click.

[capuderg]

Hi @daviedR and @rmccue,

I'm one of the developers for the One Click Demo Import plugin.

First of, @rmccue thank you for the much needed rewrite of the WP importer 👍

As for the passed options to this new importer, inside our plugin, we have a filter for that as well.

I haven't tried the aggressive_url_search option, but I will, once I come back from vacation (this weekend). However the options should work the same way as they do in this plugin (WP importer v2).

Take care!

PS: we include only the core of this new importer, because we do not need the UI bit, which by the way look awesome, so 👍 once again to Ryan.

[daviedR]

@capuderg,

After investigating for a while, I think the plugin works fine. The mistake is from my own custom function. Thanks for clarifying here. You did an awesome work on your plugin :)

And for @rmccue, thanks for this great plugin :)

[kraftner]

So currently the replacement process only considers the original image. The currently disabled and commented out functionally behind aggressive_url_search would normally work for replacing URLs of resized images, but still has issues like #64.
Maybe a more robust approach is needed here anyway as e.g. someone could also be using a different structure for the file names of resized images using image_make_intermediate_size

[drzraf]

update_attachment_guids (which only applies to attachment) is nice to have.
But it obviously breaks further imports (content duplication).
To avoid this, the post_exists should be modified so that if $update_attachment_guids is on then the search the database for an existing "would-be" GUID rather than the GUID provided by the WXR.
For this to be possible, the upload['url'] as obtained in process_attachmentmust be known before attachment is done.

1. This highly relates to the feature requests of omitting file download completely of if file exists (there are pending PR)
2. A filter for obtaining object final GUID may be useful too.
3. In any case, a wxr_post_exists filter would be a must-have.

See the wxr_importer.process_attachment.uploaded introduced in #152