Using WP Migrate DB Pro to Publish Your Content

As alluded to in a previous article about the Local Sync application from ManageWP, website content creators often first put together their content within a staging environment. And only once they are happy with it is the finished post or page pushed to the live website.

One popular type of staging environment consists of a copy of the website hosted on a local computer in the form of a MAMP, XAMPP, or other local web server instance. This local copy is then typically used to refine the new post or page, keeping the unfinished content isolated from the wider internet until it is ready for publication.

However, when the article is ready to go live, the question invariably arises as to how to efficiently transfer the finished content from the local environment to the live website. GoDaddy's ManageWP service has taken a stab at solving this problem with their Local Sync application. However, Local Sync seems to be stuck in Beta and is plagued by a series of problems.

This is where the WordPress plugin, WP Migrate DB Pro, can come to the rescue.  Using an elegant and simple interface, WP Migrate DB Pro can transfer any new articles and/or changes to old pages and posts with a simple push of a button.

Of course, like Local Sync, WP Migrate DB Pro was not designed solely to push new content to a live environment, so it has to be specifically set up and used in a certain way for it to accomplish this task. In addition, the wide variety of code making up different WordPress sites, with the almost unlimited scope for incorporating third-party plugin code, makes it difficult for the migration plugin to do a perfect job in every website setup.  

In this article, we look at the process of setting up WP Migrate DB Pro specifically for its use as a content-publishing tool. Once set up, content created on a local MAMP instance of a website can then be moved, very efficiently, to its live equivalent hosted on a remote server using the migration plugin. 

In addition, we also document some of the common problems that are likely to be encountered when using WP Migrate DB Pro as a content-publishing tool, with special attention given to the functioning of other popular plugins that are often found on WordPress websites.

Setup of WP Migrate DB Pro for Content Publishing

1. After purchasing a license for the Pro version of the software from Delicious Brains, download and install the WP Migrate DB Pro plugin on to both the local (MAMP) copy of the website as well as its live internet-accessible one.

2. Input the WP Migrate DB Pro license details into the local copy of the plugin to activate the push and pull migration functionality of the plugin. 

3a. Also on the local copy, adjust the WP Migrate DB Pro plugin settings to allow it to process requests for data to be pulled from the local website installation and to be copied elsewhere. This is achieved by setting the ‘Pull’ toggle switch in the migration plugin settings to active (as shown below). 

3b. Similarly, on the live website, adjust its migration plugin settings to allow it to process requests for data to be copied to it from elsewhere. This is achieved by the somewhat counterintuitive action of setting the ‘Push’ toggle switch in the plugin settings to active (shown in the image below).

4. The connection and sending of data to the remote website can be automated by setting up a new migration profile. Future content migrations can then be performed quickly, simply by selecting this profile.

5. Retrieve the migration plugin's connection information from the live website and add it to the local copy of the website. This gives the local version of the migration plugin the credentials to connect to the remote website host server and to know where to send the new content.

6. A dialogue may appear (as shown below) indicating that the remote site does not have the migration plugin license. However, this can be easily rectified by clicking on the link provided which copies the plugin license key to the externally-hosted website.

7. When it comes to content publishing, only some of the local website's database tables should be migrated to the live website so that other settings that are specific to the live environment remain unaffected. Select only the following six tables to migrate all post, page, category and tag data without affecting other settings on the live site.

(** your database table names should be identical unless you have changed the default database table naming prefix of ‘ wp_ ’)

8. Choose whether a backup of the current live database that will be partially overwritten on the external website is required before replacing it with the new local data. Having a backup is useful if, for any reason, the external website needs to be restored to its original form before the migration. This is especially recommended the first time a migration is carried out. However, making a backup significantly increases the amount of time the migration process takes to complete, so it may not be necessary every time.

9. It is recommended to keep the ‘Migrate all post types’ option unchanged (i.e. selected).

