Migrating Blog Posts

Have you noticed how it’s often the simplest things that cause the most problems? How the difficult stuff goes without a hitch, but then you get snagged on something that’s worked smoothly at least a hundred times before?

Case in point. A friend of mine wanted to transfer the contents of one of his WordPress blogs to a different WordPress blog, also his. Simple, you’d think. Just export all the posts from the old blog and import them into the new one. It’s nicely documented in the WordPress Codex documentation. In fact it’s one of those rare bits of the Codex that are really clearly written and easy to follow. What could possibly go wrong!

I suggested he backup the target blog before starting. Just in case. It was highly unlikely that it would get corrupted in the update process, but better safe, as they say, than sorry. His blog went back ten years and he didn’t want to lose it, understandably, if we got something wrong and wrote all over it.

All fine so far. Backing up a blog is the same as exporting it, so he would actually get to export both blogs. The process is straightforward — Export and Import are menu items under the Tools menu in the WP Dashboard. Export creates a file, and Import reads it. It’s as simple as that.

Almost.

Let’s fill in a few details before we go any further.

Under Tools > Export (on the site from which we wanted to copy the posts) we have a few choices. We could export everything, or just the posts, or just the pages. (If you have the Essential Grid plugin installed there is also an option to download just the Essential Grid posts.)

If we had selected ‘All content’ the export would have included all the variable stuff from the site — that is, posts and pages, of course, but also comments, custom fields, terms, navigation menus and custom posts. This would have almost amounted to a full backup, but not quite, since it doesn’t include templates, theme functions, custom functions, CSS files or images, and if these have changed simply reimporting the exported file wouldn’t have reinstated the site. (We’ll look at backups in another post.)

We only wanted to export the posts — the second option on the list. Checking the ‘Posts’ radio button brought up a few more choices in case we wanted to filter the output by category, author, or date range. We wanted all the posts, so we accepted the default settings.

Significantly, there’s no ‘Export’ or ‘Save’ button. Instead the button is labelled ‘Download’. This actually means ‘export and download’. There is no option simply to export the file without also downloading it to another computer. Usually that makes sense, but not always. If the source and target blogs are on the same server — possibly even on the same site, why would we want to download the exported file to another computer? It would be quicker, probably easier, and certainly more logical, to save it on the server and pick it up from there to import it. No matter – WP requires us to download it, and that’s a small price to pay for the convenience of being able to do it at the click of a button.

The exported file is in XML format, and XML is notoriously verbose, so we were prepared for the file to be quite large. It’s slightly surprising that WordPress doesn’t compress the file. XML compresses well and doing so would significantly reduce bandwidth use and transfer times.

Anyway, the first task, exporting the blogs from both of the sites, was straightforward and trouble-free. The old blog (the one that we wanted to incorporate into the target blog) produced a file of 3.7MB. Could have been a lot worse! We also exported the target blog as a backup, and since we downloaded both of the resulting files to the same local computer and they had very similar names, we made a careful note (on paper) of which was which. It sounds obvious, but it’s one of those things it’s quite easy to get wrong!

Before we could import the posts to the new site we needed to install an ‘importer’. This is consistent with the WordPress approach of providing a basic framework which does most of what most of the people want most of the time, while leaving you to install a plugin for anything that’s a bit out of the ordinary. It seems a little odd that exporting should be built-in as standard, but not importing! No doubt they have their reasons.

Installing the Importer

Under Tools > Import there’s a list of importers designed to retrieve posts (and other data) from various sources. We chose the ‘WordPress’ option since the source blog was from another WordPress site, and this brought up the installation dialog.

The number of bad reviews was quite alarming: 66 one-stars compared with 77 five-stars when I last looked. Not promising! There were relatively few two-, three-, and four-stars. Closer inspection suggested it works well when nothing goes wrong but can be a pain when it does. However, Irish_Guy’s comment, Seems like the plugin is back in order – with wordpress 4.3.1 update. Panic off, (five stars) gave us hope, so we installed it by clicking the ‘Install Now’ button’ and ran it by selecting ‘Activate & run plugin’.

Uploading the exported File

This is where things start to get a bit more complicated. On the WordPress Import page there’s a Browse button that allows you to select the file to upload. The file’s now on our local computer, and we know where we put it (I hope) so all we need to do is click the Browse button, use the dialog that comes up to locate the file, and click ‘Open’ (or ‘OK’, or ‘Save’, or whatever it says depending on whether we’re using Windows, Mac, Ubuntu, or something else).

But wait! Next to the button it says Choose a file from your computer: (Maximum size: 2 MB). So what happens if the file is bigger than 2MB? You may remember ours was 3.7MB. Well, one option is simply to ignore the warning and press on regardless. You won’t get very far. WordPress will spot the fact that the file is too big and give you an error message along the following lines:

Before you can upload your import file, you will need to fix the following error: The uploaded file exceeds the upload_max_filesize directive in php.ini.

That is commendably clear, but it may not be the whole story. It’s a start though. If you’re following this on your own computer you should be able to find your php.ini file fairly easily – it’s probably in the httpdocs directory (on the server, of course). If you can’t find it, or if you find several versions and don’t know which to use, you may have to contact your hosting provider’s Support department and ask them to help you out. But don’t do that yet! It’s always a good idea to understand what goes on behind the scenes even if you get someone else to sort it out for you.

So we’re now going to digress briefly from the world of WordPress to the more fundamental world of PHP. Bear with me if you already know this stuff. Not everyone does and it’s essential knowledge if you’re going to stay on top of WordPress!

