WPop

WordPress operations CLI for Websimple projects.

Deploy environment

wpop deploy needs:

• REMOTE_HOST
• REMOTE_PORT
• REMOTE_USER
• REMOTE_PATH

If any REMOTE_* value is missing, wpop reads the site's Actions variables (repository variables over organization variables), looking on GitHub first (websimple-com/<slug>), then on Gitea (wp-sites/<slug>) for sites that have not moved yet. The first source that provides every required value wins.

• GitHub token: WPOP_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN, or the GitHub CLI login (gh auth login)
• Gitea token (read-only is enough): WEBSIMPLE_GITEA_API_TOKEN, WPOP_GITEA_TOKEN, or GITEA_TOKEN

The slug is the name of the origin repository (whatever its host), or the directory name when there is no origin. You can override this with:

• WPOP_GITHUB_REPO=websimple-com/example, WPOP_GITHUB_OWNER=websimple-com
• WPOP_GITEA_REPO=wp-sites/example
• WPOP_GITEA_OWNER=wp-sites and WPOP_GITEA_REPO_NAME=example
• WPOP_GITEA_BASE_URL=https://gitea.websimple.com

Provision

wpop provision <slug> clones websimple-com/<slug> from GitHub when your SSH key can read it; otherwise it uses Gitea wp-sites/<slug>, creating it from templates/wp-boilerplate if missing.

Frontend builds

Before syncing, wpop deploy builds frontend assets (skip with --skip-node):

1. the site root, when it has a package.json — a frontend kept at the repository root that builds into a theme's dist/ (e.g. a Lovable-connected site);
2. every wp-content/themes/*/ that has its own package.json.

The lockfile picks the package manager: bun.lock → bun, pnpm-lock.yaml → pnpm, yarn.lock → yarn, otherwise npm. Installs are frozen, so a package.json change without its lockfile fails the deploy. The CI runner needs the matching tool (e.g. oven-sh/setup-bun for bun).