WordPress のプラグイン「Coverpeek」を wordpress.org で公開するまでの連載の番外編、その2です。
前回はストア用のバナーとアイコンを作った話でした。
バナーとアイコンを Figma MCP で作った話は↓こちらです。
今回はストアに載せるスクリーンショットを撮り直した話です。
プラグインの名前を変えたせいで、設定画面のスクリーンショットに旧名が写ってしまっていたんです…。
撮り直しの途中で、Claude のデスクトップアプリに内蔵されたブラウザで管理画面を開くと、画面が崩れてしまいました。
結論から書くと、崩れ方が「CSS のパスを間違えたときの見た目」にそっくりだったので、ブラウザ側の問題だと当たりをつけました。
原因は追い込まずに、普段使っている Chrome（Claude in Chrome）にすぐ切り替えています。
撮り直すことになった理由
wordpress.org のストアには、スクリーンショットを8枚載せています。
そのうち設定画面の4枚に、見出しとして旧名の「Live Thumbnail Generator」が写っていました。
撮り直すついでに、管理画面を英語表示にして撮ることにしました。
wordpress.org は世界中の人が見るので、英語の画面のほうが伝わりやすいと思ったからです。
管理者ユーザーの言語だけを一時的に英語に切り替えて、撮り終えたら元に戻しています。
内蔵ブラウザで管理画面が崩れた
撮影は Claude Code に任せていて、最初は Claude のアプリに内蔵されたブラウザで管理画面を開いてもらいました。
ところが、表示された画面がこんな感じでした。
ボタンなどに CSS がまったく当たっていません。
最初に疑ったのは、キャッシュとベーシック認証でした。
古いファイルが残っているか、認証で CSS の読み込みだけが弾かれているのでは、と思ったんです。
ただ、画面をよく見ると、仕事で CSS のパスを間違えたときによく見る崩れ方でした。
HTML はちゃんと表示されていて、見た目を整えるファイルだけが読み込まれていない。
普段の Chrome で同じ画面を開くと崩れていないので、サイト側ではなくブラウザ側の問題だろうと判断しました。
原因は ERR_BLOCKED_BY_CLIENT だった
Claude Code に通信の記録を見てもらうと、HTML 自体は正常に返っているのに、CSS と JavaScript がすべて同じエラーで失敗していました。
GET https://example.ddev.site/.../buttons.min.css?ver=7.1.2 [FAILED: net::ERR_BLOCKED_BY_CLIENT]
GET https://example.ddev.site/.../login.min.css?ver=7.1.2 [FAILED: net::ERR_BLOCKED_BY_CLIENT]
GET https://example.ddev.site/.../jquery.min.js?ver=3.7.1 [FAILED: net::ERR_BLOCKED_BY_CLIENT]ログイン画面だけでも、CSS が7本、JavaScript が13本、すべて読み込めていませんでした。
ERR_BLOCKED_BY_CLIENT は、ブラウザ（クライアント）側で読み込みが止められたときに出るエラーです。
普段の Chrome だと、広告ブロッカーなどの拡張機能が原因になることが多いようです。
内蔵ブラウザがなぜローカルの開発サイトの CSS や JavaScript を止めるのか、仕組みまでは追っていません。
キャッシュや認証は関係なく、ブラウザ側で止められていた。
わかったのはそこまでです。
見分け方として覚えておきたいのは、次の組み合わせです。
- HTML は表示されている（ステータスは 200）
- CSS や JavaScript だけが、一斉に失敗している
- 失敗の理由が
ERR_BLOCKED_BY_CLIENT
この3つがそろっていたら、サーバーの設定やファイルのパスを疑う前に、ブラウザ側を疑ってよさそうです。
原因を追わずに切り替えた判断
切り替えは即決でした。
今回の目的はスクリーンショットを撮ることで、内蔵ブラウザを直すことではありません。
普段の Chrome なら崩れないことはわかっているので、そちらで撮れば済みます。
そこで、Claude から普段の Chrome を操作できる「Claude in Chrome」という拡張機能に切り替えました。
ログイン済みの Chrome をそのまま使えるので、管理画面も崩れずに表示されました。
原因を突き止めるのも大事ですが、目的に関係ないところで時間を使いすぎないようにしたかったので。
撮影で工夫したこと
Chrome に切り替えたあとも、きれいに撮るまでには少し手間がかかりました。
細かい手順は省いて、やったことだけ紹介します。
ウィンドウだけを撮る
Mac の screencapture コマンドで、Chrome のウィンドウだけを撮りました。
ウィンドウを指定して撮れるのですが、Chrome が裏に隠れていると次のエラーで撮れませんでした。
could not create image from windowChrome を前面に出したら、撮れました。
目印の線で位置を合わせる
ウィンドウ全体を撮ると、タブやアドレスバーまで写ります。
ページの部分だけを切り出すために、ページに一時的にマゼンタ（#ff00ff）の線を出してから撮り、画像の中でその線の位置を探して切り出す位置を決めました。
マゼンタは、ページの中ではまず使われない色のなので、目印にちょうどいいんです。
長いページは2回に分けてつなぐ
画面に収まらない長さのタブは、上と下をスクロール位置を変えて2回撮り、画像をつなぎ合わせました。
操作中の表示を消す
Claude in Chrome が操作しているあいだは、画面のふちに色の付いた枠や、専用のカーソルが表示されます。
これが写り込むので、撮影のときだけ CSS で非表示にしました。
色をそろえる
ディスプレイの色設定が影響して、撮った画像の色が少しずれることがありました。
最後に sRGB に変換して色をそろえています。
英語で撮ったら、折り返しの不具合が見つかった
英語で撮ることには、思わぬおまけもありました。
最初に英語でスクリーンショットを撮ろうとしたときのことです。
英語のタイトルでサムネイルを作ってみると、「WordPress」が「WordPres」と「s」に分かれていました。
単語の途中で改行されていたんです。
原因は、タイトルを折り返す処理が、常に1文字ずつ判定していたことでした。
日本語なら1文字ずつ折り返しても自然ですが、英語だと単語が途中で切れてしまいます。
英数字が続く部分は1つの単語として扱い、単語の切れ目で折り返すように直しました。
日本語のタイトルの折り返し位置が変わっていないことも確かめています。
実は、英語の表示に気になるところがあることには気づいていました。
ただ、まずは日本語のユーザーを優先していたので、後回しにしていたんです。
英語のスクリーンショットを撮る段階になって、さすがに後回しにはできなくなりました…！
実際のユーザーにも影響する不具合なので、スクリーンショットの準備より先に直しています。
結果的に、英語でスクリーンショットを撮ることが、英語圏のユーザーの目で見た動作確認にもなりました。
まとめ
今回のことで、判断の基準として残しておきたいのは次の2つです。
- 画面が崩れたら、見た目から「サーバー側か、ブラウザ側か」を先に切り分ける。HTML は出ているのに CSS や JavaScript だけが一斉に失敗しているなら、ブラウザ側を疑う
- 目的に関係しない原因の究明は後回しにする。今回は撮影が目的だったので、内蔵ブラウザの原因は追わずに、確実に動く普段の Chrome に切り替えた
崩れた画面を見て「CSS のパスを間違えたときの感じだ」と気づけたのは、普段の制作の経験があったからだと思います。
見慣れた症状に置き換えて考えると、原因の当たりをつけるのが早くなりますね。
Coverpeek はこちらから入れられます。
- 紹介ページ: Coverpeek｜rcwas
- wordpress.org: Coverpeek – Auto Thumbnails with Live Preview
