The Joy and Struggle of Moving Content From One WordPress Site to Another

Cory Web, Wordpress Leave a Comment

This week I’ve had to turn once again to the world wide web for its wisdom when it comes to moving partial content from one WordPress site to another. Normally, WordPress’ built in export/import tool would do the trick. But in the case of the two instances I was presented with this week, it was not so. Both existing websites had a massive amount of media – in WordPress classic fashion, a slew of image sizes per uploaded image resulting in over 500 images on site 1 and over 9,000 images on site 2. Ya, WordPress’ tools fail with sites like that.

After struggling with it for a bit (which means I tried multiple plugins claiming to save the day but failing miserably), I came across a lovely, well-written article by MPU DEV – How to Move Content From One WordPress Site to Another. What I was most interested in was the section titled “Partial Content Movement”.

If you’re going to move WP content using this guide, let me first say that you’re going to import/export your actual posts and/or pages using the built in WordPress tools but move the media library using this procedure outlined in on MPU Dev and described here. I found it easier to import the posts/pages AFTER moving the media even though the article says to do it first.

In the article, the author describes a process by which you zip up the uploads folder from site A (the existing site) and unzip it into site B’s (new site) WordPress’ upload folder. This can be done using the web host’s CPanel (which I prefer) or you can use SSH. I had the joy of using both this week. Then you proceed to dig into the mysql databases for each site using phpmyadmin. In site A’s database, find the post’s table and sift out just the attachment posts using the SQL query provided in the article above. Export it, but pay attention to the export options as explained in the MPU Dev article. Then, using the editor of your choice – I use Brackets by Adobe – replace the existing post’s table name with site B’s post’s table name (You’d have to open site B’s phpmyadmin to see that information, of course.). Also, replace the database name with the site B’s database name and, to finish it off, replace the website address with site B’s website address.

Here’s a point to note: If site B’s URL differs in the number of characters that site A’s URL has, doing a simple “Find & Replace” for the URL in this SQL file may break your site’s serialized data. That’s a big no no and you may end up with missing content on your new site. Thankfully for me, I went from “www.domainname.com” to “dev.domainname.com” and both have the same number of characters so I used “Find & Replace”. If you’re not so lucky, I highly recommend letting Peach safely change the domain name in your database dump. After saving your file from the edits above, simply drag the sql dump file onto this page and set a new domain. Download the new SQL file.

Want to do that again? Well, you have to. This time do the same process but with the postmeta table. Export the SQL file, but pay attention to the export options as explained in the MPU Dev article.

Now it’s import time. Import the edited posts sql file, import the postmeta sql file and the WP generated post/page xml file(s) if you haven’t done those already. If everything went smoothly, you’ll see your images in site B’s media library. That’s how one of the imports went for me this week. The first one, the one with 9K images, didn’t go so well.

At the very end of WPMU Dev’s article, it states “You could also run into trouble with duplicate primary keys transferring wp_posts if you already had posts on the new installation.” For my site that needed the 9K images, the site was completed with all new content; it just needed the images and 53 blog posts from the old site. So I got that lovely error: “Duplicate entry ‘####’ for key ‘PRIMARY'”. The referenced article doesn’t go on to say how to fix that so I took to the web. Repairing and optimizing site B’s database didn’t help as was suggested by others. What I found to be the fix was that the post ID’s in my imported SQL file already existed in the post’s table in site B’s database so the import threw the error about duplicate entries. Makes sense. The solution was to painstakingly go through my post’s sql file and change the number of the IDs that already existed in the database. Luckily in my situation all I needed to do was add a “1” to the ID numbers in my sql file (for example, changing “2732” to “12732”). I was able to narrow down what IDs already existed in my table and only change those ones in my to-be-imported sql file. I had to also check my to-be-imported postmeta sql file and change the ID numbers in there too. Messy? Maybe, but it worked. Of course, every step of the way I made sure to back up everything before making any changes. Though I’ve been doing web work for a while, it still makes me nervous to delete/move files & make changes with website databases. When inside phpmyadmin, I use the Export tab but when needing to back up my client’s WordPress websites I turn to BackWPup. I’ve used a few different backup plugins in the past but BackWPup (free) beats them all for simplicity, scheduling, filtering, and backup destination options (which I use Amazon S3 and I LOVE it).

Good luck with your migrations and happy computing!

Leave a Reply

Your email address will not be published. Required fields are marked *