WordPress 4.7.4のmaintenance updateはvisual editor、media、REST APIを使うpageから確認する

WordPress 4.7.4を更新した後は、管理画面に新しいversionが出たことだけで終えません。今回の更新ではvisual editorとChromeの互換性、mediaの扱い、REST APIの改善が案内されています。自分のsiteでどの機能を使っているかを確認し、利用者が読むpage、更新担当者が編集する画面、外部とつながる処理を分けて確かめます。

WordPress 4.7.4の公式発表は、47件のmaintenance fixとenhancementを含むreleaseとして、Chromeの次期versionとvisual editorの互換性、media handlingの不整合、REST APIの改善を主な内容に挙げています。これはsecurity releaseのように脆弱性の対象版だけで判断する更新ではありません。更新を見送る理由を探すのではなく、事業で使う画面を絞って確認できる状態を作ります。

maintenance updateは更新通知と使える状態を分けて考える

maintenance updateでは、問題が一つだけ直るとは限りません。WordPress本体の修正は、管理画面、theme、plugin、media library、外部連携が動く共通の土台へ入ります。管理画面の更新画面で4.7.4を確認できても、投稿の編集、画像の追加、問い合わせの導線、外部から読むdataまで同じように確認されたことにはなりません。

まず、siteの目的から優先順位を決めます。会社案内が中心なら、top page、service page、問い合わせpageが読めることを先に見ます。記事を継続して書くsiteなら、下書きを開き、visual editorで文章を直し、保存して表示を確かめます。写真やaudioを多く使うsiteなら、既存のmediaを含むpageと、新しいfileを追加する画面を別に見ます。

説明用の仮例として、毎週スタッフが記事と施工写真を更新する会社siteを考えます。更新担当者はWordPress 4.7.4へ上げた後、既に公開している記事を直接書き換えません。新しい下書きを一つ開き、短い文章を入れ、画像を選び、previewで表示を確認します。公開側では、別のbrowserまたはloginしていない状態で記事pageを開き、本文、画像、link、問い合わせへの導線を見ます。編集画面で保存できることと、読者に正しく届くことは別です。

自動更新が動くsiteでも、確認する人と時刻は残します。更新を実行する仕組みと、業務で使う画面を確認する仕組みは違います。保守会社が更新した場合は、適用したversion、更新した時刻、backupの場所、確認したURL、未確認の機能を受け取ります。site側は、営業時間、料金、問い合わせ先、商品条件のように内容を判断できる人が公開画面を確認します。

visual editorでは保存だけでなく編集した内容を見る

公式発表は、visual editorとChromeの次期versionに関する互換性を主なfixとして挙げています。visual editorを使うsiteでは、画面を開けるかだけでなく、文章を編集し、保存し、公開側で同じ内容が見えるかを確かめます。

確認用の下書きには、短い見出し、段落、link、太字、番号付きの案内を入れます。実際に使う書式を少しずつ含めることで、単なる文字入力と、編集作業全体を分けて見られます。貼り付けた文章だけで試すと、linkの作成や段落の扱いに問題があっても気づかないことがあります。

その後、previewを開きます。見出しが本文の中へ混ざっていないか、link先が正しいか、段落の間隔が極端に崩れていないかを見ます。管理画面のeditorで見える表示と、themeを通して公開される表示は同じではありません。editorで正しく見えるからといって、themeのCSSやpluginのscriptまで正しいとは限りません。

browserを一種類だけに絞る必要はありませんが、更新担当者や読者が実際に使うbrowserを確認対象に含めます。Chromeだけで起きる問題を直した更新であっても、他のbrowserの表示を見なくてよい理由にはなりません。広い画面とphoneの幅で、menu、本文、画像、formを試します。更新対象を増やすことより、siteの利用者が通る入口を確認する方を優先します。

編集の途中で問題が出たら、公開中の記事を何度も保存し直して調べません。問題が起きた操作、下書きのURL、browser、時刻、表示されたmessageを記録します。editorの設定、theme、plugin、browser extensionのどこに原因があるかは、表示だけでは決まりません。調べる間は追加のplugin更新やthemeの変更を重ねず、原因を分けられる状態を保ちます。

mediaは表示と追加の二つを確認する

WordPress 4.7.4ではmedia handlingの不整合に関する修正も案内されています。mediaを使うsiteでは、既に公開している画像、音声、videoが読めることと、新しいfileを追加できることを分けて確認します。

