# Une prévisualisation par branche avec Cloudflare Pages pour un thème

> Publier automatiquement une démo statique d'un thème à chaque branche poussée, pour une revue client en quelques secondes.

- Auteur : Clément Hadrot
- Publié le : 2024-01-06
- Mis à jour le : 2024-01-06
- Catégorie : Outils &amp; workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/cloudflare-pages-preview-branche-theme/

## L’essentiel

- Chaque branche obtient une URL de prévisualisation dédiée
- L'export statique évite d'exposer une base de données
- Le client valide sans jamais toucher à un accès SSH

Une agence qui livre des maquettes de thème à des clients qui ne connaissent pas WordPress se heurte toujours au même problème : comment montrer une évolution visuelle sans donner un accès admin, sans monter un environnement complet, et sans attendre le prochain point hebdomadaire ? Pour un thème dont le contenu ne dépend pas d'une base de données changeante, l'export statique publié sur Cloudflare Pages répond exactement à ce besoin.

L'idée tient en une phrase : à chaque branche Git poussée, un job génère un export HTML statique du thème avec un jeu de contenu de démonstration figé, et Cloudflare Pages le publie sur une URL propre à cette branche. Le client clique sur un lien dans la pull request, sans rien installer.

## Pourquoi le statique suffit pour une revue de thème

Un thème WordPress classique, en dehors de ses templates PHP dynamiques, produit un rendu qui dépend surtout de la structure du contenu et des styles appliqués : disposition des articles, en-tête, pied de page, composants réutilisables. Pour une revue visuelle, un site figé au moment de la génération suffit largement : le client ne cherche pas à publier un nouvel article, il veut voir si le nouveau design de la page d'accueil lui convient.

Générer un export statique depuis un WordPress complet reste possible grâce à des outils comme `wp-static-html-output` ou un simple crawl avec `wget --mirror` sur une instance temporaire. En pratique, l'approche la plus fiable reste de lancer WordPress dans un conteneur éphémère à chaque build, de le peupler avec un jeu de contenu de démonstration versionné dans le dépôt, puis de l'exporter en HTML.

## Le pipeline, étape par étape

Le workflow GitHub Actions suivant tourne sur chaque push, quelle que soit la branche :

> L'essentiel à retenir : Chaque branche obtient une URL de prévisualisation dédiée ; L'export statique évite d'exposer une base de données ; Le client valide sans jamais toucher à un accès SSH

```
name: Preview thème
on: push
jobs:
  build-preview:
    runs-on: ubuntu-latest
    services:
      db:
        image: mariadb:10.11
        env:
          MARIADB_ROOT_PASSWORD: root
          MARIADB_DATABASE: wordpress
    steps:
      - uses: actions/checkout@v4
      - name: Démarrer WordPress
        run: |
          docker run -d --name wp --network host \
            -e WORDPRESS_DB_HOST=127.0.0.1 \
            -e WORDPRESS_DB_NAME=wordpress \
            -e WORDPRESS_DB_PASSWORD=root \
            -v ${{ github.workspace }}/theme:/var/www/html/wp-content/themes/demo \
            wordpress:6.4-php8.2
      - name: Attendre et installer
        run: |
          sleep 10
          docker exec wp wp core install --url=http://localhost --title=Demo \
            --admin_user=admin --admin_password=admin --admin_email=demo@example.com --allow-root
          docker exec wp wp theme activate demo --allow-root
          docker exec wp wp import content/demo.xml --authors=create --allow-root
      - name: Exporter en statique
        run: wget --mirror --convert-links --page-requisites -P dist http://localhost/
      - name: Publier sur Cloudflare Pages
        run: npx wrangler pages deploy dist --project-name=theme-preview --branch=${{ github.ref_name }}
```

### Le fichier de contenu de démonstration

Le fichier `content/demo.xml` mérite un vrai soin : c'est un export WXR classique, produit une fois depuis un site de référence via *Outils > Exporter*, puis versionné dans le dépôt du thème. Il contient un jeu d'articles, de pages et de médias représentatif, avec des textes réalistes plutôt que du lorem ipsum, pour que la revue visuelle soit crédible.

## L'URL de prévisualisation par branche

Cloudflare Pages attribue automatiquement une URL de la forme `<nom-de-branche>.theme-preview.pages.dev` à chaque déploiement identifié par son nom de branche. Une branche nommée `feature/nouvelle-page-accueil` devient accessible à une URL prévisible, que l'on peut coller directement dans la description de la pull request grâce à une étape supplémentaire qui poste un commentaire automatique :

```
- name: Commenter la PR avec le lien
  if: github.event_name == 'pull_request'
  uses: actions/github-script@v7
  with:
    script: |
      const branch = context.payload.pull_request.head.ref
        .replace(/[^a-z0-9-]/gi, '-').toLowerCase();
      github.rest.issues.createComment({
        ...context.repo,
        issue_number: context.issue.number,
        body: `Prévisualisation disponible : https://${branch}.theme-preview.pages.dev`
      });
```

## Les limites à connaître avant de vendre l'idée

Cette approche ne convient pas à tout. Les formulaires de contact, les blocs interactifs qui appellent l'API REST de WordPress, ou tout élément dépendant d'un plugin de e-commerce ne fonctionneront pas dans l'export statique. Il faut le dire clairement au client : ce qu'il voit est une photographie visuelle du thème, pas un site fonctionnel. Sur un projet récent pour une étude d'avocats, la navigation et les pages de contenu passaient très bien en statique, mais le formulaire de prise de rendez-vous devait être testé séparément sur un environnement de staging classique.

- Les formulaires et l'API REST ne fonctionnent pas dans un export statique.
- Le contenu affiché est figé au moment du build, pas en temps réel.
- Un thème qui dépend fortement de requêtes dynamiques (recherche, filtres AJAX) demande un environnement complet, pas ce pipeline.

> Un lien de prévisualisation qui s'ouvre en quinze secondes convainc plus un client qu'une longue explication sur l'état d'avancement du projet.

## Pour aller plus loin

Ce pipeline reste volontairement limité au rendu visuel statique d'un thème. Pour un besoin de revue incluant l'administration WordPress complète, avec une base de données persistante par pull request, une architecture d'environnement éphémère bien plus lourde s'impose, et elle mérite un traitement à part entière. Pour la simple validation d'un design de thème, en revanche, cette combinaison export statique et Cloudflare Pages reste la solution la plus rapide à mettre en place et la moins chère à faire tourner.
