前回、デザインの検討が終わったところで、次は実装です。ここからが大変でした。
先に白状しておくと、わたしはPHPもCSSも、まともに触ったことがありません。「トリミング」は画像処理の言葉として聞いたことがある程度で、それ以外の用語はほぼ何も知らない状態でした。それでゼロから自作テーマを作ろうと決めたわけですから、今思えばだいぶ無謀でした。
じゃあどうやって進めたかというと、方法はシンプルで、「なんかここ、おかしくない？」と思ったところをスクリーンショットで送って、Claudeに原因を探ってもらう、というやり方です。自分でコードを読んで原因を特定する、ということは基本的にできないので、見た目の違和感だけを頼りに指摘して、直してもらって、また確認する。このキャッチボールをひたすら繰り返しながら形にしていきました。
そしてこのやり方だと、当然ながら「事故」が起きます。しかも一度直したはずのところが、別の場所を直した拍子にまた崩れる、みたいなことが何度もありました。今回はその事故の数々を、順番に振り返っていきます。
事故①：同じクラス名「.phone」が、ページごとに違う意味で使われていた
だ
トップページとカテゴリーページ、記事ページ、それぞれ見た目はできているのに、実際にサイトに組み込んだらデスクトップの横幅が全部同じになっちゃったんだけど。しかも記事ページの幅に統一されている。
C
これは
.phoneというクラス名が原因ですね。CSSというのは「このクラス名がついた部分は、こういう見た目にする」というルールの集まりなんですが、.phoneという同じ名前を、トップページ用のファイルでも、記事ページ用のファイルでも、それぞれ別の意味で使っていたんです。3つのファイルを1つに合体させたことで、あとから読み込んだ記事ページ側の指定が、他の2つを丸ごと上書きしてしまいました。だ
同姓同名の生徒が3人いて、後から転入してきた子の情報で他の子の名簿まで書き換わっちゃった、みたいな話？
C
まさにそのイメージです。名前（クラス名）だけで判断する仕組みだと、こういう事故が起きます。対策としては、生徒それぞれに「トップページ組」「記事ページ組」という所属クラスを追加して、指定するときは必ず「トップページ組の
.phone」というふうに、所属も込みで指定するようにしました。だ
それで直った、と。
C
はい。ただこの手の事故は「直したと思ったら別の場所でまた起きる」ことがあるので、新しいページを増やすたびに、所属クラスをつけ忘れていないか確認する必要があります。
事故②：サムネイルの縦横比が合っておらず、画像の端が切れていた
だ
新着記事のカードに使っているサムネイル、なんか横長のバナー画像だと両端が切れて見えるんだけど。
C
これはカードの写真枠の「縦横比」が原因ですね。今のカードは4:3という比率、つまり横幅に対して高さが少し詰まった、ほぼ正方形に近い形で作ってあります。世界史のアイキャッチみたいに横長のバナー画像をこの枠にはめ込もうとすると、はみ出した部分が問答無用で切り取られてしまうんです。
だ
額縁のサイズに合わせて、写真の端を切って無理やり入れている感じか。
C
その通りです。まず額縁自体をもう少し横長の比率に変えて、切れ落ちる範囲を減らしました。ただ、直したはずなのに関連記事のところではまだ切れる、という報告をもらって調べたら、もう一つ問題がありました。
だ
え、まだあったの。
C
関連記事用に使っていた
.t-thumbというクラス名が、実は別の場所（新着記事の一覧）でも同じ名前で使われていて、事故①と同じ「名前の衝突」がここでも起きていました。関連記事の方を直したつもりが、同じ名前を使っている新着記事の見た目まで一緒に変わってしまっていたんです。だ
また同じパターンか。
C
はい。ここでも「どのページの、どの部分の写真枠か」をちゃんと区別できる名前に直して、ようやく両方とも正しい比率で表示されるようになりました。
事故③：画像のトリミング表示設定が原因で、文字入りアイキャッチの文字が切れていた
だ
だらず世界史のアイキャッチ、サムネイル表示にすると文字が切れて読めなくなるんだけど。
C
これは表示方法の設定が原因です。カードに写真を載せるとき、枠の形に合わせて写真の一部を切り取って表示する「トリミング表示」という設定にしていました。写真自体にはみ出す部分があっても気づきにくいので便利な設定なんですが、だらず世界史のアイキャッチみたいに、写真の中に文字（タイトルの一部）が焼き込んであるものだと話が変わってきます。切り取られた部分にちょうど文字がかかっていると、そこだけ読めなくなってしまうんです。
だ
なるほど、風景写真なら多少切れても気づかないけど、文字入りだと一発でバレるってことか。
C
そうです。なので「トリミングして枠いっぱいに見せる」設定から、「写真の全体を、切らずにそのまま縮小して収める」設定に変更しました。ただ、これだけでは直りませんでした。
だ
まだ何かあったの。
C
はい。WordPress側の画像登録の設定で、もともと「決まった比率にあわせて画像を切り抜いてから保存する」という処理を入れていました。表示側だけ「切らずに収める」に変えても、保存された時点ですでに端が切れた画像になっていたので、直っていなかったんです。表示設定と、保存時の設定の両方を「切らない」方向にそろえて、ようやく文字が全部見える形になりました。
だ
一箇所直したつもりが、実は入り口と出口の両方で同じ問題が起きていたんだな。
C
まさにそういう構造でした。
事故④：固定ページ用のテンプレートが存在せず、記事一覧の表示が誤って適用されていた
だ
お問い合わせページを見たら、タイトルがリンクになっていたり、本文が途中で切れて「続きを読む」表示になっていたりするんだけど、これ普通の固定ページだよね。
C
これは、固定ページ専用の表示テンプレートがそもそも存在していなかったことが原因です。WordPressは「このタイプのページには、このテンプレートを使う」という対応関係を持っているんですが、固定ページ用のファイルを作り忘れていました。対応するテンプレートが見つからない場合、WordPressは仕方なく「記事一覧用」のテンプレートを代わりに使ってしまいます。
だ
一覧用のテンプレートって、本来は記事のタイトルと冒頭だけをずらっと並べるためのものだよね。
C
その通りです。だから、お問い合わせページのような1ページ完結の内容に対しても、「タイトルはリンクにする」「本文は冒頭だけ表示して省略する」という一覧向けのルールがそのまま適用されてしまっていました。固定ページ専用のテンプレートを新しく作って、この対応関係をきちんと結び直したことで解消しました。
だ
見た目の小さい違和感かと思ったら、そもそもファイルが1個丸ごと抜けていたのか。
C
はい。派手なバグではないんですが、テンプレートの対応関係という、実装の土台に関わる話だったので、他の3つと同じくらい大事な事故だったと思っています。
小ネタ集
だ
直したはずのCSSが、更新してもブラウザに反映されないことがよくあったよね。
C
あれはキャッシュの問題でした。ブラウザやサーバーは、一度読み込んだCSSファイルを「同じファイル名なら中身も同じだろう」と判断して、手元に保存したものを使い回します。ファイルの中身を書き換えても、名前が変わっていないので、古い方をそのまま表示し続けてしまうんです。対策として、ファイルを読み込むタイミングで、そのファイルが最後に更新された時刻を名前の末尾にくっつけるようにしました。中身を変えるたびに時刻も変わるので、「これは新しいファイルだ」とブラウザに気づかせることができます。
だ
もう一つ、ルビ（ふりがな）を振ったら本文からルビだけ消えていた事故があったよね。
C
WordPressには、投稿された内容から危険なコードを取り除く「掃除」の仕組みが標準で入っています。この掃除の対象リストに、ルビ用のタグが元々含まれていなかったので、保存するたびに「知らないタグだから」という理由でルビだけ削除されていました。ルビ用のタグを掃除の対象外リストに追加してもらって、ようやく残るようになりました。
だ
検索ボックスも、実はしれっと後から実装した機能だったよね。ヘッダーに置いたはいいものの、正直どういう理屈で検索できているのか、あんまりちゃんと分かっていない。
C
そうですね。入力されたキーワードでWordPress標準の検索の仕組みを呼び出しているだけなので、特別なことはしていません。ここは今後の宿題ということで。
AIとの協働で気づいたこと
だ
一連の事故を振り返ってみて、進め方として良かったところと、微妙だったところってどう思う？
C
良かったのは、コードが読めない前提を隠さずに、見た目の違和感だけをそのまま伝えてもらえたことです。「なんか変」という感覚は、実は原因を探る手がかりとしてかなり優秀でした。逆に苦労したのは、同じ名前のクラスがあちこちで使い回されている、というような「見た目には出てこない設計上の重複」です。これは見た目を確認しているだけでは気づけないので、コード側を通しで見直すタイミングを意識的に作る必要がありました。
だ
わたしとしては、「なんとなく動いている」状態で放置せず、原因まで説明してもらってから直す、というやり方にはこだわった気がする。
C
そこは実装のスピードだけを考えるなら遠回りですが、結果的には良かったと思います。原因を毎回言葉にすることで、同じ種類の事故（クラス名の衝突とか）が起きたときに「あ、またあのパターンだ」と気づけるようになりましたし、次に似た機能を追加するときの設計も、最初から衝突を避ける形にしやすくなりました。
現在地と締め
デザインを決めるところから始まって、実装で転げ回った話まで、ここまで振り返ってきました。今のところ、大きな見た目の崩れは一通り直せて、サイトとしては普通に動いています。ただ、検索ボックスの仕組みみたいに「動いてはいるけど理解しきれていない」部分もまだ残っているので、そのあたりは今後少しずつ潰していくつもりです。
PHPもCSSも分からないままここまで来られたのは、わたしが原因を理解せずに済ませなかったからというより、都度立ち止まって説明してもらえたからだと思います。次に何か作るときも、多分このやり方は変わらない気がします。
デザインを検討していた段階の話はこちらから読めます。
