tjkelly com/ blog/wordpress-import-failed-how-to-fix-it

If your WordPress import failed, here’s the solution.
No wasting time. Let’s get right to it. Follow these steps to import your WordPress XML data even if it’s failed in the past.


1. Export XML data
You probably already did this. If not, go to your old WordPress website. In the WP-Admin area, find the Tools > Export menu item. Hit the blue “Download Export File” button and save the XML file generated.


2. Divide file into small chunks
This part is a pain in the ass. And it requires a working knowledge of XML (or HTML) markup. Open your favorite text editor. I prefer Coda or Sublime Text, but just about any will do. DO NOT USE MS WORD or any other “word processing” application. It must be a basic text editor like Notepad, etc.


The first 20-ish lines are all instructions. They’re not important. However, the <?xml version="1.0" encoding="UTF-8" ?> tag on the top line is very important. Wherever you see the <rss version="2.0"... and the <channel> tags, that’s where the content starts.


Now, here comes the hard part.


3. Make sure chunks are properly formatted
Back to that working knowledge of markup thing. Every chunk has to start and end with the proper tags. Make sure your chunks follow this pattern:


<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0"...
<channel>
<wp:wxr_version>1.2</wp:wxr_version>
Your 5,000-ish lines of content, starting with <item> and ending with </item>
</channel>
</rss>
You can have many, many <item>...</item> tags within your 5,000 lines―and in fact, you definitely should. But your content MUST be wrapped within <item>...</item> tags (plus the others described above) or the import will break.


You will have to copy and paste these tags into the top and bottom of each file (or start with one file like this and paste your content into the middle). It’s a pain and it must be done properly. If you have a problem, it’s probably because this step was done wrong.


Here’s an example XML document I’ve edited to match the pattern above. Download and inspect it in your favorite text editor. Make sure yours looks similar in format.


4. Upload chunks individually
Repeat the Tools > Import > WordPress Import process you’re already familiar with. This time, import these smaller files that won’t take forever to parse. Your data should import just fine, albeit in smaller installments.


Drawbacks of this method
My solution isn’t perfect. It has two drawbacks, one bigger than the other: it’s tedious and it might break your data’s relationships.


It’s slow and tedious
It’s a total pain to go through a 100,000-line file and break it into 5,000-line chunks. And, as far as I know, it can’t be automated (at least not by the average WordPress user). But if you’ve got an hour or two and the patience of a saint, the tedium isn’t the end of the world.


It might break your meta data/relationships
This one could be a deal-breaker for some. Here’s the problem: if you have two pages in your site: Page ID #10 and Page ID #20. For whatever reason, you created 20 after 10, but 20 is the parent of 10. Read that carefully: 20, the higher ID and newer page, is actually the parent of 10, the older page. (I know that sounds weird. It doesn’t matter why. Maybe you added a category-level landing page [20] to list all sub-pages [10, 12, 14, etc.] Whatever, just go with me on this.)


Well, if you import a chunk that defines page 10 but cuts off before defining page 20, you’ll be telling WordPress to import/create page 10 and its parent is 20…but you haven’t imported 20 yet. That relationship is invalid. WordPress sees the invalid relationship and just skips right over it. They SHOULD throw an error or at least warn you of the problem, but it’s rare and most people won’t care so they probably just didn’t bother.


Now, when you do get around to importing/creating page 20, that relationship should be restored right? Well, the truth is I don’t know. I think so. But stranger things have happened. And I’ve dealt on more than one occasion with a list of imported pages whose parent/child relationships are all bonkers. So I’m blaming it on this little gem right here.


The real problem/cause
The problem here is not with uploading the XML file. It’s with processing it. Once uploaded, WordPress passes the XML file into a PHP processor script. The processor parses through each line of the XML document and handles the data accordingly. Namely: it inserts records into the database according to the XML doc’s content and meta definitions (author, publish date, status, tags, etc.).


It’s that markup-parse/database-insert process that causes a problem. It just takes too long. 2MB of plain text—like in an XML file—is a TON of text. The server takes forever to process all the data in the 2MB file. And most servers have a timeout limit. They don’t let the process run long enough.


Technically, the failure isn’t WordPress’ fault. It’s the server’s. But of course WordPress’ system files can’t foresee or control that, so they have no way of alerting the user when it happens―there’s no WP error message for that.


So the “2MB is way less than 7MB” is deceiving. The 7MB limit is just for the file upload. It has nothing to do with processing the data contained within the file.


