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.
- Copy database down
- Copy Production to Staging/Development Environment
- Be sure to select Yes for “Include database?”
- Deploy code up
- After changes are developed, copy the file changes from the Staging/Development to Production
- Be sure to select No for “Include database?”
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.
- Copy the file changes from the Staging/Development to Production
- Be sure to select No for “Include database?”
- Export the changes from the Staging/Development database
- 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
NEXT STEP: Best practices when copying a multisite
