This article covers restoring a backup of an AccessAlly site and how to prevent tech hiccups during the process by using a staging site.
ARTICLE CONTENT:
Part 1: When should you restore a backup on a live AccessAlly site?
Restoring on a live site AccessAlly site should only be used as a last resort for critical failures.
Restoring is a very dangerous operation, as it erases a portion of the site history. When it absolutely must be performed, the restore timepoint should be as recent as possible. Restoring the live site should be done sparingly as there are better ways to do testing outlined in this article below.
If an AccessAlly site backup is restored any prior payments that were processed during the in-between period are erased and can result in duplicate charges!
Duplicate charges from a backup restore are tricky to find and eliminate because of the site history being erased during the restore!
Part 2: When should you use a staging site?
Staging sites are helpful when doing in-depth development/testing, or migrating from one WordPress course or membership plugin to another, it is preferred to clone the live site to a staging/development site. Changes should be made to the staging/development site and thoroughly tested. Once satisfied, the staging/development site can be deployed to the live site.
The purchase data on the live site will need to be migrated and you can find the tutorial here.
Part 3: How to manage small changes or tweaks to your live AccessAlly site.
If you’re making minor changes that can be performed in a day or less, these can be performed on your live site directly after testing on your staging site. This method is a bit riskier than option 2 above, but you might decide to do this versus a full staging site deployment.
Click here to learn how to set up a Staging Site on WordPress.
