WordPress Playground : WordPress entièrement exécuté dans le navigateur

 (developer.wordpress.org)
5 points par GN⁺ 2023-07-15 | 1 commentaires | Partager sur WhatsApp
  • WordPress Playground est un outil en ligne qui permet d’expérimenter et d’apprendre WordPress sans installation, et cette page ne sert pas de site produit mais de hub de documentation officiel
  • La documentation est divisée en Documentation, Blueprints, Developers et API Reference, qui présentent respectivement la prise en main, la configuration basée sur JSON, l’intégration dans le code et la référence API
  • Les utilisateurs peuvent lancer un nouveau site WordPress en moins de 5 minutes, tester des blocs, des thèmes et des extensions, ou vérifier une version spécifique de WordPress/PHP
  • Les développeurs peuvent choisir entre Query API, Blueprints API et JavaScript API selon leur objectif, et utiliser Playground comme environnement de développement local sans configuration
  • Fonctionnant dans le sandbox du navigateur et dépendant peu du backend et de l’authentification, l’outil convient bien aux démos rapides, aux prototypes et aux environnements d’expérimentation générés par l’IA

Hub de documentation WordPress Playground

  • Le site web officiel de Playground a été déplacé vers wordpress.org/playground/, et cette page sert de point d’entrée documentaire
  • WordPress Playground est un outil en ligne destiné à expérimenter et apprendre WordPress
  • La documentation est organisée en quatre hubs
    • Documentation : présentation de WordPress Playground, guide de démarrage et point d’entrée de la documentation
    • Blueprints : documentation des fichiers JSON servant à configurer une instance Playground
    • Developers : comment utiliser Playground dans le code
    • API Reference : référence complète des API exposées par WordPress Playground

Prise en main et flux de développement

  • Les nouveaux utilisateurs peuvent commencer rapidement avec le Quick Start Guide, qui permet de créer un nouveau site WordPress, de tester des blocs, des thèmes et des extensions, ou d’essayer une version spécifique de WordPress/PHP
  • Playground web instance traite de l’instance Playground proposée sur https://playground.wordpress.net/
  • About Playground permet de consulter la sécurité de Playground, ses usages et ses limitations actuelles
    • Les documents Build, Test et Launch montrent comment utiliser Playground dans un flux de développement, de validation et de lancement produit
  • Guides regroupe des documents pas à pas et des cas d’usage, tandis que Links and resources rassemble des ressources associées

Premières étapes et choix des API

Contribution et usage avec l’IA

  • WordPress Playground est un projet open source qui accepte des contributions en code, design, documentation et triage
  • Playground est conçu pour être utilisé avec des agents de codage IA et des outils basés sur l’IA
    • Il s’exécute entièrement côté client en WebAssembly, ne nécessite ni authentification ni backend, et ne laisse pas d’effets persistants en dehors du sandbox du navigateur
    • Using Playground with AI agents : dans Claude Code, Cursor, Gemini CLI, GitHub Copilot et autres, il est possible d’installer la compétence wp-playground pour lui confier l’exécution de commandes
    • AI-readable site index : résumé llms.txt lisible par machine des fonctionnalités, API et documents de Playground
    • AGENTS.md : instructions pour les agents de codage IA contribuant à cette base de code
  • WordPress Playground est un logiciel libre distribué sous les termes de la GNU General Public License version 2 ou ultérieure, et la licence complète est disponible dans LICENSE.md

À lire aussi

