Who this is for. The developer who needs production's content somewhere safe: to reproduce an issue, rehearse a migration or build against real data. Afterwards you can ask for a copy that is safe from the start, and make it safe in a fixed order when it is not.
On Core dna that means a copy of the site's database on a development platform, made by Core dna on request. The copy is identical to production in every way that matters for harm: the same members, the same jobs, the same payment methods with the same keys, the same site data. It is safe only after the steps below.
What to ask for
- The copy in development mode. Mode is set per environment folder by Core dna, not by anything in the database, so ask for it explicitly. In production mode the copy sends mail to real recipients.
- Without customers' personal data, unless the task needs it. Agree with Core dna what the copy leaves out or replaces: members and people, addresses, orders, invoices, form submissions and mail recipients. Content, layouts, jobs, forms and settings are usually all a developer needs.
- Hostnames nobody outside the team knows, and a date when the copy will be deleted.
How development mode handles mail
In any mode other than production, each outgoing email is checked against the Mailer setting Development email whitelist, a regular expression. A recipient that matches it receives the mail; any other recipient is replaced by the address in Development email. Both settings belong to the account, so they apply to every site on it, but they take effect only where the mode is not production. Before the copy is used, set Development email to your team's inbox and keep the whitelist to your own domain.
The reset checklist
Work through it in order, before anyone browses the copy and before any scheduled job can run:
- Mail. Confirm the mode: submit a form whose notification goes to a mailbox you control outside the whitelist, such as a personal address, and check that the mail arrives at the development address instead. If it reaches the mailbox, the copy is in production mode: stop and ask Core dna to switch it.
- Payments. Switch every payment method to Test Mode with the provider's sandbox keys, or untick Active. A copy that takes a payment takes real money; Disabling test providers is the same check in reverse.
- Tax. Put each tax provider in its sandbox (Avalara's sandbox environment, Stripe Tax's test mode), or point the copy's zones and default provider at a mock tax provider. Otherwise the copy reports real tax transactions.
- Jobs. Unpublish every scheduled job and every job that calls an outside system, then publish only the ones the task needs, pointed at sandboxes. A nightly export to a partner runs on the copy exactly as on production.
- Site data. Replace every live API key and URL with its sandbox equivalent.
- Sign-in providers. Disable external sign-in, or register the copy's own redirect addresses with each provider (the providers).
- Hostnames and robots. The copy answers only its own hostnames, and every page carries
noindex. The "primary environment only" tests in production's templates do not protect a copy, because the copy carries the same environment records (two legitimate uses). - Analytics and tags. Make sure no production tag manager container or pixel loads, or the copy's test traffic lands in the client's reports.
- Search. Reindex, because the copy's index does not match its records (search and environments).
- Access. Members' and administrators' passwords work on the copy as they do on production. Limit who knows the hostnames, and remove administrator accounts that do not need access.