Have WordPress.com Broken Export and Import Functionality?

I like WordPress.com – I recommend it to people who don’t want to get into their own hosting.  You can pay to remove ads, and the service and value you get is tremendous.

But something recently starting causing me all sorts of trouble.

I needed to migrate a new client site from WordPress.com to our own servers so that we can add additional functionality not available on the SaaS offering.

In the past this has been easy – set up the new site with the same theme (if that’s the way you’re going) and appropriate plugins, do an export from WordPress.com and use the WordPress import tool in your new site.  Simple!

What do the Guided Transfer folk do?


Except, suddenly, it isn’t.

I have this problem – the user has uploaded many large images – like, 8MP images.  I wish users wouldn’t do this, but they do.  Still, so long as the inline images are resized all is well.  And they are.  Yet when they arrived on the new install they weren’t – we had massive massive images leading to very slow page load times.  I thought at first that our server wasn’t resizing the images but then realised that the export has lines like this:

<a href="http://mayorofsandwell.wordpress.com/2012/09/24/tea-with-mr-bill-woodhouse-in-the-big-house/sam_0654-2/#main" rel="attachment wp-att-634"><img title="SAM_0654" src="http://mayorofsandwell.files.wordpress.com/2012/09/sam_06541.jpg?w=768" alt="" width="768" height="1024" /></a>

In particular, note the URL for the image:


Now what’s interesting here is that the URL isn’t to a resized image, and it comes with some extra parameter.  Which the new WP install isn’t going to handle.

Also, the parameter is wrong – on wordpress.com the URL is actually:


See the h=1024? That’s missed on the export file. So that’s problem No.2!

What that means, then, is that we don’t have in our new content the resized image, but the original monster JPEG with a parameter in it… and a broken parameter at that.

In this case where the image is massive, the test install then has posts with oversized images in, which means very slow loading times. And that means we have a problem. At the moment the only fix I can see to the problem is to manually go through and re-insert every image on the site which, in local argot, is something of a ball-ache. Even if we reproduce the tool that wordpress.com is using for on-demand image resizing (and I can understand why they’d do this) we still have the problem that the export data isn’t properly formed.

I’m almost tempted to test their Guided Transfer service and see what their solution is – but I suspect there are serious limitations on what they’ll do for that money.

In due course I’ll raise this with WordPress.com, but for the moment I’m left with the possibility of getting somebody to sit and tidy up manually, which is painful even for a relatively small site like this one.

Do you know a better solution?

David Coveney

David Coveney

Dave has been working in software development since 1988, starting with payroll development and then ERP consultancy for large corporates. He is a keen traveller, photographer and motorsport enthusiast, but now puts family first as he’s massively in love with his two little boys. Dave is still an early adopter. He was connected to the internet from his bedroom, way back in the eighties, had a personal website by 1994, was into the connected house in the late '90s, a smartphone by 2002, and a was the first in the office with a fitness tracker.

