WordPress's Portability Problem

WordPress’s Portability Problem

Filed Under

Published

March 19, 2014

5 Comments

Many WordPress users have encountered—at least once or twice—the tedious process of moving content from one server to another. A recent post by web developer Eric Mann shed light on this issue when he emphasized how WordPress drastically lacks portability.

To export, import, and backup content, WordPress uses a particular format called WXR. The fallacy of this feature lies in its inability to import enough content to effectively recreate your site on a new server.

Meta information, media attachments, and site settings are just a few important elements that are lost in the transfer.

Additionally, as your website becomes larger and more complex, your WXR file grows as well. So, when you’re finally ready to move to a new server the WXR file is simply too big to be imported.

In an effort to address this issue, WordPress developers created WXR File Splitter. This software enables you to break apart your gigantic WXR file into smaller files so they can be safely imported to your new site.

While WXR file splitter does alleviate the pain of transporting large WXR files, it still doesn’t speak to the inefficiency of WXR as a whole.

As an alternative to WXR, Mann suggests using MySQL.

MySQL provides a more efficient file-import method, and helps retain your website’s important information that WXR would lose in the import. Still, Mann went on to explain that MySQL is very rigid because you can only map MySQL to MySQL.

As a solution to this issue, Mann indicated:

In an ideal world, WordPress would be decoupled from its data store—allowing me to swap out MySQL for, say, flat-file YAML documents for data storage. Being able to work with multiple data systems would enable site administrators to dump their content from one format to another and back again losslessly.

The problem with portability seems to be a hot topic in the WordPress space, and it will be interesting to see what solutions the future holds.

What steps do you take to recreate your WordPress site on a new server?

Marie Dodson is an editorial assistant at Torque. She graduated from Cornell University with a degree in Biology and Society. She enjoys wine, good books, and travel.

There are 5 comments

March 19, 2014 #

Kevin

Moving WordPress this way can certainly be difficult. I’ve found it easier to just compress everything, dump the database then restore it all on the new server 🙂
March 19, 2014 #

Michael Bastos

WordPress core being a meritocracy, the excuse that’s always given is if you want to see a feature then you should write it yourself and I’m all for that.

But to many on the outskirts of core it feels like there’s a vested interest among the companies that help provide and support core committers to not improve the portability to such an extent because many including Automattic are themselves hosting providers.

Eric Mann works for 10up which does enterprise so it’s in his best interest to push this since he does these kind of moves regularly, but I can see the need for portability as low on the list of priorities for many who may not feel comfortable promoting that to existing customers.

Ultimately though portability will only help good providers gain more customers, or allow folks to move away from crappy hosts and towards more premium hosts easier and with less hassle and creates more competition which can only be good for the WordPress consumer.
- March 20, 2014 #
  
  Eric Mann
  
  My interest in portability actually stems from personal experience moving my own site. My blog began on a shared hosting setup with Network Solutions (where I lacked direct database access). When I moved to a (slightly better) shared hosting setup with 1and1, I was forced to rely on a WXR and manually migrate other settings. I then moved to a VPS, and was lucky enough to do so by way of a direct SQL import. When I moved again to WP Engine, I again had to rely on a WXR.
  
  For a personal site, this is a headache. I have several hundred posts and huge data structures that needed to migrate. Getting everything set up to where I was happy took the better part of a day and, honestly, is the main reason I’m loathe to move any of my sites again.
  
  Working with larger enterprise clients, the headache becomes a nightmare. Even a direct SQL script (the best way to “clone” your data from one server to another) can take several hours, and that’s assuming nothing goes wrong during the transition!
  
  As for baking this feature into core, it’s a bit trickier than just telling people to write it on their own. WordPress does a horrendous job of abstracting business logic away from the database. Yes, we have the convenient $wpdb class to manage connections and queries, but direct SQL calls are littered throughout core. Making the WordPress codebase truly database-schema agnostic would be a monumental task for core itself.
  
  Factor in third-party themes and plugins (and our ongoing commitment to backwards compatibility) and it becomes nearly impossible.
March 20, 2014 #

Chuchundra

I use Navicat, a desktop MySQL client. In Navicat I set up connections to the old db and the new db, then just tell it to transfer the data from the old one to the new one, copy the files to the new sever, edit the config and move the domain name.

I’ve done this with some pretty large WP installs and I’ve never had any issue.
March 20, 2014 #

Mark Gavalda

I use the Duplicator plugin almost every day, it has been a true life saver.

How do you stay on top of your WordPress game?