Hébergez votre propre Playground
Vous pouvez héberger le Playground sur votre propre domaine au lieu de playground.wordpress.net.
C'est utile pour avoir un contrôle total sur son contenu et son comportement, ainsi que pour supprimer la dépendance à un serveur tiers. Cela peut fournir une expérience utilisateur plus personnalisée, par exemple : un playground avec des plugins et thèmes préinstallés, des paramètres de site par défaut ou du contenu de démonstration.
Avant de commencer
L'auto-hébergement de Playground vous donne un contrôle total, mais nécessite de comprendre quelques concepts clés :
À quoi s'attendre
- Complexité de configuration initiale : La construction et le déploiement de Playground impliquent plusieurs étapes. Prévoyez du temps pour le dépannage lors de votre premier déploiement.
- Hébergement de fichiers statiques : Playground est principalement composé de fichiers statiques (HTML, JS, WASM) avec des exigences minimales côté serveur.
- Exécution basée sur le navigateur : Tout le traitement WordPress se fait dans le navigateur de l'utilisateur via WebAssembly—votre serveur ne fait que livrer les fichiers.
Considérations de performance
Les temps de chargement dépendent de plusieurs facteurs :
| Facteur | Impact | Optimisation |
|---|---|---|
| Taille du plugin | Les gros plugins (ex. WooCommerce) peuvent prendre 30-60 sec à installer | Préinstallez les plugins dans votre build WordPress |
| Vitesse du réseau | Les fichiers WASM font ~15-30 Mo | Utilisez un CDN avec des en-têtes de cache appropriés |
| Navigateur | Chrome/Edge sont les plus performants ; Safari utilise des mécanismes de secours | Testez sur différents navigateurs |
| Appareil | Les appareils mobiles chargent plus lentement que les ordinateurs | Avertissez les utilisateurs mobiles des temps de chargement plus longs |
Compatibilité des navigateurs
Playground fonctionne sur les navigateurs modernes, mais avec quelques différences :
| Navigateur | Statut | Notes |
|---|---|---|
| Chrome/Edge | ✅ Meilleure performance | Support complet de toutes les fonctionnalités |
| Firefox | ✅ Bon | Performance fiable |
| Safari | ✅ Bon | Des améliorations récentes ont significativement amélioré la fiabilité |
| Navigateurs mobiles | ⚠️ Limité | Fonctionne, mais avec une utilisation mémoire plus élevée, et une connexion 4G peut impacter l'expérience |
Note technique : Safari utilise MessagePorts au lieu de SharedArrayBuffer pour les réponses en streaming. Ce mécanisme de secours fonctionne de manière fiable mais ajoute une légère surcharge par rapport à Chrome/Edge.
Utilisation
Un Playground auto-hébergé peut être intégré comme une iframe.
<iframe src="https://my-playground.com"></iframe>
Ou chargé dynamiquement en passant l'URL distante au Client Playground.
import { startPlaygroundWeb } from '@wp-playground/client';
const client = await startPlaygroundWeb({
iframe: document.getElementById('wp'),
remoteUrl: `https://my-playground.com/remote.html`,
});
Ressources statiques
Il existe plusieurs façons d'obtenir les ressources statiques nécessaires pour héberger le Playground.
Par ordre de commodité et de facilité :
- Télécharger le package pré-construit
- Forker le dépôt et construire avec GitHub Action
- Construire localement
Télécharger le package pré-construit
Pour héberger le Playground tel quel, sans modification, vous pouvez télécharger l'artefact construit depuis la dernière GitHub Action réussie.
- Cliquez sur Deploy Playground website.
- Dans la section Artifacts en bas de la page, cliquez sur
playground-website. - C'est un package zip avec les mêmes fichiers déployés sur le site public.
Forker le dépôt et construire avec GitHub Action
Pour personnaliser le Playground, vous pouvez forker le dépôt Git.
Construisez-le depuis la page GitHub de votre fork en allant à : Actions -> Deploy Playground website -> Run workflow.
Construire localement
La méthode la plus flexible et personnalisable est de construire le site localement.
Créez un clone superficiel du dépôt Playground, ou de votre propre fork.
git clone -b trunk --single-branch --depth 1 --recurse-submodules https://github.com/WordPress/wordpress-playground.git
Entrez dans le répertoire wordpress-playground.
cd wordpress-playground
Installez les dépendances et construisez le site web.
npm install
npm run build:website
Cette commande exécute en interne la tâche nx build:wasm-wordpress-net. Elle copie les ressources construites des packages remote et website dans un nouveau dossier au chemin suivant :
dist/packages/playground/wasm-wordpress-net
L'ensemble du service du Playground consiste en le contenu de ce dossier.
Résumé des fichiers inclus
Les ressources statiques incluent :
- Fichiers de données et WASM pour toutes les versions PHP et WordPress disponibles
remote.html- le cœur du Playgroundindex.html- le shell, ou chrome du navigateur- Script Web Worker
Vous pouvez déployer le contenu du dossier sur votre serveur en utilisant SSH, comme scp ou rsync.
C'est un site statique, sauf pour ces aspects dynamiques.
- Fichier de directive serveur Apache
.htaccessdu packageremote
Pour que ceux-ci fonctionnent, vous avez besoin d'un environnement serveur avec Apache et PHP installés.
Configuration NGINX
Comme alternative à Apache, voici un exemple d'utilisation de NGINX pour servir le Playground.
L'exemple peut être obsolète. Veuillez vérifier le fichier source pour la dernière version.
Le fichier Apache .htaccess combiné ressemble à ceci.
AddType application/wasm .wasm
Un équivalent en NGINX.
location ~* .wasm$ {
types {
application/wasm wasm;
}
}
Vous devrez peut-être ajuster ce qui précède selon les spécificités du serveur, en particulier comment invoquer PHP pour le chemin /plugin-proxy.
Le serveur web Caddy ne nécessite aucune configuration spéciale pour fonctionner.
Personnaliser les données empaquetées
Le fichier wp.zip est un ensemble de tous les fichiers pour le système de fichiers virtuel dans Playground. Il y a un fichier de données pour chaque version WordPress disponible.
Le package à packages/playground/wordpress-builds est responsable de la construction de ces fichiers de données.
Modifiez le script de construction dans Dockerfile pour créer un ensemble personnalisé qui inclut des plugins préinstallés ou du contenu.
Pour reconstruire les builds WordPress après avoir personnalisé le Dockerfile, exécutez la commande suivante :
npm run rebuild:wordpress-builds
Pour reconstruire le site web afin d'inclure les builds WordPress personnalisés, suivez les instructions ici.
Installer des plugins
Voici un exemple d'installation de plugins pour l'ensemble de données.
Avant la section intitulée Strip whitespaces from PHP files.
# === Preinstall plugins ===
RUN cd wordpress/wp-content/mu-plugins && \
# Install plugins
for plugin_name in example-plugin-1 example-plugin-2; do \
curl -L https://downloads.wordpress.org/plugin/{$plugin_name}.latest-stable.zip -o {$plugin_name}.zip && \
unzip $plugin_file && \
rm $plugin_file && \
# Create entry file in mu-plugins root
echo "<?php require_once __DIR__.'/$plugin_name/$plugin_name.php';" > $plugin_name.php; \
done;
Vous pouvez télécharger des plugins depuis des URLs autres que le répertoire de plugins WordPress, ou utiliser Git pour les récupérer ailleurs.
Il est également possible de copier depuis un dossier local. Par exemple, avant RUN :
COPY ./build-assets/*.zip /root/
Ensuite, placez les fichiers zip des plugins dans build-assets. Dans ce cas, vous voudrez peut-être ajouter leurs chemins à .gitignore.
Importer du contenu
Voici un exemple d'importation de contenu.
# === Demo content ===
COPY ./build-assets/content.xml /root/
RUN cd wordpress ; \
echo "Importing content.."; \
../wp-cli.phar --allow-root import /root/content.xml --authors=create
Cela suppose que vous avez mis un fichier d'export WXR nommé content.xml dans le dossier build-assets. Vous pouvez ajouter son chemin à .gitignore.
Liste de vérification pour le déploiement en production
Avant la mise en production, vérifiez que votre Playground auto-hébergé répond à ces exigences :
Configuration du serveur
- Types MIME : Assurez-vous que les fichiers
.wasmsont servis avec le type de contenuapplication/wasm - En-têtes CORS : Si vous intégrez en cross-origin, configurez les en-têtes CORS appropriés
- Cache : Définissez des temps de cache longs pour WASM et les ressources statiques (ils sont versionnés)
- Compression : Activez gzip/brotli pour des transferts de fichiers plus rapides
- HTTPS : Requis pour les service workers et certaines fonctionnalités du navigateur
Optimisation des performances
- CDN : Servez les ressources statiques depuis un CDN pour une livraison mondiale plus rapide
- Plugins préinstallés : Empaquetez les plugins fréquemment utilisés dans votre build WordPress
- Blueprints minimaux : Gardez les installations de plugins à l'exécution au minimum
Dépannage
Problèmes courants et solutions
Playground ne charge pas ou affiche un écran blanc
Causes possibles :
- Le serveur ne sert pas les fichiers WASM avec le bon type MIME
- Le déploiement manque des fichiers requis
- Erreurs JavaScript dans la console du navigateur
Solutions :
- Vérifiez la console du navigateur pour les erreurs (F12 → onglet Console)
- Vérifiez que les fichiers
.wasmretournent le type de contenuapplication/wasm - Vérifiez que vous avez déployé tous les fichiers de construction
Chargement initial lent (30+ secondes)
Causes possibles :
- Installation de gros plugins à l'exécution
- Configuration CDN ou cache manquante
- Utilisateur sur une connexion réseau lente
Solutions :
- Préinstallez les plugins dans votre build WordPress au lieu de l'installation à l'exécution
- Configurez le CDN avec des en-têtes de cache appropriés
- Affichez des indicateurs de chargement pour définir les attentes des utilisateurs