All WordPress development must follow a spin up → develop → push → delete cycle for staging environments. Persistent staging environments are a liability: they consume server resources, drift out of sync with production, and create risk when pushed.
The goal is to always have exactly one active environment per site — production — and to treat staging as a temporary, disposable workspace.
Repeat this cycle for every discrete piece of work. Do not leave staging environments running between tasks.
A staging environment that was created weeks ago is no longer a true copy of production. Pushing stale staging to production will overwrite recent changes and introduce regressions. Creating a fresh copy at the start of each task eliminates this risk entirely.
WP Engine automatically rewrites URLs when pushing from staging to production — staging.example.com becomes example.com, and http:// becomes https://. This only works correctly when using the native push workflow. Manual search-and-replace operations on the database are error-prone and should be avoided.
Every environment is a full copy of the site. Two persistent environments means double the storage; three means triple. Across ~40 managed sites, orphaned staging and dev environments add up to significant unnecessary load. Deleting staging after each use keeps the footprint minimal.
Because the team is distributed across time zones, verbal coordination about who is using which environment is unreliable. The push-and-delete model means there is never ambiguity: if a staging environment exists, someone is actively using it right now.
Because developers work asynchronously, a shared tracking mechanism is required so team members don't accidentally overwrite each other's work. The recommended approach is a simple shared sheet (Google Sheet or equivalent) with:
This sheet must be kept current. An outdated entry is worse than no entry — it destroys confidence in the whole system. Developers should update the record when they spin up and again when they delete.
Owner: Isalia is responsible for developing and maintaining this tracking process.
Developers may build on a local WordPress environment (e.g., Local by Flywheel) for speed. When local work is ready, the recommended path is:
Avoid uploading compressed file archives manually — this bypasses URL rewriting and version tracking.
| Anti-pattern | Problem |
|---|---|
| Leaving staging environments running indefinitely | Wastes resources; environment drifts from production |
| Pushing from a staging environment that wasn't freshly copied | Overwrites recent production changes |
| Manually doing search-and-replace on URLs after a push | Error-prone; WP Engine handles this automatically in the push workflow |
| Working directly in production | No safety net; breaks are immediately live |