WordPress 4.8.1のCustom HTML widgetはcodeを貼る前に置く目的と更新する人を決める

WordPress 4.8.1で追加されたCustom HTML widgetは、sidebarなどへHTMLを置くための場所です。使えるようになったからといって、外部serviceのcodeや長い案内文をまとめて貼る場所にしてはいけません。まず、そのwidgetで読者に何を見せるのか、誰が内容を更新するのか、表示が崩れたときに誰が直すのかを決めます。codeを入れる作業と、公開中の案内を管理する仕事は別です。

WordPress 4.8.1は8月2日に公開され、rich Text widgetの修正とともにCustom HTML widgetが導入されました。管理画面にHTMLを入力できる欄があれば、画像、link、埋込み、外部serviceの表示を置けます。しかし、その欄に何でも入ることと、どの内容でもsidebarへ置くべきことは違います。読者にとって必要な案内か、更新を続けられるかを先に考えます。

textとHTMLは書く人ではなく役割で分ける

文章だけを直す案内なら、text widgetや固定pageで管理できる場合があります。営業時間、問い合わせ先、短い補足のように、担当者が文章を読み直して更新する情報です。一方で、HTMLの形を保つ必要があるlink、外部serviceから渡された埋込みcode、見出しとlinkを組み合わせた小さな案内などは、Custom HTML widgetに置く理由があります。

説明用の仮例として、sidebarへ「資料をdownloadする」案内を置く場合を考えます。資料名、更新日、link先を文章として伝えるだけなら、読める文で案内します。buttonの形や画像を使うためにHTMLを置くなら、そのcodeを誰が直すかまで決めます。資料の差替え時にURLだけを替えればよいのか、表示する日付も直すのか、古い資料を消すのかで、作業は変わります。

文章の担当者がHTMLの構造を触れないなら、無理にCustom HTML widgetへ集めません。反対に制作者が更新する内容なら、文章の担当者がその場で書き換えるべき情報を入れない方がよいでしょう。入力欄の種類ではなく、内容の性質と更新責任で分けます。

HTMLを使えば見た目を細かく変えられますが、sidebarの狭さ、mobileの画面、themeを替えたときの見え方まで自動で整うわけではありません。横幅を固定した画像や、長いURLを含むlinkは、画面幅によって読みにくくなることがあります。管理画面で保存できたかだけでなく、公開画面で読者が押せる大きさか、文章の順が分かるかを確認します。

外部serviceのcodeは出所と目的を残す

外部serviceから渡されたcodeをwidgetへ貼る場合は、どこから受け取ったcodeかを残します。地図、動画、予約、SNSの表示などは、見た目だけをコピーすると、後でサービス名、設定画面、契約しているaccountが分からなくなるからです。widgetの本文へ長い説明を足す必要はありません。別の管理表に、表示の目的、service名、管理account、更新担当、貼った日を残します。

外部のcodeには、表示するためのscriptやstyleが含まれることがあります。貼り付けた直後に表示できても、読み込み先が変わる、service側の設定が変わる、themeやpluginと干渉する可能性があります。内容を理解しないまま、表示されたからといって同じcodeを複数のsidebarやpageへ増やしません。必要な場所を一つ決め、目的が異なる場合だけ別に置きます。

たとえば、予約serviceへのlinkをsidebarへ置くなら、読者が予約したいページを開けることが目的です。予約件数を数えたい、外部siteの投稿を並べたい、動画を再生させたいという目的とは分けます。目的が違えば、必要なcode、読む人、確認する画面、止めるときに消す場所も変わります。「便利そうだから貼る」では、後で残す理由を説明できません。

外部serviceの契約やaccountを制作会社が作った場合も、widgetのcodeだけを納品物と考えない方がよいでしょう。事業側が、何のserviceを使い、誰へ更新や停止を頼めるかを把握していなければ、表示が消えたときに判断できません。制作を委託することと、公開siteに置く仕組みの責任を手放すことは別です。

保存前と公開後の確認を分ける

Custom HTML widgetを編集するときは、入力欄の中だけを見て終わらせません。まず、既存のcodeと文章を控えます。変更する箇所を一つにし、保存後に公開pageを開きます。sidebarは、top pageと投稿page、PCとmobileで置かれる場所が違うthemeもあります。目的の画面で、表示されるか、link先が開くか、ほかの案内を押し下げていないかを確認します。

仮に画像のlinkを追加したとき、画像だけが表示されてlink先を間違えた場合があります。外部serviceを埋め込んだときは、管理画面のpreviewではなく公開pageで、読み込みに失敗していないかを見ます。見た目に問題がなくても、更新日を過ぎた案内や、終了したcampaignへのlinkが残っていれば、読者には古い情報を渡すことになります。

変更を頼むときは、制作担当へ「sidebarを直してください」とだけ送らず、どのpageのどの位置にあるwidgetか、残す内容、消す内容、link先、確認する画面を渡します。受け取る側は、変更後のURLと、確認した画面を返します。このやり取りがあれば、同じ名前のwidgetが複数ある場合にも、別の案内を誤って変えにくくなります。

更新頻度の高い情報をHTMLへ直接書く場合は、期限の過ぎた内容を消す人も決めます。今日だけの案内、募集、在庫、休業日は、置く時点より、外す時点の方が忘れられやすいからです。HTMLで見出しを整えても、更新担当がいなければ情報は古くなります。表示を作る仕事と、公開を終える仕事を一緒に予定へ入れます。

widgetを増やす前に置かない選択もする

sidebarは、何でも置ける余白ではありません。案内が増えるほど、読者はどのlinkを押せばよいか分かりにくくなります。新しいwidgetを加える前に、今ある案内のうち、問い合わせ、資料、会社情報、最新記事など、何を優先して見せるかを確認します。目的が同じlinkが二つあれば、一つへまとめる方が読者は迷いません。

HTMLが必要な表示でも、本文中に置いた方が文脈を伝えられる場合があります。個別serviceの説明を読んだ人へだけ案内するなら、そのservice pageにlinkを置く方が、すべてのpageのsidebarへ同じbuttonを出すより分かりやすいことがあります。共通のsidebarに置くのは、どのpageを読んでも同じ行動へ案内したい場合です。

最初の一手は、新しく置こうとしているcodeの横へ「何を見せるか」「誰が更新するか」「どの画面で確認するか」の三つを書くことです。三つに答えられなければ、まだwidgetを増やす段階ではありません。Custom HTML widgetは、貼り付けを簡単にするための場所であって、公開情報を考えずに増やすための場所ではありません。