# Variables d'environnement — où va quoi

Trois destinations distinctes. Ne pas mélanger.

> `create-wp-reactor --provision` renseigne les trois automatiquement, et génère
> les secrets au passage — ce document décrit alors ce qu'il a posé. Voir
> [`deploy.md`](./deploy.md).

## 1. Local (`.env`, gitignored)

Pour `docker-compose.dev.yml` + `pnpm dev`. Copie `.env.local.example` → `.env`.

| Variable | Rôle |
|---|---|
| `WP_PORT` | Port hôte du WordPress local (ex. 8890) |
| `WP_HOME` | URL du WP local (`http://localhost:${WP_PORT}`) |
| `FRONTEND_URL` | URL de la webapp en dev (`http://localhost:3000`) |
| `WORDPRESS_DB_NAME/_USER/_PASSWORD`, `MYSQL_ROOT_PASSWORD` | DB locale |
| `WP_SITE_TITLE`, `WP_ADMIN_USER/_PASSWORD/_EMAIL` | Provisioning (`pnpm docker:bootstrap`) |
| `VITE_*` | Bakées par Vite au `pnpm dev` (front) |
| `SESSION_SECRET` | Sceau du cookie de session (auth) |
| `WP_USER`, `WP_APP_PASSWORD` | `pnpm push:page` (Application Password WP) — inutiles en `--dry-run` |

> `push:page` lit aussi `WP_URL`, qui retombe sur `VITE_WORDPRESS_URL` s'il est absent.

> L'image WordPress de base est **privée** (GHCR). Avant le 1er `up` :
> `echo <PAT read:packages> | docker login ghcr.io -u <user> --password-stdin`

## 2. GitHub (CI — `.github/workflows/deploy.yml`)

Repo → *Settings* → *Secrets and variables* → *Actions*.

**Secrets** (sensibles) :

| Secret | Rôle |
|---|---|
| `COOLIFY_URL`, `COOLIFY_TOKEN` | API Coolify (déclenche le redeploy) |
| `COOLIFY_WEBAPP_UUID`, `COOLIFY_WORDPRESS_UUID` | UUID des apps Coolify à redéployer |

> `GITHUB_TOKEN` est fourni automatiquement (push GHCR + lecture des packages
> `@wp-reactor/*` privés au build). Aucun PAT à créer côté CI.

**Variables** (non sensibles, `vars.*`, bakées au build Vite) :

| Variable | Rôle |
|---|---|
| `VITE_WORDPRESS_URL` | URL publique du WordPress (`https://${WP_HOST}`) |
| `VITE_FRONTEND_URL` | Origine publique du site (`https://${APP_HOST}`) — réancre les URLs SEO fabriquées par RankMath depuis le domaine backend |
| `VITE_GRAPHQL_PATH` | Chemin GraphQL (`/graphql`) |
| `VITE_FEATURE_EDITORIAL/_ECOMMERCE/_AUTH` | Flags de modules |

## 3. Coolify (runtime des apps déployées)

Dans chaque application Coolify (webapp / WordPress), onglet *Environment Variables*.
Ce sont les variables **runtime** (lues à l'exécution), distinctes des `VITE_*`
qui, elles, sont figées au build.

**Ressource WordPress** (Docker Compose — `apps/wordpress/docker-compose.yml`) :

| Variable | Rôle |
|---|---|
| `WORDPRESS_IMAGE` | Image GHCR tirée par le compose (`ghcr.io/<owner>/<repo>/wordpress:main`) ; rollback = tag `:<sha>` |
| `WP_HOST`, `APP_HOST` | Hosts lus par les **labels Traefik** du compose (`wp.…` / front, **sans** schéma) |
| `WORDPRESS_DB_HOST/_NAME/_USER/_PASSWORD` | Connexion DB (ressource Coolify séparée) |
| `WP_HOME`, `WP_SITEURL` | `https://${WP_HOST}` |
| `FRONTEND_URL` | `https://${APP_HOST}` (redirection headless) |
| `WP_REDIS_HOST`, `WP_REDIS_PASSWORD` | Cache objet Redis (ressource Coolify séparée) |
| `CACHE_PURGE_SECRET` | Secret du webhook qui périme le cache HTML de la webapp à chaque publication. Doit être **identique** côté webapp |
| `WP_ENVIRONMENT_TYPE`, `WP_DEBUG` | Environnement |
| `WP_AUTO_BOOTSTRAP` | À `1`, l'entrypoint provisionne WordPress au démarrage (idempotent) — remplace le `docker exec … bootstrap.sh` manuel |
| `WP_SITE_TITLE`, `WP_ADMIN_USER/_PASSWORD/_EMAIL` | Compte admin créé par ce bootstrap. **Requis** si `WP_AUTO_BOOTSTRAP=1` |

> `WORDPRESS_DB_HOST` et `WP_REDIS_HOST` d'une ressource **managée** Coolify
> valent l'**UUID** de la ressource, pas son nom d'affichage.

> ⚠️ NE PAS définir `WORDPRESS_CONFIG_EXTRA` ni `WORDPRESS_DEBUG` côté Coolify :
> la config est bakée dans l'image base (`wp-reactor-config.php`). Utiliser `WP_DEBUG`,
> que l'entrypoint mappe sur `WORDPRESS_DEBUG`.

**App Webapp** :

| Variable | Rôle |
|---|---|
| `WORDPRESS_INTERNAL_URL` | URL interne du WP en SSR (`http://__PROJECT_NAME__-wordpress-internal`) |
| `SESSION_SECRET` | Sceau du cookie de session — **lu au runtime** (≥ 32 car., `openssl rand -base64 48`) |
| `NODE_ENV` | `production` — active le flag `secure` des cookies (session/panier) |
| `CF_ZONE_ID`, `CF_API_TOKEN` | Purge du cache edge en post-deploy (`scripts/clear-cache.mjs`) ; cf. [`deploy.md`](./deploy.md) |
| `REDIS_URL` | Cache HTML côté origine : `redis://:<WP_REDIS_PASSWORD>@<uuid-redis>:6379`. **Même instance** que l'object cache WordPress, isolée par préfixe de clé. Absent ⇒ cache désactivé |
| `CACHE_PURGE_SECRET` | Secret du webhook `/api/cache/purge` — **identique** à celui de WordPress |

> `HTML_EDGE_MAX_AGE` / `HTML_EDGE_SWR` (TTL du cache edge du HTML SSR) sont
> optionnels — défauts 600 / 86400 s. Idem `HTML_CACHE_TTL` /
> `HTML_CACHE_STALE_TTL` pour le cache Redis (fraîcheur 3600 s, rétention
> 86400 s) : le HTML reste servable pendant toute la rétention, et c'est ce qui
> évite une 502 quand WordPress redémarre.

## TLS / routing

Les **labels Traefik** (host, TLS, cache, compression) ne sont pas des variables d'env :

- **WordPress** : inline dans `apps/wordpress/docker-compose.yml` (versionnés). Ils
  interpolent `WP_HOST` / `APP_HOST` depuis l'env ci-dessus.
- **Webapp** : posés par `--provision` (ou collés dans l'UI Coolify) → voir
  [`traefik-labels.md`](./traefik-labels.md).