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 :
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.
