WordPress 4.6のcontent recoveryは下書きの復元と公開前の確認を分ける

文章を書いている途中にbrowserを閉じたり、通信が切れたりしても、WordPress 4.6ではeditorの内容をbrowserへ保存し、復元しやすくなります。これは書きかけを失いにくくする仕組みです。復元された文章が、そのまま公開してよい文章であることを保証するものではありません。

4.6のcontent recoveryは、入力中のcontentをbrowserへ保存します。復元後には、見出し、本文、link、画像、公開日時、意図しない書き換えがないかを確認します。保存された途中の状態と、編集者が承認した下書きを同じものとして扱わないでください。

書きかけの文章には、考えるために置いた文と、読者へ出す文が混ざります。見出しの案、確認前の数値、仮のlink、本文から外した段落が残ることもあります。復元できたことは、作業を続ける出発点です。内容が正しいこと、公開日時が正しいこと、分類が決まっていることまでを復元機能へ任せません。

復元する内容と公開する内容を分ける

下書きには、編集途中の断片、確認前の数字、書き換え前の表現が残ります。

説明用の仮例として、記事の途中でbrowserを閉じ、翌日に復元した場合を考えます。復元した本文に、前日には仮置きだった価格やlinkが残っているかもしれません。文章が戻ったことだけを確認せず、公開する原稿としてもう一度読んで、仮例や編集メモが本文へ混ざっていないかを見ます。

復元した原稿では、本文の先頭と末尾を先に見ます。途中だけを読み直すと、titleを直したあとに本文の結論が古いまま残っている、末尾の注記が途中で切れている、といった問題を見落とします。長い原稿なら、見出しだけを一覧にし、話の順が変わっていないかを確認します。書いた順と、読者が読む順は同じとは限りません。

画像も復元した本文と一緒に確認します。記事に画像の説明を書いていても、media libraryの画像を差し替えた直後だった場合は、本文と表示する画像が合わないことがあります。画像のalt文、caption、link先、表示位置をpreviewで確認します。本文に残った「図のとおり」という文だけを見て、画像があると決めません。

公開日時とcategory、tagも、復元時に戻った内容をそのまま使いません。下書きを始めた日に設定した日時が残っていれば、意図しない日時で公開されることがあります。categoryが仮のままなら、archiveの案内が狂います。復元後の原稿は、文章だけでなく投稿としての設定まで一つずつ見直します。

復元後の確認順を決める

content recoveryを使う場合は、復元した直後に公開buttonを押しません。まずWordPressの下書きへ保存し直し、browserに残った一時的な内容と投稿dataをそろえます。次にpreviewを開き、読者が見る画面で確認します。復元前にどこまで保存されていたかを覚えているつもりで作業せず、画面ごとに確かめます。

1. 投稿titleと本文の末尾が欠けていないか確認する。
2. 見出しの順序、link、画像、tableを確認する。
3. 下書きへ保存し直し、WordPress側の投稿dataとそろえる。
4. previewで表示を確認する。
5. 公開日時、category、tag、本文の承認者を確認する。

説明用の仮例として、本文の中へ外部資料へのlinkを三つ置いた記事を考えます。復元直後にはlinkの文字が見えても、URLが編集途中のものか、link先が公開状態かは別に確認します。inline link checkerがURLの形を確認しても、資料の内容や公開状態は開いて見ます。復元したlinkは、保存できたかではなく、記事の根拠として使えるかを確かめます。

browserに残る内容は、ほかの端末や別のbrowserで同じように復元できるとは限りません。長い原稿、画像、重要な変更はWordPressの下書きへ保存し、必要な場合は別に正本を持ちます。正本を複数の場所へ置く場合は、どちらが公開前の最新版かを決めます。同じ記事のコピーを二つ直して、片方だけ公開すると、後からどの文章を承認したかが分からなくなります。

復元後の確認では、文字数だけを見て不足や重複を決めません。段落の途中で文が切れていないか、同じ段落が二度入っていないか、見出しと本文が対応しているかを読みます。editor上では改行に見えても、previewで表や引用の位置が崩れることがあります。公開画面の確認は文章校正の代わりではありませんが、読者が読める形になっているかを知るために必要です。

承認者が別にいる場合は、復元したことと、承認を求める原稿を保存したことを分けて伝えます。「復元したので確認してください」だけでは、復元前後のどちらを読めばよいか分かりません。下書きの更新日時、確認してほしい範囲、公開予定日時を添えます。編集作業が中断したときほど、次に読む人が判断できる記録を残します。

復元機能と編集の承認を分ける

WordPressの機能やeditorの設定は制作側が整えられます。しかし、どの文章を下書きの正本にするか、誰が公開を承認するか、誤って戻した内容をどう扱うかは、記事を運用する側が決めます。復元できることと、内容が正しいことは別です。制作側がbrowserの保存を有効にできても、本文に書く事実や公開する日時を承認することはできません。

制作側へ頼むときは、editorで保存する場所、復元後に確認する画面、previewの方法、revisionを比べる方法を渡します。記事の担当者は、本文、link、画像、category、tag、公開日時を確認します。承認者は、公開してよい内容かを決めます。役割を分けても、誰も公開画面を見ない状態にしないことが必要です。

最初の一手は、公開前の原稿について「下書きの保存先」「正本」「previewの確認者」「公開日時を決める人」「承認者」を記録することです。復元後は、本文の先頭と末尾、見出し、link、画像、投稿設定、previewの順に確認します。復元した文章を扱う順序が決まります。content recoveryは書きかけを戻すための機能であり、公開する原稿を自動で選ぶ機能ではありません。