「その不具合、こちらの環境では起きないんです」
WordPressの不具合を調べていると、よくこうなります。PHPのバージョン、入っているプラグイン、言語の設定。どこか1つ違うだけで、同じ現象は再現しません。
WordPress Playgroundの「Blueprint(ブループリント)」を使うと、検証に使う環境をJSONで書いておき、URL1つで相手に渡せます。開いた人のブラウザで、同じWordPressが20秒ほどで立ち上がります。
Blueprintとは
Blueprintは、WordPress Playgroundを開いたときに、どんなサイトを用意するかを書いた設定ファイルです。PHPとWordPressのバージョン、言語、入れておくプラグインやテーマ、サイトの設定などを、JSONという形式でまとめて書きます。
Playgroundは、URLの末尾にパラメーターを付けるだけでも、PHPのバージョンやプラグインを指定できます。Playgroundの基本的な使い方とURLパラメーターは、こちらの記事で紹介しています。
テーマやプラグインを試したいけれど、本番のサイトには入れたくない。PHPのバージョンを上げる前に、動くかどうか確かめておきたい。そんなときに便利なのが、WordPress公式の「WordPress Playground」です。 WordPress Playgroundを使えば、サーバーを借りた...
URLパラメーターとBlueprintの違いは、次のとおりです。
| URLパラメーター | Blueprint | |
| バージョン・言語 | 指定できる | 指定できる |
| プラグイン・テーマ | WordPress.orgにあるものだけ | WordPress.orgのほか、URLで公開したzipも入れられる |
| サイトの設定 | できない | サイト名、タイムゾーン、wp-config.phpの定数なども変えられる |
| 記事などのデータ | できない | WordPressのエクスポートファイルを読み込める |
| 共有のしかた | URLをそのまま渡す | URLを渡す、またはJSONファイルを渡す |
バージョンとプラグインを決めるだけならURLパラメーターで足ります。サイトの設定や記事のデータまでそろえたいときに、Blueprintを使います。
Blueprintで検証環境を作る手順
1. Blueprintを書く
例として、次のような環境を用意するBlueprintを書きました。
- PHP 8.3、WordPressは最新版
- 管理画面を日本語に、サイト名を「検証サイト」、タイムゾーンを東京に
- プラグイン「YOMERU」と「Query Monitor」を入れて有効化
- ログインした状態で、プラグインの一覧画面を開く
{
"landingPage": "/wp-admin/plugins.php",
"preferredVersions": {
"php": "8.3",
"wp": "latest"
},
"login": true,
"steps": [
{
"step": "setSiteLanguage",
"language": "ja"
},
{
"step": "setSiteOptions",
"options": {
"blogname": "検証サイト",
"timezone_string": "Asia/Tokyo"
}
},
{
"step": "installPlugin",
"pluginData": {
"resource": "wordpress.org/plugins",
"slug": "yomeru-paywall-membership"
}
},
{
"step": "installPlugin",
"pluginData": {
"resource": "wordpress.org/plugins",
"slug": "query-monitor"
}
}
]
}
「landingPage」は最初に開く画面、「preferredVersions」はPHPとWordPressのバージョンです。「login」を true にすると、管理者としてログインした状態で始まります。
「steps」には、上から順に実行する作業を並べます。プラグインの「slug」には、WordPress.orgのプラグインページのURLにある名前を入れます。YOMERUなら https://ja.wordpress.org/plugins/yomeru-paywall-membership/ の「yomeru-paywall-membership」の部分です。
2. URLに付けて開く
書いたJSONを、PlaygroundのURLの「#」のあとに付けて開きます。
https://playground.wordpress.net/#{"landingPage":"/wp-admin/plugins.php", ... }
実際に開くと、20秒ほどで次の画面になりました。サイト名が「検証サイト」になり(①)、2つのプラグインが有効になっています(②)。管理画面も日本語です。

JSONをファイルにしてWeb上に置いた場合は、「blueprint-url」というパラメーターでそのファイルを指定することもできます。
https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json
3. Playgroundの画面で直す
画面下の操作バーにある「Blueprint」(上の画像の③)を押すと、いま動いているサイトのBlueprintが開きます。

ここでJSONを書き換えて、「Run in a new Playground」(①)を押すと、書き換えた内容で新しいサイトが作られます。エラーがあれば画面に表示されるので、URLを作る前の確認に使えます。
4. 共有用のURLをコピーする
できあがったら、「Export」→「Copy Blueprint URL」(①)を押します。Blueprintの入ったURLがコピーされるので、そのまま相手に送ります。

コピーしたURLでは、JSONが英数字の文字列に変換されていました。今回の例で、URLは全部で966文字です。長いURLですが、相手はクリックするだけで同じサイトを開けます。「Download Zip」を選ぶと、Blueprintをファイルとして保存できます。
よく使うステップ
「steps」に書ける作業には、ほかにも次のようなものがあります。
| ステップ | できること |
| installTheme | テーマを入れる。有効化もできる |
| importWxr | WordPressのエクスポートファイル(XML)を読み込んで、記事や固定ページを入れる |
| defineWpConfigConsts | wp-config.php に定数を書く(WP_DEBUG を true にするなど) |
| setSiteOptions | サイト名、パーマリンクなどの設定を変える |
| wp-cli | WP-CLIのコマンドを実行する(ユーザーの作成、記事の作成など) |
| runPHP | PHPのコードを実行する |
不具合の調査で使うなら、defineWpConfigConsts で WP_DEBUG を有効にしておくと、エラーの内容がすぐに分かります。
参考:Blueprint Steps(WordPress Developer Resources)
こんな場面で使える
不具合の報告に、再現できる環境を添える
プラグインやテーマの作者に不具合を伝えるとき、文章だけでは環境の違いが伝わりません。Blueprintで再現できる環境を作り、URLを添えて送れば、相手は同じ画面をすぐに確かめられます。
プラグインの使い方を見せる
プラグインを入れて設定まで済ませた状態を、URL1つで見せられます。サーバーを用意しなくてもデモを配れるので、使い方の説明や研修にも向いています。
毎回同じ検証環境から始める
自分用の検証環境も、Blueprintにしておけば何度でも同じ状態から作り直せます。試しているうちに設定がぐちゃぐちゃになっても、URLを開き直すだけです。
Blueprintを使うときの注意点
有料のテーマやプラグインのファイルは公開しない
Blueprintには、URLで公開したzipファイルからテーマやプラグインを入れる書き方もあります。ただ、そのURLを知っている人はだれでもzipを取り出せます。有料のテーマやプラグインのzipを、Blueprintのために公開の場所へ置くことはやめましょう。TCDのテーマも同じです。
作ったサイトはブラウザの中にしかない
Playgroundのサイトは、開いた人のブラウザの中で動いています。相手がURLを開いて作ったサイトは相手のブラウザに、自分のサイトは自分のブラウザにあり、データは共有されません。共有されるのは、Blueprintという「作り方」だけです。
まとめ
Blueprintで共有するのは、できあがったサイトではなく、サイトの作り方です。
だから、相手の環境がどうなっていても、URLを開けば同じ状態から始められます。ふだん使っている検証環境を1つBlueprintにしておくと、次に不具合を調べるとき、相手に送る準備がもうできています。
WordPressテーマ集











コメント