Development Best Practices (No Version Control)

WP Engine supports a variety of different development workflow methods. There are general best practices for site development that you should keep in mind. By sticking to these general rules, you can help ensure you don’t overwrite important information on your Production site when making changes. These practices are especially important when managing multiple copies of the same site.

NOTE

If you use a version control system like Git to manage changes to your site, please use our best practices guide for version control instead.


Database Moves Down, Code Moves Up

The “top” layer in this scenario is your live or Production environment.

The “bottom” layer is the environment you’re developing in. This may be Staging, Development or your local development environment.

Therefore, code moves up to Production and the database moves down to develop.

It is never advised to include a database when copying to a live site.


You should never blindly copy database data into Production environments. The reason this concept works is that it is based on the understanding that your site’s database is in a constant state of flux. There are new articles being published, new orders received, new users registered, and other actions happening daily on the site.

By never copying your databases “up” towards production, you do not run the risk of overwriting newer data.

Copying the database “down” works equally well with databases of any size, as your development instances would be the ones in flux when the database changes are being applied.


Deploy Site

First you’ll want to ensure you’d created a Staging or Development environment to work with. Follow this guide to learn how to add Staging/Development and to read more about these environments.

Once you have defined your Environments, you can begin to deploy your site.

  1. Copy database down
  2. Deploy code up

Be sure to only make changes to the code and file system in Staging/Development. Do not make changes to the database, as these won’t be carried to Production.


Deploy Database to Production

While it is not advised, it may still happen that you’ve already added changes to your Staging/Development database and need to copy those up to Production.

In these cases the file system can be pushed as normal, with the changes must be exported and imported- essentially performing the database portion of the copy manually.

  1. Copy the file changes from the Staging/Development to Production
    • Be sure to select No for “Include database?”
  2. Export the changes from the Staging/Development database
  3. Import the changes to the Production database

Export/Import Tools

WordPress Default Export/Import Tools  — These exports can be excessively large, however if you just need to move a few posts this is a great option.
Export/import tables using phpMyAdmin – Export and import specific tables directly from phpMyadmin, without needing to login to the WordPress dashboard.
WP All Export — Allows many options for exporting

Export/Import WooCommerce Data:
WooCommerce CSV Importer/Exporter — Built-in WooCommerce product exporter/importer
Export/Import Plugin For WooCommerce — Helpful for exporting Orders
WooCommerce CSV Import Suite — Paid export/import suite provided by WooCommerce
WP All Export for WooCommerce — Helpful to export/import of Products

NOTE

When using WooCommerce, we recommend enabling High Performance Order Storage, which separates orders into dedicated tables. This can improve performance and simplify deployments. Learn more here.


NEXT STEP: Best practices when copying a multisite

Code-level performance analytics

Application Performance provides real-time, code-level visibility to help you troubleshoot faster, optimize WordPress experiences, and increase development agility.