You need to know that PHP is the programming language that WordPress is written in, and that many of the capabilities and limitations of PHP are defined in a special ‘initialisation file’ (‘ini’ file, for short). This allows us to match the behaviour of PHP programs to the environment they are running in, by modifying the ini file.

OK, that’s the theory. How is it relevant? Well, remember the error message that said we had to fix the error concerning the upload_max_filesize directive in php.ini? ‘php.ini’ is the name of the ini file. It contains a number of ‘directives’, one of which (called upload_max_filesize) is preventing us from uploading a file that is 3.7MB in size.

But rather than going straight ahead and fixing this issue there are a couple of other things I need to tell you first, because when my friend followed WordPress’s instruction and changed the size to 6MB, and then to 64MB (!) he still couldn’t upload the file. And not only did it fail to upload, but it killed his Skype connection every time he tried. (Why Skype was affected remains, for the time being at least, a mystery!)

The point is that the upload_max_filesize directive, though critical, is not the only thing that matters. There are in fact three things: the upload_max_filesize directive, the post_max_size directive, and the max_execution_time directive. The ‘maximum file size’ quoted by WordPress, and which it restricts you to, is actually either the value of the upload_max_filesize directive or the value of the post_max_size, whichever is the smaller. If we want to upload 3.7MB files setting both of these to at least 4MB should do the job, and with capacity to spare.

But what this doesn’t take account of is the amount of time it’s going to take to upload 3.7MB (or whatever) over a domestic broadband line. Upload speeds are generally very much slower than download speeds — often ten to twenty times slower! A file that takes 3 seconds to download can easily take 30 seconds to a minute to upload. Now a PHP operation (strictly, a PHP ‘script’) that takes more than a few milliseconds is rare, and one that takes as long as PHP’s default time of 30 seconds or a minute has probably gone seriously wrong. If this happens PHP simply ‘times out’ — stops running, in other words. But if we’re uploading a file of any size (and 3.7MB isn’t much of a file these days) it could easily take much longer than this.

It follows that as well as increasing upload_max_filesize and (possibly) post_max_size, we may also need to increase max_execution_time. I suggest a minimum of 8MB for the first two (64MB does seem a bit excessive!) and, say, 300 seconds for the max_execution_time, or possibly even more, depending on your upload speed.

Now you can get on to your hosting provider’s Support department and tell them exactly what you’d like them to do, and why. After that you should be able to select the downloaded export file and import it to the new site. Alternatively you can read on and find out how to do it yourself.

cPanel

What follows assumes you can (a) find your php.ini file and (b) edit it. If you’re using cPanel you’ll probably find it in the httpdocs directory corresponding to the domain, and you can edit it simply by selecting it and clicking edit.

Find the line (if any) that starts

upload_max_filesize =

and change it to read

upload_max_filesize = 8M

If the value is already 8M or more (M = megabytes here), don’t change it. If there’s no such line at all, just add one somewhere — at the end if there’s no particular reason to put it anywhere else.

Then find the line (if any) that starts

post_max_size =

and change it to read

post_max_size = 8M

If the value is already 8M or more, don’t change it. If there’s no such line at all, just add one somewhere – at the end if there’s no particular reason to put it anywhere else.

Lastly, find the line (if any) that starts

max_execution_time =

and change it to read

max_execution_time = 300

If the value is already 300 or more, don’t change it. If there’s no such line at all, just add one somewhere – at the end if there’s no particular reason to put it anywhere else.

Now save the file and you’re done!

Plesk

If you’re using Plesk you’re probably confused. It certainly confuses me. Plesk seems to me to be about the least intuitive user interface yet devised. However, it’s all there somewhere, so find your way to the Control Panel for the domain and select ‘PHP settings’. Suddenly everything becomes simple – even simpler than cPanel, as you can just enter the required values and don’t need to edit the file directly

Make sure the max_execution_time setting is at least 300, and the post_max_size and upload_max_filesize settings are at least 8M (for 8 megabytes). Don’t forget to scroll down to the bottom of the page and click the OK button or all your efforts will be in vain!

Other Interfaces (and none)

If you’re not using cPanel or Plesk you’re either using a different interface (with which I’m not familiar – sorry!) or you have command line access, hopefully over ssh. In that case you probably don’t need any more help – just find the php.ini file and edit it using nano (or whatever) to change the values of upload_max_filesize, post_max_size and max_execution_time as described.


Phew!

Now we should be able to complete the import process without further event, by clicking the Browse button and selecting the exported file.

It’s all very simple really, even if it’s been a bit of a struggle getting there. We have seen that in order to transfer posts using WordPress’s export/import mechanism we may need to do a bit of preparatory work. This is simply because the exported file is automatically downloaded and has to be uploaded again. For the upload to succeed we may need to adjust a few (i.e. three) variables, and this is quite easily done by changing settings in the php.ini file.

Any questions?

Related Posts
No related posts for this content
Phil

Hi David. Great blog. I’ve a question for you.

When you export from one blog and import to another, the images that have been imported into the new blog are actually linked images from the old blog. They aren’t truly imported. What can I do about this? I want to close the old blog down but clearly I can’t if that’s where the old images are held.

Thanks,
Phil

    David Brown

    Good question. And closing down the old site isn’t the only potentially problematic issue either. Even if you can guarantee the old site will stay up, the fact that you’re linking to external images can mess up your SSL settings if, say, the new site has an up-to-date certificate and the old one doesn’t. What you really need to do is get the images transferred as well. Fortunately there are plug-ins to help with this, and I’ll be looking at these and related issues in a future post.

Phil

Thanks. Looking forward to that.

Comments are closed