WordPress Playground: ブラウザで完全に実行されるWordPress

 (developer.wordpress.org)
5 ポイント 投稿者 GN⁺ 2023-07-15 | 1件のコメント | WhatsAppで共有
  • WordPress Playground は、インストール不要でWordPressを試したり学んだりできるオンラインツールであり、このページは製品サイトではなく公式の ドキュメントハブ の役割を果たす
  • ドキュメントは Documentation、Blueprints、Developers、API Reference に分かれており、開始方法、JSON ベースの設定、コード連携、API リファレンスをそれぞれ案内している
  • ユーザーは5分以内に新しいWordPressサイトを立ち上げ、ブロック・テーマ・プラグインを試したり、特定の WordPress/PHP バージョン をテストしたりできる
  • 開発者は Query API、Blueprints API、JavaScript API の中から目的に合った方法を選び、Playgroundをゼロ設定のローカル開発環境として活用できる
  • ブラウザのサンドボックス内で動作し、バックエンドや認証への依存が少ないため、高速なデモ・プロトタイプ・AI生成の実験環境に適している

WordPress Playground ドキュメントハブ

  • 公式Playgroundウェブサイトは wordpress.org/playground/ に移動しており、このページは ドキュメントへの入口 として使われている
  • WordPress Playground は、WordPressを実験し学習するための オンラインツール である
  • ドキュメントは4つのハブで構成されている
    • Documentation: WordPress Playground の紹介、スタートガイド、ドキュメントへの入口
    • Blueprints: Playgroundインスタンスを設定する JSON ファイル のドキュメント
    • Developers: コードからPlaygroundを活用する方法
    • API Reference: WordPress Playground が公開しているAPIの完全リファレンス

開始方法と開発フロー

  • 初めて使う人は Quick Start Guide から、新しいWordPressサイトの作成、ブロック・テーマ・プラグインのテスト、特定のWordPress/PHPバージョンのテストをすぐに始められる
  • Playground web instance では、https://playground.wordpress.net/ で提供されるPlaygroundインスタンスを扱っている
  • About Playground では、Playgroundの安全性、活用方法、現在の制限事項を確認できる
    • Build、Test、Launch の文書を通じて、製品の開発・検証・公開にPlaygroundを活用する流れを見ていける
  • Guides は段階的な案内と活用法をまとめたドキュメントであり、Links and resources は関連資料の一覧である

最初のステップとAPIの選択

貢献とAI活用

  • WordPress Playground はオープンソースプロジェクトであり、コード、デザイン、ドキュメント、トリアージへの貢献を受け付けている
  • Playground は AIコーディングエージェント やAIベースのツールと一緒に使うことを想定して設計されている
    • WebAssembly 上で完全にクライアント側実行され、認証やバックエンドを必要とせず、ブラウザのサンドボックス外に永続的な副作用を残さない
    • Using Playground with AI agents: Claude Code、Cursor、Gemini CLI、GitHub Copilot などで wp-playground スキルをインストールしてコマンド実行を任せられる
    • AI-readable site index: Playgroundの機能、API、ドキュメントの機械可読な llms.txt 要約
    • AGENTS.md: このコードベースに貢献するAIコーディングエージェント向けのガイドライン
  • WordPress Playground は GNU General Public License version 2 またはそれ以降の条件による 自由ソフトウェア であり、完全なライセンスは LICENSE.md にある

関連記事

