Aller au contenu principal

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 :

FacteurImpactOptimisation
Taille du pluginLes gros plugins (ex. WooCommerce) peuvent prendre 30-60 sec à installerPréinstallez les plugins dans votre build WordPress
Vitesse du réseauLes fichiers WASM font ~15-30 MoUtilisez un CDN avec des en-têtes de cache appropriés
NavigateurChrome/Edge sont les plus performants ; Safari utilise des mécanismes de secoursTestez sur différents navigateurs
AppareilLes appareils mobiles chargent plus lentement que les ordinateursAvertissez les utilisateurs mobiles des temps de chargement plus longs

Compatibilité des navigateurs

Playground fonctionne sur les navigateurs modernes, mais avec quelques différences :

NavigateurStatutNotes
Chrome/Edge✅ Meilleure performanceSupport complet de toutes les fonctionnalités
Firefox✅ BonPerformance fiable
Safari✅ BonDes 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 Playground
  • index.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 .htaccess du package remote

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.

Consultez le fichier source

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 .wasm sont servis avec le type de contenu application/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 :

  1. Vérifiez la console du navigateur pour les erreurs (F12 → onglet Console)
  2. Vérifiez que les fichiers .wasm retournent le type de contenu application/wasm
  3. 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 :

  1. Préinstallez les plugins dans votre build WordPress au lieu de l'installation à l'exécution
  2. Configurez le CDN avec des en-têtes de cache appropriés
  3. Affichez des indicateurs de chargement pour définir les attentes des utilisateurs