WordPress 4.6で文字が変わって見えるときは管理画面と公開画面を混同しない

WordPress 4.6へ更新したあと、投稿一覧や編集画面の文字が以前と違って見えることがあります。最初に確認するのは、公開サイトのCSSではありません。文字が変わったのが管理画面だけなのか、編集画面なのか、読者が見る公開ページなのかを分けます。場所を間違えると、問題のない公開デザインまで直してしまいます。

4.6では、WordPressのダッシュボードが端末に入っているフォントを利用します。管理画面の読み込みを軽くし、利用する端末に合った表示にする変更です。Windows、Mac、スマートフォンで管理画面を開けば、文字の幅や行の高さが同じに見えないことがあります。

これは、公開サイトの文字をWordPressが勝手に変更する機能ではありません。公開ページのフォントは、テーマのCSS、外部フォントの読み込み、ブラウザーの表示条件で決まります。管理画面で違和感があったという報告だけで、テーマのfont-familyやfont-sizeを書き換える理由にはなりません。

文字の見え方を確かめるときは、書体名だけでなく、読めるかどうかを見ます。menuの項目が途中で切れていないか、長い投稿titleが一覧で区別できるか、設定画面の説明やwarningを読み取れるかを確認します。文字幅が少し違うことと、操作に必要な文が読めないことは別です。修正の優先順位は、作業を止めるかどうかで決めます。

文字の問題は四つの画面に分ける

「文字が詰まった」「見出しが途中で折り返す」と言われたときは、同じ内容を次の画面で開きます。見る内容をそろえなければ、画面の違いなのか、記事の違いなのか分かりません。

たとえば投稿一覧だけで題名が窮屈に見え、公開した記事は以前と同じ幅で読めるなら、テーマを修正する問題ではありません。編集者が使う管理画面の見え方を確認する問題です。反対に、公開した見出しが意図しない位置で改行されるなら、管理画面の変更と決めつけず、テーマのCSS、読み込んでいるフォント、表示幅を調べます。

投稿編集画面も、公開ページと同じではありません。テーマがeditor styleを用意している場合は、編集時の見え方を公開ページへ近づけられます。それでも、入力欄で読みやすいことと、読者の画面で読みやすいことは別の条件です。編集画面を整えるための変更を、公開ページのデザイン変更として扱わない方がよいでしょう。

たとえば、編集画面のtableが横へはみ出していても、公開pageではthemeのCSSで読める場合があります。このとき、記事を書く人にとって編集が難しい問題と、読者が読むページの問題を別々に記録します。逆に公開pageだけで長い英数字がはみ出す場合は、管理画面のnative fontsとは別に、themeの幅や改行の指定を調べます。画面を一つしか見ないと、直す場所を取り違えます。

直す前に同じ記事で確認する

確認には、新しく短い記事を作る必要はありません。見出し、長い段落、表、リンクが入った既存の記事を一つ選びます。その記事を管理画面と公開ページの両方で開けば、比較の基準になります。

次の順序で見ると、作業を広げずに済みます。

1. 文字が読みにくいと報告された端末とブラウザーを確認する。
2. 同じ記事を、投稿一覧、編集画面、Customizer、公開ページで開く。
3. どの画面で、どの文字が、どのように読みにくいのかを書き出す。
4. 管理画面だけの問題なら、管理画面側の表示を対象にする。
5. 公開ページにも問題があるときだけ、テーマのCSSと外部フォントを調べる。

この順序なら、「文字が変わった」という一つの報告から、必要のないテーマ改修やフォントの差し替えを防げます。見た目の問題は小さく見えても、編集者が毎日触る投稿画面なら作業時間に影響します。だからこそ、公開ページの見栄えだけで優先順位を決めません。

端末差を不具合と決めつけない

native fontsでは、端末ごとに利用できる書体が異なります。同じ管理画面でも、文字幅、かなと英字の組み合わせ、記号の位置が少し変わります。ある端末だけの画面を見て「WordPressの表示が壊れた」と判断すると、必要のない修正を始めることがあります。

もちろん、端末差だから放置してよいわけではありません。日常的に記事や商品を登録する人が、題名、設定、警告を読めないなら、その環境で確認する価値があります。ただし、問題を直す対象は、その画面に限定します。公開サイトに影響しない管理画面の差を理由に、読者向けのデザインを変えないことが重要です。

確認する端末を増やす前に、誰が日常的に使う端末かを聞きます。管理担当者がWindowsのbrowserで投稿を作り、別の担当者がMacで確認するなら、両方の画面を比べます。ほとんど使わない端末の見た目を完全にそろえるために、日常の編集作業を悪くする必要はありません。利用頻度と、文字が読めない影響を基準にします。

誰が確認し、誰が直すかを分ける

テーマのCSSを変更する作業は制作者へ任せられます。しかし、投稿画面を日常的に使う人が読めるか、公開した文章が読者に届いているかは、運用する側が確認しなければ分かりません。制作者へ「文字がおかしい」とだけ伝えても、対象画面が分からなければ、修正範囲が広がります。

伝えるときは、端末、ブラウザー、画面名、問題のある記事、どの部分が読みにくいかを残します。これで、管理画面の調整なのか、テーマの修正なのかを分けられます。作業を頼むことと、何を直すかを決めることは別です。

修正後は、報告があった端末と画面で同じ記事を開き直します。別のfontを指定した結果、投稿一覧の幅やbuttonの位置が変わっていないかも見ます。管理画面の表示を直すために、public pageのCSSまで変えた場合は、公開pageの見出し、本文、formを別に確認します。一つの文字の問題を直した結果、別の画面を読みにくくしないためです。

最初の一手は、同じ記事を管理画面と公開ページで開き、違和感がある画面へ印を付けることです。直す前に場所を特定すれば、更新後の文字を落ち着いて扱えます。