Copy Environment
If you have made changes to an environment and want to deploy or copy those changes to another environment you will need to use the User Portal function called “Copy Environment”.
Copy Environment
The copy process can be done between any of the 3 environments (PRD, STG, DEV) within a site. Our copy system uses backups, so a fresh backup will be made automatically of the source and target environments when the copy is initiated.
- If you need to copy an older checkpoint, or copy to an environment within another site, use the backup and restore functionality instead. Read more about this here.
- If you are copying a multisite network, we also recommend reading the article Multisite Deployment Best Practices first.
NOTE
To prevent any visual discrepancies, downtime or missed orders, we suggest that you enable a maintenance page on the Source environment before initiating the Copy Site process. Maintenance mode can be enabled through a plugin, or by triggering the default WordPress functionality.
- Log in to the User Portal
- Select an environment name
- Click Copy environment on the top right
- This button will be greyed out if there are no other environments within the site. See the section “Restore a Backup from One Environment to Another” for more information or learn how to add a new environment.
- Source environment: Ensure this is the correct environment that you want to copy content and/or data from
- Target environment: Select the desired environment you wish to copy to
- Include: Select one of the following options-
- All database tables and file system
- Copying the database to production can be destructive, so we advise doing so with caution. The target database will be rewritten when selecting this option, which can cause the loss of new orders and users. Read more about copying to Production or learn more about what the database includes.
- (BETA) Specific database tables and file system
- Allows you to partially copy the database by specifying tables. Read more about what the database includes.
- This option may be useful if you have a large website or if you only need to test updates on a handful of subsites.
- Copying the database to production can be destructive, so we advise doing so with caution. Learn more about copying the database to production.
- File system only
- This option is typically recommended when copying to production as the database will not be replaced. Read more here.
- All database tables and file system
NOTE
If the database is included, a search and replace will be run automatically to update the domain name.
On a multisite network this search and replace may look different than expected, so we recommend reviewing this article beforehand.
- Enter email address(es), separated by commas, to be notified at when the copy is complete
- Click Review and confirm
- Review the details of the copy process, such as the source and target environments, database include options, and notification email(s)
- When ready to start the process, click Looks good, copy the environment
You will receive an email when the copy process is complete. Large environments may take a while. Once a copy has been initiated, do not make additional changes to either environment.
Database Include Options
Each copy process includes the file system by default, but copying the database is optional.
The file system includes: media, images, stylesheets, plugin files, scripts, wp-config.php, etc.
The database includes: all posts, pages, users, custom post types (EX: WooCommerce orders), and certain settings. It’s possible for the database to also contain theme and plugin settings. This will vary based on the asset so if there are questions, reaching out to the author directly would be best if you aren’t sure.
When the database is included, a search and replace will automatically be run to update the source domain to the destination domain. Learn more about this process here.
If the environment is a multisite network, this search and replace will work similarly, but the results may look different than expected. We recommend reviewing this article before copying.
All database tables
Copying the database can be destructive, meaning that the entire database will be overwritten if the database is included in the copy. If you wish to copy the database to production, we advise doing so with caution.
Tables that exist on the source but do not exist on the destination will be added.
Tables that exist on the destination but not the source will be left as-is on the destination and not be removed.
Only the file system
No database information will be copied to the target environment. The database will remain as-is.
Specific database tables
This option allows you to copy some database tables and exclude others. This option is only available when copying between environments within the same site, and therefore is not available when restoring a backup or copying between environments of different sites.
There might be scenarios where you only want to copy certain database tables. For example:
- You’ve installed a theme or a plugin and only want to copy the tables related to that
- You’ve added content to the target environment since the last copy and you hope to preserve that data when pushing back
You can do this by choosing only specific tables that you want to copy. Ultimately you may need to refer to your plugin or theme support if you’re not sure which tables hold data you wish to not overwrite.
NOTE
Copying the database to production can be destructive, so we advise only doing so with caution.
When selecting this option you can either choose specific database tables, or you can use “select all” tables, then search or scroll through the list of tables and uncheck them.
To push all changes except for pages, posts and users to your target environment, select all database tables except:
wp_posts
wp_postmeta
wp_users
wp_usermeta
If you are using WooCommerce the tables WooCommerce stores Order data you may want to exclude from the deployment. It might be a good idea to exclude the user information as well. In this case, exclude the following tables:
wp_posts
wp_postmeta
wp_woocommerce_order_items
wp_woocommerce_order_itemmeta
wp_users
wp_usermeta
For more information on deploying WooCommerce, see WooCommerce Best Practices.
NOTE
If you’re using a custom database prefix, these would read yourprefix_tablename instead of wp_tablename.
Copy Database to Production
It is typically not recommended to copy a database to a Production environment, as the database will be rewritten entirely with the Staging/Development contents. This destructive process can cause the loss of important data, such as new orders or users.
If posts or pages were added to the Staging/Development environment, the easiest solution is to use the WordPress Default Export/Import Tools to manually migrate that content to Prod. If more specific export parameters are necessary, then WP All Export has more customizable export options.
Alternatively, if you have added content to Production but need to push the Staging/Development database for some other reason, the content will need to be exported from Production before the copy, then imported back to Production after the copy has completed. The WordPress Default Export/Import Tools can be used for this as well as WP All Export for more customizable export options.
If you are using a theme that stores settings in the database, it would be best make the changes on Production and leverage the Preview Site theme feature as well as our Backup system.
If you are deploying a WooCommerce site, we recommend reviewing WooCommerce Best Practices first.
Copy Tips
User Portal 301/302 redirects, custom cache exclusions, Nginx rules and any other custom WP Engine server configuration options will not be copied using these processes.
These rules exist only if added manually, so in most cases will not cause issues when not copied. The WP Engine Support team is happy to manually copy over any custom rules if necessary, by request.
We suggest that you enable a maintenance page on the Source environment before initiating the Copy Site process. Maintenance mode can be enabled through a plugin, or by triggering the default WordPress functionality.
This is done to prevent any visual discrepancies, downtime or missed orders. Maintenance mode can be enabled with a plugin or by leveraging default WordPress functionality.
NEXT STEP: Learn about the WP Engine backup and restore system