既存の画像は、top pageだけを見ません。記事の本文中にある画像、一覧に出るthumbnail、固定pageの写真を選びます。スマートフォンで開く場合は、画像が横へはみ出さないか、拡大したときに説明が読めるかも見ます。写真が表示されることと、画像の周りにある見出しやlinkが使えることは別です。

新しいfileを試すときは、本番の差し替えが必要ないtest用の画像を一つ用意します。media libraryへ追加し、下書きへ置き、previewで見ます。画像にtitleや代替textを入力する運用なら、その入力欄が使え、公開側で必要な説明が残るかも確認します。testが終わったら、公開予定のない下書きとtest用fileをどう扱うかを決めます。確認のためのdataを残し続けると、後から更新する人が誤って使う可能性があります。

audioやvideoを使うsiteなら、fileが一覧へ出るだけでなく、公開pageで再生まで進みます。外部の動画serviceを埋め込む場合は、embedした画面、play操作、phoneでの表示を見ます。WordPress本体の更新、外部serviceの仕様、themeの表示を一度に変えると、どこで問題が出たかを追えません。更新後の確認では、代表的なmediaを一種類ずつ選びます。

画像を制作会社が用意し、site側がWordPressへ入れる運用なら、file名、保存場所、代替text、掲載pageを引き継ぎます。制作会社が更新作業を終えても、どの写真がどの商品やserviceを示すか、いつ差し替えるかは事業側が決めます。media libraryの操作を任せることと、公開する内容の責任を任せることは別です。

REST APIを使う連携は画面の外で確認する

REST APIは、外部のapplicationやsiteがWordPressのdataを読む、または更新するための入口です。公式発表でREST APIの改善が案内されていても、全てのsiteが外部連携を使っているわけではありません。使っていないsiteは、使わない機能を無理に試す必要はありません。使っているsiteだけ、連携先と実際に渡るdataを確認します。

たとえば、別のsiteへ記事一覧を出す、予約systemへ情報を渡す、独自の管理画面から投稿を更新する仕組みがある場合を考えます。更新後には、代表となる一件のdataを読み、title、本文、公開日時、画像URLなど、連携先で必要な項目が読めるかを確認します。更新機能があるなら、test用の下書きだけを対象にし、公開中の記事をtestのために書き換えません。

REST APIのURLが応答することだけでは、連携が使える証明になりません。連携先が必要な項目を正しく読み、権限がないdataを更新できず、利用者に見せるpageで内容が正しいことを分けて見ます。外部の開発者へ任せている場合は、endpoint、使うdata、更新権限、確認方法、障害時に止める人を記録します。

更新後に連携の数字や表示が変わったら、WordPress 4.7.4だけを原因と決めません。連携先の更新、認証情報の期限、networkの障害、dataの入力内容でも結果は変わります。いつからどのURLで何が違うのかを記録し、WordPress本体、theme、plugin、連携先を順に切り分けます。正常かどうか分からない連携を、見た目の問題としてthemeへ直し込まないことが大切です。

確認結果は更新作業と分けて残す

更新後の確認には終わる順番があります。最初にversionを見ます。次に、利用者が使う主な公開pageを開きます。その後に、更新担当者が使うeditorとmediaを試します。最後に、使っている場合だけREST APIや外部連携を確認します。この順なら、事業への影響が大きい入口から確認できます。

確認結果は「問題なし」と一言で残しません。たとえば「2017年4月28日、WordPress 4.7.4、top page、service page、問い合わせform、記事下書きの保存、画像追加を確認。予約連携は翌日の予約作成時に確認」と残します。まだ試していないものを未確認と書けば、後から担当者が確認を引き継げます。更新した人と確認した人が別でも、何を終えたかを共有できます。

問題が出た場合は、追加の更新を止め、戻すかどうかを決めます。表示が少し崩れたことと、問い合わせを受けられないことは影響が違います。どのURLで、誰が、どの操作をできないのかを先に確かめます。backupから戻す必要があるなら、復旧する担当者、戻す範囲、更新後に増えた投稿や問い合わせをどう扱うかを決めます。更新を元へ戻すことは、原因調査の代わりではありません。

最初の一手は、WordPress 4.7.4が適用されたversionを確認し、普段の業務で使う公開page、下書きの編集、画像の追加から一つずつ試すことです。REST APIを使うsiteでは、その後に代表dataを連携先で確認します。