19 responses to “Have WordPress.com Broken Export and Import Functionality?

  1. Is it possible to download all the original sized images in one go using some Firefox plugin? Maybe you could get them all from the Media page (I haven’t tried this)? Then you might try using the plugin Imsanity to resize all uploads. Since you have access to the underlying file system it might be possible to place all the newly uploaded & resized images in a directory (eg wp-content/uploads/2012/09) with the same relative URL. Then your image URLs might work as migrated. Alternately, having uploaded and resized the images, since you need to remake the domain anyway you could replace ‘http://mayorofsandwell.wordpress.com/2012/09/24/’ with the actual domain and location of the images. The filenames should remain untarnished.
    Just a couple of ideas …..

  2. This is pretty uncool on WP.com’s part. Thanks for highlighting this problem and do let us know if Automattic gets back to you.

  3. WordPress are implementing a way to support HiDPI screens – for WordPress.com first, for self-hosted sites later. Could be the source of the trouble, and let’s hope it’s temporary.

    1. That may be a part of it.

      Essentially, wherever WordPress.com diverges from WordPress.org, there’s going to be problems for anybody doing a migration. There’s the images, some features such as the slideshow which aren’t replicated in JetPack, the social integration and lots more things. I can see why WordPress.com doesn’t share this – it’s their differentiator, after all.

  4. I’m guessing that the reason for the WP.com image urls with a parameter is that WP.com uses a CDN setup that parses the incoming URLs and provides the appropriate image file accordingly. This is obviously beyond the capabilities of your standard $5-$10/mo hosting account and self-installed WP software.

    I totally agree with your perception that WP.com should not be providing a “broken offering” in this regard, and maybe should even provide some options on export time for translating the URLs and images to appropriate filenames.

    But in the meantime, as a small businessperson, it’s important to remember that any work required in this situation (sensible or not) is your clients’ problem, not yours. It’s unfortunate if a job on their tasklist that SHOULD be simple ends up being complex instead, but ultimately this is something that becomes part of the job spec as if it were not a snafu but a planned migration element. Indeed, if they’re a small site that has no budget and can’t afford a complex migration, then they’ll be stuck on WP.com. But if they have no budget, why take them so seriously anyway? You do what you can for them, but you can’t give away work just because your client expects more than they can afford. Clients with real money will be disenfranchised but ultimately it won’t break their backs. It’ll just be more busywork for you, and longer project timeframes, which means it’s an opportunity for improvement, not a code emergency.

    I don’t mean to be preachy, but I do mean to use this as an example to illustrate the challenge we face as WordPress developers, when such a small part of the user community is the clients who can afford typical development costs (which can fluctuate in a task based on difficulties encountered) and such a large part of it is clients who need a professional site but have a barebones budget only to get launched, and lean on their developers to deal with site-hassles (some self-introduced) otherwise. It’s quite a challenge to manage your client base to keep your business viable.

    1. That all depends on whether you opted to do a fixed cost or variable cost migration.

      Ultimately, we’re the experts – if we say a migration from WordPress.com to self-hosted is easy then we shouldn’t go “oh, sorry, they changed something and it’ll cost double now.” After all, to the client, WordPress is WordPress, regardless of whether it’s dot com or dot org. That has a real impact on perception and I always felt there was a danger in the shared branding.

      The upside is that we’re now more aware of it. But we don’t do enough WordPress.com to WordPress.org migrations to be aware of every little change or difference, and we do need to take that into account in the future.

  5. I think that this feature works great on WordPress.com, and I’m waiting for the same feature to come to self-hosted WordPress(.org) installs.

    It’s a compatibility problem, which needs to be fixed – either by bringing WordPress.com’s features to self-hosted installs, or changing the export files to support those same non-WordPress.com installs.

    Thanks for pointing this out.

  6. 1. Export old database using PHPmyadmin
    2. Create new MYSQL database on new server
    3. Import database .sql file into new database using PHPmyadmin
    4. FTP all files from old WP installation including wp-content folder 🙂
    5. Modify wp-config.php file to reflect correct settings for new database.

    1. Jerry – I’m not quiiiiite sure how to respond to your comment.

      You’ve either commented on the wrong post, or you don’t really know what we do around here, or what we’re famous for in the WP community 😀

  7. Have you tried regenerating the image thumbnails?

    1. Damn right I have!

      If you look carefully at the export, it’s not of thumbnails – the wp.com exporter places the jpeg link with a query string in it, rather than the selected size as you’d see with normal WP.

  8. Normally, WordPress saves static resized images at upload time. On the stand-alone install, is it automatically creating those when you import? (images in the upload folder with names like “someimage-640×480.jpg”)

    You should already know what image sizes are being used on the wordpress.com side, so doing a search+replace in the .WXR file shouldn’t be too difficult. Replace things like ‘.jpg?w=768’ with ‘-768×1024.jpg’, right? Maybe it’s more complex than that, but we’d need more details if so.

    1. All the correct image sizes are being created.

      The problem is the content sent over – it’s not suitable. Yes, we can replace the sizes, but we have to know each of those sizes… images don’t follow common aspect ratios at all times, sadly.

      1. But if you search/replace the image references before importing the WXR, is it still doing something wrong? And if so, what? Or is a search/replace problematic in some way?

        1. Oh, I see what you’re saying… I’m having to quit for today, but will try that out. Should work… but shouldn’t really have to do that – a WordPress > WordPress export/import should just work, really.

          1. I agree. File a bug with them, and hopefully they’ll do what they need to adjust it. Good luck!

          2. I am very agree with you David!

    2. PS – thanks for responding 🙂

Leave a Reply

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