Development & Version Control
How the codebase should be managed, deployed, and maintained.
Current State
Both sites are deployed via GitHub Actions, but this configuration cannot be inherited. It will be your responsibility to pull down the current codebase, and set up your own CI/CD pipeline.
Recommended Setup
The correct process for maintaining these sites going forward is:
- Source control — each site in its own Git repository (or a monorepo with clear boundaries)
- CI/CD pipeline — automated builds, linting, and deployment triggered by branch merges
- Three environments — development, staging, and production
- Branch workflow — feature branches → pull request → code review → merge to main → auto-deploy to staging → promote to production
Environment Strategy
| Environment | Purpose | When to deploy |
|---|---|---|
| Development | Local or shared dev instance for active work | Continuous |
| Staging | QA and client review before production | On merge to main |
| Production | Live customer-facing sites | Manual promotion from staging |
WP Engine supports staging environments (one per install) with snapshot-based syncing. For a proper multi-environment setup, you may want to use WP Engine's staging for QA and a local Docker environment for development.
What's Been Stripped From This Doc
The previous developer's local environment configuration, Docker setup, and tooling-specific details have been intentionally removed from this documentation.
You'll need to establish your own:
- Local development environment — Docker, Local by WP Engine, MAMP, or whatever your team uses
- CI/CD pipeline — GitHub Actions, GitLab CI, Buddy, or WP Engine's own deployment tools
- Code review process — branch protection rules, required reviewers, automated checks
- Staging workflow — how changes get promoted from staging to production
The architecture, plugin system, theme structure, and business logic documented elsewhere in these docs are the durable knowledge. The development tooling around them is yours to define.
Key Constraints
A few things to keep in mind when setting up your workflow:
- WP Engine git deploys are push-to-deploy. There's no build step on their end — what you push is what runs. If your build process generates output (compiled assets, etc.), that output must be in the repo or built before push.
- Cloudflare R2 credentials are needed for media offload. These are configured via environment variables (
S3_UPLOADS_*) inwp-config.custom.phpand must be set in each environment. - Plugin updates should be tested in dev & staging first.
Database
The sites use the database as a primary content store (not just configuration). Fusion Builder page content, Avada theme options, ACF field values, WooCommerce products, and custom report data all live in the database. A fresh WordPress install with the correct theme and plugins will not produce a working site — you need the database.
WP Engine provides database snapshots and export tools. Establish a regular backup cadence beyond what WP Engine provides automatically.