10a. Advanced Options: Replace GUIDs. When publishing content to the live website, this option should be selected. In this way, the local GUIDs (Globally Unique IDs) in the data being transferred will be replaced with the live GUIDs so that posts and pages on the live website keep their identifying information.

10b. Advanced Options: Exclude spam comments. This can be left checked or unchecked as the local version of the website is unlikely to contain any spam comments. That is because the local website usually lacks exposure to the outside world to receive spam comments in the first place.

10c. Advanced Options: Exclude transients (temporary cached data). It is recommended to leave this as selected since it is unlikely that any cached data generated on the local copy of a website will need to be sent to the live one.

10d. Advanced Options: Do not push the 'active_plugins' setting. This is a setting in the wp_options database table. For the purposes of using WP Migrate DB Pro for content publishing, this table is usually NOT migrated in order to leave various settings on the live website unchanged (see 'TablePress (and the wp_options table)' below for more information). As a consequence, the migration for content publishing performed here should not affect WordPress plugin status whether this box is checked or not. However, for the sake of completeness, this option should be left as checked since there should be no reason to change the state of the plugins on the live website which may be different from their status on the local one.

11. Standard Find & Replace. This section is automatically populated when the migration plugin connects to the remote server. For content publishing purposes, leave this untouched.

Once these settings have been established and the connection to the remote server confirmed, (almost) all changes to posts or pages made on the local copy of the website can then be migrated to the live version at the touch of a button without affecting any other aspect of the live site.

Media Files

The WP Migrate DB Pro Personal license permits the migration of the WordPress database or selected tables from it. However, WordPress does not store the media (images and video) within the database itself. Instead, these are stored separately within the filing system of the website. Consequently, any website files of embedded images and/or video will also need to be separately migrated across to the remote site as well. 

This migration of media files can be done manually relatively easily via the standard WordPress backend. However, any new media files contained within a new post or page should be uploaded to the live website first before the database migration is performed. This will avoid empty image artefacts appearing in the media library (as shown in the image below). In the event such empty images are inadvertently created, these can simply be deleted before replacing them with the actual media files.  

Alternatively, a better way to deal with media file migration, and if one has the budget, is to opt for the more expensive Developer license of WP Migrate DB Pro which includes the migration of media files alongside the database migration.

Interactions With Other Popular WordPress Plugins

Thrive Architect and Thrive Theme Builder

Thrive Architect and Thrive Theme Builder make up the essential components of the increasingly popular Thrive Themes page builder, which is used to create content on numerous websites, DesktopVibes.com included. So how does the Thrive Themes ecosystem fare when it comes to migrating Thrive Themes-curated content from a local site to a live one using WP Migrate DB Pro? The answer is extremely well. In fact, it is sufficient to migrate only the wp_post and wp_postmeta tables in order to achieve full migration of any content produced within the Thrive Themes ecosystem.

TablePress (and the wp_options table)

A popular WordPress plugin for displaying tabular data on websites comes in the form of the TablePress plugin. Some of the data to make TablePress work is stored within the wp_options table of the database (in addition to the wp_posts and wp_postmeta tables). Unfortunately, a good deal of other website settings are contained within the wp_options table and migrating this table as part of our content-publishing process can create all manner of problems for the live website.

Settings on the local copy of the website will never be identical to those of the live one. That is because some things can only be done in a live environment. In the case of DesktopVibes.com, migrating the wp_options table from the local to the live website resulted in several unwanted changes and disconnections. For starters, the Jetpack connection to wordpress.com was disconnected, while the Google Analytics connection, mediated via the MonsterInsights plugin, was also severed. This was also true of the connection to Godaddy’s ManageWP, which is used to control some aspects of the website remotely as well as to get access to its backend. 

Some settings on other plugins were also changed when the wp_options table was migrated, for instance, XML sitemaps, which is used to generate and submit sitemaps to Google, showed a lack of sitemap submission after the migration. Thrive Themes Project Lightspeed (which happened to be deactivated on the local website) also became deactivated on the live website after the migration.