1 commentaires

 
GN⁺ 2023-07-15
Avis sur Hacker News

  • Testé sur Firefox d’une tablette Android d’entrée de gamme : la réponse n’est pas instantanée, mais ce n’est pas très différent de faire tourner la stack LAMP complète sur une instance cloud ou un VPS correct, ce qui est assez surprenant
    Il y a quand même tout l’interpréteur PHP, des milliers de lignes du code de WordPress, et même SQLite. Et malgré ça, c’est tout à fait utilisable, ce qui est impressionnant

    • J’ai toujours eu l’impression que les performances de WordPress variaient peu entre du matériel bas de gamme et haut de gamme. Au final, on dirait que WordPress lui-même est le goulot d’étranglement

  • La manière dont ils ont fait fonctionner ça est très moderne : PHP s’exécute comme binaire WebAssembly, MySQL est remplacé par SQLite via un plugin WordPress, et le serveur web est implémenté avec un Service Worker JavaScript

  • Dans la phrase disant que Playground prend en charge « une app de notes pour appareils mobiles, un environnement de tests automatisés, et même une démo WooCommerce qui tourne sur un site », les deux derniers points me paraissent totalement logiques, mais l’idée de créer une application mobile basée sur WordPress qui fait tourner PHP en WebAssembly dans le navigateur me donne le vertige

  • WordPress divise fortement les sensibilités sur HN. D’un côté, certains voient WordPress comme un outil multiplicateur de valeur qui permet aux non-développeurs de se concentrer sur leur métier sans se soucier du code ; de l’autre, certains le détestent à cause de son codebase désordonnée et s’acharnent à la place sur du code ultra-extensible et parfaitement formaté que presque personne n’utilisera en pratique
    WordPress fait tourner plus de la moitié du web. Ce n’est peut-être pas la meilleure technologie, ni la pire, mais la leçon que beaucoup de programmeurs continuent de manquer, c’est que personne ne se soucie de la façon dont la saucisse est fabriquée

    • Pour de petits sites utilitaires, comme celui d’un groupe de musique, je suis entièrement d’accord. Si ça tourne sur un hébergement bon marché et que le groupe se sépare avant que l’intégration Google Calendar ne casse, c’est largement suffisant
      Cela dit, comme je repousse en ce moment une migration d’un SSO tiers depuis un vieux site WordPress bancal vers un nouveau site WordPress bancal, je vais vider mon sac : il existe bel et bien un troisième groupe qui assure la maintenance pour que le premier groupe n’ait pas à se soucier de la façon dont la saucisse est fabriquée.
      Ça fait environ 14 ans que je fais ce genre de boulot ; j’héberge quelque 300 sites WordPress pour une université de taille moyenne, j’ai créé et maintenu des sites en .gov, et j’ai développé plusieurs blocs basés sur React dans trois grands modèles différents à cause de la direction prise par l’équipe Gutenberg. J’ai tout fait : déploiement de serveurs, correctifs CSS pour IE6, grattage d’un CMS inexistant pour migrer des milliers de pages et des dizaines de milliers d’images vers WordPress, écriture de commandes WP-CLI, et même du code pour propager de force des événements de calendrier dans un multisite.
      Quelqu’un doit bien savoir comment la saucisse est fabriquée, et moi je le sais. C’est aussi pour ça que je sais à quel point WordPress est un tas de déchets précaire. J’ai aussi travaillé sur des codebases réellement utiles, avec de meilleurs outils et des bases de données compréhensibles ; je sais que les autres plateformes ont aussi leurs problèmes, mais WordPress est vraiment mauvais.
      Donc je n’ai aucun scrupule à le critiquer. Je suis complètement en burn-out, au point d’avoir envie de tout arrêter, de vivre dans un camion et de faire de la musique. C’est une plateforme lamentable, et les gens paient rarement correctement pour le travail nécessaire à la maintenir en vie. Au final, beaucoup reviennent vers WordPress, cet immeuble en feu permanent, à cause des circonstances, et la haine collective envers cette plateforme est amplement justifiée
    • WordPress est excellent pour le premier groupe mentionné plus haut. Je le vois comme Excel, FileMaker ou Visual Basic : des outils qui démocratisent le logiciel et le rendent accessible à tous
      Évidemment, ce genre d’outils a des limites et des problèmes de qualité, et certains utilisateurs finissent forcément par s’y heurter. En soi, ce n’est pas grave. Le problème commence quand on attend de professionnels qu’ils intègrent ou construisent par-dessus. Les gens qui viennent voir un développeur web ont des attentes de qualité, des problèmes spécifiques et des exigences particulières, et l’héritage de WordPress place tellement de pièges et d’obstacles sur le chemin de ces objectifs que cela revient souvent à faire entrer une cheville carrée dans un trou rond. On pourrait dire la même chose de nombreuses plateformes CRM ou e-commerce
    • Je me considère comme un ingénieur logiciel sérieux, mais j’utilise WordPress pour le site web de mon entreprise
    • Au lieu de partir vers du « code parfaitement formaté et ultra-extensible », il s’agit peut-être plutôt d’arrêter de travailler sur une codebase imparfaite aujourd’hui pour démarrer un nouveau projet parfait
    • Cette fracture ressemble davantage à une différence entre la nouvelle génération de développeurs full-stack JavaScript et ceux qui ont appris avec PHP + MySQL

  • Lors du keynote State of the Word de décembre 2022, ils voulaient visiblement en parler assez largement : https://wordpress.tv/2023/01/04/matt-mullenweg-state-of-the-...
    En tant qu’ingénieur, voir que ça fonctionne réellement, puis réfléchir à toutes les couches qui doivent interagir pour y parvenir, était assez impressionnant. C’est amusant de voir que c’est devenu un sujet sur HN six mois plus tard.

    • Je m’intéresse beaucoup à l’idée d’exécuter dans le navigateur des applications jusqu’ici considérées comme « côté serveur », donc je trouve ça extrêmement intéressant. C’est d’autant plus fascinant que cela ressemble au premier cas d’usage réel de SQLite dans un produit, alors qu’auparavant je n’avais vu que des démos gadget.
      En regardant un peu le code, j’ai aussi réalisé que je ne connaissais pratiquement pas PHP à l’heure actuelle, et il ne semble pas que cela utilise l’approche « traditionnelle » SQLite-over-OPFS pour la persistance. En lisant davantage, il n’était même pas clair si un stockage persistant via Emscripten était encore possible. J’ai fini par trouver https://github.com/WordPress/wordpress-playground/issues/19, et c’est dommage, car cela semble vouloir dire que la persistance n’est pas encore possible pour WordPress dans le navigateur.
    • Bonne présentation. Pour les curieux, WordPress Playground est présenté à partir de 48:33.

  • Question purement par curiosité : si on met la base de données de côté pour l’instant, est-ce que cela veut dire qu’on pourrait faire tourner WordPress sur Cloudflare Worker ? https://developers.cloudflare.com/workers/runtime-apis/webas...

  • J’utilise souvent WordPress pour plusieurs sites presque statiques. C’est bien pour laisser des non-techniciens continuer à ajouter du contenu, et pour cet usage il n’existe pas vraiment d’alternative proche de WordPress.
    En revanche, il faut choisir soigneusement les plugins qu’on utilise, mettre en place un frontend Cloudflare adapté, et empêcher les utilisateurs de faire des choses qui paraissent simples en apparence mais sont dangereuses. J’ai l’impression qu’une grande partie de la haine envers WordPress vient de gens qui l’ont utilisé il y a très longtemps, qui avaient des besoins auxquels WordPress ne répondait pas, ou qui l’ont récupéré en héritage.

    • Pour moi, c’était un mélange du deuxième et du troisième cas, plus des projets où un headless CMS + du code sur mesure aurait été bien mieux, mais où le client insistait pour utiliser WordPress.
      Ce n’est pas vraiment la faute de WordPress, mais ça ne change pas le fait que rien que d’entendre son nom me fait encore un peu me crisper d’angoisse.

  • Ce Playground qui fait tourner PHP dans WASM est bien plus réactif que 95 % des sites web classiques.

    • Le plus génial ici, c’est que cela réduit énormément les allers-retours avec le serveur. Tous les appels à la base de données et toutes les requêtes d’assets se font côté client. Bien sûr, il faut accepter un temps de chargement de quelques secondes.
      WordPress est probablement la solution d’application multipage la plus utilisée, et là, cela la transforme pratiquement en application monopage. En plus, comme il n’y a pas besoin d’envoyer en permanence des requêtes d’API au serveur, les performances sont meilleures que celles de la plupart des applications monopage.
      Les parties en application monopage comme l’éditeur d’articles/pages et l’éditeur de site sont des applications React complexes, et dans cette démo elles paraissent plus rapides que dans mon environnement de développement local. Cela montre bien à quel point une application monopage peut devenir meilleure quand on supprime les allers-retours serveur. Pour référence, je travaille chez Automattic, et c’était vraiment passionnant de voir cette expérience se dérouler.

  • Il n’est pas nécessaire de rabaisser WordPress, mais il a une longue histoire et aussi beaucoup de problèmes. Ce serait bien d’avoir une alternative moderne auto-hébergée, utilisable sans génération de site statique ni hébergement complexe.

    • Quel que soit le concurrent, il doit surmonter un très rude problème de l’œuf et de la poule. WordPress a un plugin pour presque tout, avec en général la possibilité d’un support payant, donc il est difficile à éviter.
      La base de code n’est pas bonne, développer dessus est pénible, et ni les choix de conception ni la gestion de la boutique officielle n’empêchent vraiment la confusion et les risques côté base de données. Malgré cela, une proposition du type « très bien, il suffit de deux jours de configuration et de 80 dollars par mois en plugins/thèmes » est bien plus facile à vendre que « d’accord, mais il nous faudra au minimum deux mois de développement ».
      Même quand un travail de développement est nécessaire, il est facile de trouver des développeurs expérimentés sur WordPress, et si l’on ne veut pas recruter soi-même, il existe aussi beaucoup d’agences spécialisées WordPress. Un concurrent émergent ne bénéficie pas de tels effets d’échelle. Concevoir un système extensible avec une structure de plugins et de thèmes bien meilleure que celle de WordPress n’est pas une petite affaire, mais ce n’est pas impossible non plus et cela ne demande pas une équipe de génies. En revanche, sur le vrai marché, c’est probablement l’étape la plus facile pour déloger WordPress.
    • Il existe beaucoup de remplaçants parfaitement complets sur le plan fonctionnel, mais la vraie proposition de valeur de WordPress, c’est son écosystème de plugins, son vivier de développeurs et le soutien des utilisateurs.
      Tout le monde a déjà rencontré des clients qui ne veulent que WordPress et rien d’autre. Même après avoir déployé une solution neuve et propre, il arrive souvent que le client revienne à WordPress. J’ai vu de la valeur dans une approche hybride où des exigences complexes sont gérées par une application sur mesure construite avec un autre framework, tandis que le contenu est géré via une instance WordPress et des connecteurs.
    • Si WordPress a réussi jusqu’à aujourd’hui, c’est parce qu’il est resté globalement stable pendant des années alors que d’autres CMS cassaient sans cesse leurs API, ce qui a permis à un immense écosystème de plugins de se développer.
      De plus, l’API PHP de WordPress utilise très peu l’orienté objet et repose surtout sur des fonctions et des tableaux, ce qui permettait même à des personnes n’ayant que des bases très élémentaires en programmation de créer elles-mêmes des plugins ou des thèmes.
    • Le CMS avec lequel les développeurs ont envie de travailler n’est pas le même que le CMS que les entreprises ont envie d’utiliser. Pour entrer dans la seconde catégorie, il faut souvent faire de nombreux choix pragmatiques qui éloignent de la première.
      Les entreprises aiment ce qui a déjà duré longtemps, et par définition ce genre de choses est souvent dépassé.
    • C’est ici : https://github.com/Qbix/Platform

  • La technologie derrière cette démo est vraiment impressionnante. Ce serait bien de pouvoir voir les logs d’erreurs/avertissements PHP en temps réel, et j’aimerais particulièrement vérifier jusqu’où va le réalisme de ce simulateur, notamment avec la réécriture de la base de données SQLite.
    Tester des plugins ou des thèmes est aussi très simple. Il suffit d’ajouter &plugin=plugin-slug-from-dir, et si le slug correspond à celui du plugin dans l’URL WordPress.org, il est téléchargé automatiquement et ajouté au sandbox. Toute la documentation de l’API de requête qui configure le sandbox est ici : https://wordpress.github.io/wordpress-playground/query-api/
    Je suis certain qu’il doit y avoir un moyen d’ouvrir ou d’afficher le journal de débogage. Sans cela, ils n’auraient pas pu développer ça.