I’ve found that 5,000 lines of XML markup―usually 300-400 KB―is the perfect size for a WordPress import. The file uploads instantly and the PHP import process only runs for 10-20 seconds, well within most server process time limits. The import of each 400KB file runs smoothly and then you can move on to the next small chunk and do it all over again.


Your move, Automattic
I believe that the WP dev team should fix this problem. Granted, they can’t predict the behavior of every server, but they could build some sort of sectioning and redundancy into the import process.


Test the XML document for its size.
If it exceeds, say, 500 KB, run the import in waves.
Automattically (see what I did there) break the large XML doc into chunks.
Lather, rinse, repeat.
WordPress could do this for you. But right now it doesn’t. And I think that’s a shame. Hopefully this tutorial saves some headaches.


Share this:
FacebookTwitterLinkedIn1GoogleReddit
20 thoughts on “WordPress Import Failed? Here’s How to Fix It”
Doodles SD, S.L. (@manodere) July 3, 2013 at 1:11pm
suffering because of this, thanks for taking your time to write about it…
;-)


TJ Kelly July 3, 2013 at 1:20pm
My pleasure, I hope it helped! Have you had success with any other techniques or tricks?


Chris September 12, 2013 at 5:56am
Thanks for that post! I guess that you can also reduce the processing time by unchecking the option to import attachments (You can process those attachments later with plugins). I totally agree that the import procedure could be improved for people who have to rely on shared hosting where you cannot change the php execution time. It would probably be possible to process the items one by one with AJAX.


TJ Kelly September 12, 2013 at 8:28am
An excellent point! Thank you for your suggestion, Chris.


Yorick September 16, 2013 at 7:15am
Awesome! Thanks a lot! This saved me a headache!


cto December 31, 2013 at 10:11am
i was having this problem and the solution was to delete all the spam comments from my XML file.


THANKS A LOT for the leads


WPShowCase January 2, 2014 at 6:32am
Thank you so much Chris – this has been really useful for importing large files.


Muhammad February 21, 2014 at 4:59am
Hey TJ,


You just saved my life!


Thank you for your time taken to write this out. I thought your 100,000 line XML was crazy but i realised that I had 140,000. Haha!


Have an awesome day.


KMHDESIGN February 22, 2014 at 12:19pm
I second that motion! Awesome helper, I haven’t tried it yet, but i have to say, its the first rational thing i’ve seen in all the searching i’ve done. And this post is how old? I wish i’d have found it first!
Im simply trying to load demo content for a theme (hate recreating post layouts, etc) so nothing critical like most people moving blogs. None the less, This is super valid information!
Thank you!
KMH


TJ Kelly February 23, 2014 at 4:43pm
Thank you! I’m glad I could help.


Neil Andrew March 6, 2014 at 12:47pm
You are the best. You just saved me hours and hours and hours of work!


TJ Kelly March 6, 2014 at 12:49pm
Happy to be of service, Neil! Very glad I could help :)


Harry April 14, 2014 at 11:10am
Thanks for the tips. Very helpful :)


TJ Kelly April 14, 2014 at 11:12am
Glad I could help, Harry! Thanks for your comment.


Mick April 16, 2014 at 7:51pm
Just run the importer many times until you get it all. Works every time for me. Last one i did succeeded on the 3rd run!


TJ Kelly April 16, 2014 at 8:32pm
Thanks for your comment, Mick. That plan fails if the server kills the process and errors out. That’s what happened to me every time. Otherwise, a good idea. Thanks!


Mick April 16, 2014 at 11:33pm
When the server kills the process and errors out, it doesn’t undo what it got done in that time. So incrementally running it till error you eventually get everything across. It can take many times if its a large xml but this method hasn’t failed on me yet. Some menu duplication occurs but thats the only negative I have found which is an easy fix.


TJ Kelly April 16, 2014 at 11:35pm
Hmmm an interesting point. I’ll have to try it. Also, what’s your easy fix for the duplicate menus? Manual recreation/purging?


giovannif23 May 13, 2014 at 5:24pm
Something that has worked for me is the following:


1. Import the demo xml files on a local server. (I usually never receive a timeout error).
2. Export local SQL and save to file.
3. Open SQL in text editor (Sublime) and change all of the URLs using common + F (from localhost to server URLs).
4. FTP the /uploads/ folder to live server
5. Upload SQL using phpMyAdmin import.


I’m my experience the timeout issues have been caused by attaching/importing the images. I hope that this approach might help someone else. :)


Adam Watts December 8, 2014 at 12:31pm
Working on a 3,000,000 line text file…thought I’d try and make everyone’s lives seem better after reading this. Up to about 250 files that it’s been split up into…still working….