Data Liberation and WordPress Migrations

One thing I heard a lot about when talking to the community about Data Liberation was the challenge of WordPress-to-WordPress migrations. Exciting news for anyone who has ever struggled with that: those migrations are now going to be an important part of the Data Liberation project.

As Matt mentioned at his WCEU Keynote, “We need to make WordPress to WordPress easier.” That’s what we’ll aim to do.

Making WordPress sites easier to move could free you from being locked into a specific host, let you set up a local staging site to test changes, or even let you take a copy of your whole site as an archive.

Migrations ≠ Importing

This might seem obvious, but it’s important to point out that the WordPress Importer pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is useful for importing content from an XML file and can definitely be used to migrate content from one site (or host) to another.

But, if the goal is to provide a 1:1 migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. (or as close as possible), the WordPress Importer is not the tool for the job. No plugins or themes, no settings of wp-config.php, and limited support for media migration mean that we need something more.

Plenty of third-party plugins are filling this gap and meeting user needs, but we should also improve the options within WordPress itself.

Migration challenges

In discussions with hosts and agencies, several recurring challenges emerge regarding migration:

• Getting adminadmin (and super admin) access to the source site – incorrect username and password, finding hidden login pages, insufficient user privileges, etc.
• Incompatibilities in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version or WP version between source and destination sites.
• Incompatibilities in supported plugins between source and destination.
• Incompatibilities in database encoding.
• Poor server performance/resources of source site (causing backups/migrations to fail or timeout).

Migrations and WordPress Playground

Something I’m particularly excited about is the potential of the WordPress Playground. In fact, the primary proposal for improving WordPress to WordPress migrations, Site Transfer Protocol, leans on the Playground heavily. You can check the details of that proposal in this Trac ticket.

But what about third party platforms to WordPress?

Don’t worry – a focus on WordPress to WordPress doesn’t mean we’re forgetting the need for migration pathways to WP from third-party platforms. There’s more information to come regarding that – but for now you can check out this really interesting proof of concept of a browser extension to copy content from a site and paste it into the editor as Blocks.

Get Involved!

There will be opportunities soon to get your hands dirty in helping build the tools of Data Liberation – but for now, the best way to get involved is to join the Discussion on how best to solve the challenges of migration. I’m really interested in hearing about your experiences with migrating WordPress sites – the challenges, and interesting and clever ways you’ve worked around them!

You can share those experiences in the comments here – or join the  #data-liberation channel in Make Slack to share any feedback, ideas, or comments there!

You can also check out the proposal for Site Transfer Protocol (to standardise WP to WP migrations) and join the discussion there.