Closed (cannot reproduce)
Project:
WordPress Migrate
Version:
7.x-2.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
28 Aug 2012 at 21:02 UTC
Updated:
18 Jun 2013 at 18:46 UTC
When I do a migrate of my complete WP database I get notified in the UI that my attachments are not copying. If I use an export from WP for just one user's posts, I do not get the error, but the files still never copy to my Drupal server.
In both cases the images appear in the posts (or Article) but the images are simply linked from the original site...never copied.
Comments
Comment #1
ksignorini commentedAnyone?
Comment #2
mikeryanWhen reporting issues involving error messages, please post the specific messages.
Are you sure that the file itself did not get copied? It's possible that that part of the migration succeeded, but what failed was the rewriting of references within posts - can you see if the file exists in the Drupal files directory and/or the files_managed table in the database?
Comment #3
ksignorini commentedThey don't copy at all. All the links stay referencing the original files on the previous site.
The folder structure looks like it gets built, but the files never copy over. I see the folders:
sites/default/files/wp-content/uploads/2010/11 (for example, for the images uploaded in november 2010)
sites/default/files/wp-content/uploads/2010/02 (for example, for the images uploaded in february 2011)
but the folders are empty.
There were no errors on import.
Comment #4
ksignorini commentedIf I do another complete import I'll post the error.
Comment #5
ksignorini commentedA few quick questions just to be sure I'm not doing something wrong:
How soon after import should the image files be copied over?
What permissions should be set on the file structure where the images get copied to?
Should it work with partial data exports/imports (say, exported by author name) or only full exports/imports?
Thanks.
Comment #6
alexboss commentedPersonally I'm using the latest module in the dev branch (at the time 7.x-2.x-dev) and images are imported correctly into Drupal (I modified the content-type for the blog post to add fields for files / attachments).
The only thing is that images are not shown within the post, some Json code is displayed instead of showing the image...
Example of code displayed:
Best regards,
Alexandre
Comment #7
mikeryanPlease be sure to change the status from "postponed (maintainer needs more info)" to "active" when providing more info, to make sure that your reply gets reviewed.
@ksignorini: The files are copied directly, it's not a delayed action. The normal web server permissions should apply. However, your last question may be it - I understand that when you do a selective export rather than a full export from WordPress, attachment info may not be in the WXR file so files won't be copied. Please try with a full export.
@alexboss: Please open separate issues for distinct questions. What you're seeing are media tags - when you have the media module installed, we emit these special media tags instead of regular img tags. For them to be interpreted by the media module (which turns them into img tags for the browser), you need to go to /admin/config/content/formats, click "configure" for the text format being used, and enable "Convert Media tags to markup".
Comment #8
mikeryanNo further information provided.
Comment #9
finex commentedThe bug is still reproducible using:
- Migrate 7.x-2.5
- Wordpress Migrate 7.x-2.2
Wordpress "attachments" are not imported to Drupal.
Comment #10
finex commentedI've just imported about 600 posts from a WP blog with about 300 images (attachments), the files has been copied and the "file_managed" table has been updated. The image field table has been updated only in 6 nodes. I'm trying to understand why most images has not been associated to the corresponding nodes.
Comment #11
mikeryanI never reproduced this with wordpress_migrate 2.2. There've been a lot of changes since, once 2.3-beta1 is out (soon) any problems with attachment migration should be opened as new issues.