The list goes on, so much so that, in the end, it was not worth continuing to analyse all of the discrepancies encountered when including the wp_options table in the migration process. Ultimately, migrating the wp_options table is a big no-no if all you want to do is publish your content. Maybe the team in charge of WP Migrate DB Pro can introduce a way to allow migration of only certain records from the wp_options table so that we can pick and choose what gets updated on the live website. Hope springs eternal.

As for TablePress, since TablePress table-to-post association data and TablePress general options information are located in the wp_options table, this database table will become 'de-synchronised' from the TablePress information contained within the migrated wp_posts / wp_postmeta database tables if we can not migrate it as well. In addition, importing the TablePress tables (via the plugin's bespoke export-import facility) to overcome the wp_options table 'de-synchronisation' issue, will see the imported TablePress tabular data later overwritten when a WP Migrate DB Pro migration is performed to replace the wp_post & wp_postmeta tables. In other words, we have a problem when it comes to transferring new content containing TablePress tables to the live website as part of the WP Migrate DB Pro migration process.

So is there a solution for migrating TablePress tables? Yes, but it is not a pretty one!. First of all, the TablePress tabular data will migrate with the wp_posts & wp_postmeta tables as with other Post/Page data. As for the information contained within the wp_options table, the following records that pertain to the TablePress plugin need to be transferred manually:

To transfer this information, one needs to access the records on the local website database using a MySQL interface, such as phpMyAdmin or MySQL Workbench. Once retrieved, the information can then be used to replace the equivalent records in the live website database. The exact process on how to do this is documented in this follow-up article.  

Yoast SEO

Yoast SEO is another popular plugin that is used to optimise various aspects of posts and pages on websites. One aspect of the Yoast plugin that is relevant to content publishing via the WP Migrate DB plugin is the Yoast interface on the post's 'Edit Page'. This allows optimisation of the Focus Keyphrase, Google Preview, Meta Description, and other SEO-related aspects of the webpage. Some of this information is migrated via the wp_postmeta table, while other information is migrated within the wp_terms-related tables.

Therefore, as long as the six WordPress database tables, identified above as essential for content publishing, are migrated, then all relevant information contained within the Yoast interface on the post or page 'Edit' screen will be carried over to the live website.

Wordfence Security

Wordfence Security is a very popular WordPress security plugin that is installed on and used to protect millions of websites from being hacked. One of the ways the plugin protects websites is through the use of a firewall.

A common conflict arises when the Wordfence firewall mistakes some of the activity of the WP Migrate DB Pro plugin as malicious. In our testing, the initial use of the migration plugin did not trigger any sort of security issue from Wordfence. However, repeated migrations over a few days eventually led to a firewall rule being triggered which blocked all future migrations to the remote website. 

When the Wordfence firewall blocks WP Migrate DB Pro, the following error is generated within the migration plugin:

This can be rectified by doing one of two things. If the block is logged within the Wordfence 'Live Traffic' logs, then the action can be whitelisted directly through the Wordfence interface using the " ADD PARAM TO FIREWALL ALLOWLIST " button provided with the log entry. 

Alternatively, if the blocked traffic is not logged by Wordfence (which sometimes happens for reasons that are not clear), then the IP address hosting the local version of the website needs to be "Allowlisted" in the Wordfence's Advanced Firewall Options section shown below:  

However, it should be noted that the second method is the less preferred one since many broadband connections use dynamically generated IP addresses. This means that their IP addresses may change over time and any whitelisted ones entered above may require updating periodically.  

Restoring the original database

Finally, in the unlikely event one is unhappy with any part of the changes that have occurred to the live website following a WP Migrate DB Pro migration, as long as a database backup is available, it is a simple matter to restore the live website back to its original form. Importantly, a backup can be made during the plugin migration process itself or beforehand, via the migration plugin's 'Backups' tab.

To perform a restore of a WordPress database, proceed with the following actions:

This will replace the existing tables on the live website with those from the local one, and voila! the live website will have been returned to its original state.