1件のコメント

 
GN⁺ 2023-07-15
Hacker Newsのコメント

  • 廉価なAndroidタブレットのFirefoxで試してみたところ、応答は瞬時というほどではないが、適当なクラウドインスタンスやVPSで LAMPスタック一式 を動かすのと大差なく、かなり驚いた
    ここにはPHPインタープリタ全体、数千行に及ぶWordPressコードベース、SQLiteまで載っている。それでも十分実用になるのはすごい

    • WordPressの性能は低スペックでも高スペックでもあまり変わらないと常々感じていた。結局 WordPress自体がボトルネック なのだと思う

  • これを動かしている仕組みがとてもモダンだ。PHPは WebAssemblyバイナリ として実行され、MySQLはWordPressプラグインによってSQLiteに置き換えられ、WebサーバーはJavaScriptの Service Worker で実装されている

  • 「モバイル端末向けノートアプリ、自動化テスト環境、サイト上で動くWooCommerceデモまでPlaygroundがサポートする」という文言では、後ろの2つは完全に納得できるが、ブラウザ内で WebAssemblyでPHPを動かすWordPressベースのモバイルアプリ を作るという発想には頭がくらくらする

  • WordPressはHNで好みが大きく分かれる。一方では、WordPressを非開発者がコーディングを気にせず本業に集中できる 価値増幅ツール と見る人がいて、他方では、散らかったコードベースを嫌いながら、実際にはほとんど誰も使わないような完璧に整形された超拡張可能コードに執着する人がいる
    WordPressはウェブの半分以上を動かしている。最高の技術ではないかもしれないし最悪の技術かもしれないが、多くのプログラマが見落とし続けている教訓は、ソーセージがどう作られているかなんて誰も気にしない ということだ

    • バンドのような小さなユーティリティサイトを作るときは、その意見に全面的に同意する。安いホスティングにとりあえず置いておいて、Google Calendar連携が壊れる前にバンドが解散してくれれば十分、という感じだ
      ただ、古くてめちゃくちゃなWordPressサイトのサードパーティSSOを、新しくてめちゃくちゃなWordPressサイトへ移す作業を先延ばしにしている身として少し吐き出すと、最初のグループがソーセージの作り方を気にしなくて済むよう保守する 第三のグループ が実在する。
      14年ほどこういう仕事をしてきて、中規模大学のWordPressサイトを300件ほどホスティングし、.govサイトも作って保守し、Gutenbergチームの方向性のせいで大きく異なる3つのパターンにまたがるReactベースのブロックもいくつも作った。サーバー配備からIE6向けCSS修正、CMSのない環境から数千ページと数万枚の画像をWordPressに移行する作業、WP-CLIコマンドの作成、マルチサイト間でカレンダーイベントを無理やり伝播させるコードまで、ひと通りやってきた。
      誰かはソーセージの作り方を知らなければならないし、私はそれを知っている。だからWordPressがどれほど危ういゴミの山かも分かっている。より良いツールと理解可能なデータベースを持つ、本当に有用なコードベースも扱ってきたし、他のプラットフォームにも問題があることは分かっているが、WordPressは本当にひどい。
      だから遠慮なくけなせる。完全に燃え尽きていて、もう辞めてトラックで暮らしながら音楽でもやろうかと思うほどだ。ひどいプラットフォームだし、それを回し続ける仕事に人は大して金も払わない。結局、事情に押されて燃えている建物のようなWordPressに戻ってくる人たちがいて、このプラットフォームに対する集団的な嫌悪には十分な根拠がある
    • WordPressは先に挙げた第一のグループには素晴らしい。Excel、FileMaker、Visual Basicのように、ソフトウェアを民主化 して誰でも使えるようにした道具に近いと見ている
      もちろん、こうした道具には限界や品質上の問題があり、一部のユーザーはいずれそれに直面する。それ自体は構わない。問題は、専門家にその上で統合や構築をさせようと期待するときに起きる。ウェブ開発者のところに来る人たちは品質への期待、固有の課題、要件を持っているが、WordPressというレガシーはその目標の前にあまりにも多くの罠や障害物を置くため、四角い釘を丸い穴に押し込むような話になりがちだ。よくあるCRMやeコマースプラットフォームにも同じことが言える
    • 自分は真面目なソフトウェアエンジニアだと思っているが、会社のウェブサイトには WordPress を使っている
    • 「完璧に整形され超拡張可能なコード」に去っていくというより、今ある不完全なコードベースでの作業をやめて、完璧になるはずの新規プロジェクトを始める、という話かもしれない
    • この分断は、新世代の フルスタックJavaScript開発者 と、PHP + MySQLで学んだ人たちの違いにより近いように見える

  • 2022年12月のState of the Wordキーノートで、これをかなり大きく取り上げようとしていた: https://wordpress.tv/2023/01/04/matt-mullenweg-state-of-the-...
    エンジニアとして実際に動いているのを見て、それを実現するために相互作用しなければならないすべてのレイヤーを考えると、かなり衝撃的だった。6か月後にHNで話題になっているのを見ると面白い

    • これまで「サーバーサイド」アプリケーションと見なされていたものをブラウザ内で動かすことに関心があるので、とても興味深い。特に SQLiteを実際の製品で動かす最初の事例のように見えてさらに興味深く、以前はおもちゃのデモしか見たことがなかった
      コードを少しのぞいてみると、現時点ではPHPをほとんど知らないことにも気づいたし、これは永続性のために「伝統的な」SQLite-over-OPFSアプローチを使っているわけではないようだ。さらに読んでみると、Emscripten経由の永続ストレージがまだ可能なのかもはっきりしない。結局 https://github.com/WordPress/wordpress-playground/issues/19 を見つけたのだが、ブラウザ内のWordPressではまだ 永続性 が不可能だという意味のようで残念
    • 発表は良かった。気になる人は 48:33 からWordPress Playgroundが紹介される

  • 純粋に興味本位なのだけれど、データベースはいったん脇に置いて考えると、WordPressを Cloudflare Worker で動かせるという意味だろうか？ https://developers.cloudflare.com/workers/runtime-apis/webas...

  • ほぼ静的な複数のサイトでWordPressをよく使っている。非技術者が継続的にコンテンツを追加できるようにしておくのに向いていて、この目的ではWordPressに近い代替はない
    ただし使うプラグインは慎重に選び、適切なCloudflareフロントエンドを設定し、ユーザーが見た目には単純でも危険なことをできないように防ぐ必要がある。WordPress嫌いのかなりの部分は、かなり昔に使ったことがあるか、WordPressでは満たせない要件があったか、レガシーとして引き継いだ場合 から来ている気がする

    • 自分にとっては2つ目と3つ目、そして ヘッドレスCMS + カスタムコード のほうがずっと良かったはずのプロジェクトでクライアントがWordPressにこだわったことが合わさってそうなった
      実際にはWordPressのせいではないのだが、名前を聞くだけで少し恐怖を感じて身構えてしまうのは変わらない

  • WASMでPHPを動かすこのPlaygroundは、一般的なウェブサイトの95%よりはるかに 反応が速い

    • ここでいちばんすごいのは、サーバー往復をものすごく減らしていることだ。すべてのデータベース呼び出しとアセット要求がクライアント側で行われる。もちろん数秒の読み込み時間は受け入れる必要がある
      WordPressはおそらく最も広く使われている マルチページアプリケーション のソリューションだが、これは事実上それをシングルページアプリケーションに変えてしまう。しかもサーバーにAPIリクエストを送り続ける必要がないので、大半のシングルページアプリケーションより性能も良い。
      投稿／ページエディタやサイトエディタのようなシングルページアプリケーション部分は複雑なReactアプリだが、このデモではローカル開発環境よりもずっときびきびして感じられる。サーバー往復をなくすとシングルページアプリケーションがどれほど良くなりうるかをよく示している。ちなみにAutomatticで働いていて、この実験を見守るのは本当に素晴らしかった。

  • WordPressをけなす必要はないが、歴史も長く問題も多い。静的サイト生成や複雑なホスティングなしで使える、現代的なセルフホスティング代替があればよいと思う

    • どんな競合であっても、非常に厄介な鶏と卵の問題を乗り越えなければならない。WordPressにはほぼ何でもしてくれるプラグインがあり、たいてい有償サポートも受けられるので避けにくい。
      コードベースは良くなく、その上で開発するのはつらく、設計方法や公式ストアの運営もデータベース周りの混乱やリスクを防いではくれない。それでも、2日でセットアップしてプラグイン/テーマに月80ドル使う提案は、「承知しました、まず最低2か月の開発期間が必要です」よりはるかに売りやすい。
      開発作業が必要でもWordPress開発経験者は見つけやすく、直接採用したくなければWordPress専門のエージェンシーも多い。新しく台頭する競合には、こうした規模の優位性がない。プラグインとテーマの仕組みを備えた拡張可能なシステムをWordPressよりはるかに良く設計することは小さな仕事ではないが、不可能でもなく天才チームが必要なわけでもない。ただ、実際の市場でWordPressを押しのける道のりでは、それがいちばん簡単な段階だ
    • 機能的に完全な代替はいくつもあるが、WordPressの実際の価値提案はプラグインのエコシステム、開発者層、ユーザー支持基盤にある。
      WordPressだけを望み、ほかは嫌だというクライアントには誰もが出会ったことがあるはずだ。すっきりした新しいソリューションを導入しても、クライアントが再びWordPressに戻ることも多い。複雑な要件は別のフレームワークで作ったカスタムアプリが処理し、コンテンツはWordPressインスタンスとコネクタで扱うハイブリッドなアプローチには価値があると感じた
    • WordPressが今日成功している理由は、長年にわたり他のCMSがAPIを壊し続ける中で、WordPressはおおむね安定性を保ち、そのおかげで巨大なプラグインのエコシステムが育ったからだ。
      またWordPressのPHP APIはオブジェクト指向をほとんど使わず、ほぼ関数と配列なので、ごく基本的なプログラミングしか知らない人でもプラグインやテーマを自作できた
    • 開発者が一緒に仕事をしたいCMSと、企業が使いたいCMSは別物だ。後者に入っていくには、前者から遠ざかるような実用的な選択を数多くしなければならない。
      企業は長く生き残ってきたものを好み、そういうものは定義上たいてい古い
    • ここにある: https://github.com/Qbix/Platform

  • このデモの背後にある技術は本当にすばらしい。リアルタイムのPHPエラー/警告ログが見られるとよいし、特にSQLiteデータベースの書き換えまで含めて、このシミュレーターがどれほど完全か確かめてみたい。
    プラグインやテーマのテストも非常に簡単だ。&plugin=plugin-slug-from-dirを追加するだけでよく、slugがWordPress.org URLのプラグインslugと一致すれば自動でダウンロードされてサンドボックスに追加される。サンドボックスを構成する完全なクエリAPIのドキュメントはここにある: https://wordpress.github.io/wordpress-playground/query-api/
    デバッグログを開いたり表示したりする方法は、きっとあるはずだと思う。そういうものがなければ、これを開発できたはずがないのだから