WordPressの投稿は執筆と公開を分け公開前に確認する内容を一枚に残す

WordPressで記事を増やすとき、原稿を書く人へ管理者権限を渡す必要はありません。原稿を作る作業、内容を確認する作業、公開を判断する作業は分けられます。最初に、誰が下書きを作り、誰が公開し、公開前に何を確認するかを決めます。権限を広く渡すことより、誤った内容や未確認のlinkを公開しない流れを作る方が先です。

WordPressの標準roleでは、Contributorは自分の投稿を編集できますが、publish_postsは持ちません。Authorは自分の投稿を公開できます。Editorは他人の投稿を編集、公開できます。WordPressのRoles and Capabilitiesは、roleがcapabilityの組み合わせであり、投稿を編集することと公開することが別の権限であると説明しています。この違いを使えば、原稿を渡す人と、siteへ出す人を分けられます。

原稿を書く人へ管理者権限を渡さない

管理者は、投稿だけでなく、theme、plugin、利用者、site設定など、広い範囲へ変更を加えられます。記事の原稿を追加するために管理者を増やすと、公開内容とは関係ない設定まで変えられる状態になります。便利だからという理由だけで管理者を渡すのではなく、その人が必要とする作業からroleを選びます。

記事の流れを単純にするなら、原稿を作る人はContributor、内容を確認して公開する人はEditorまたはAdministratorという分け方が考えられます。Authorを使う場合は、原稿を書く人が自分で公開できるため、公開前の確認をroleだけで止めることはできません。Authorを使ってはいけないのではなく、誰が公開判断をするかと合うかを確認します。

説明用の仮例として、会社の担当者が月に数本の記事を書くsiteを考えます。担当者は原稿を下書きへ保存し、サービス内容や料金の記述を事業責任者が確認します。公開担当はtitle、URL、カテゴリ、画像、link先を見てから公開します。この流れなら、原稿の担当者がthemeやpluginを触る必要はありません。公開担当が不在なら、公開を遅らせるのではなく、代わりに判断する人を決めます。

投稿のstatusと公開の判断を同じ意味にしない

下書きになっていることは、内容が正しいことを意味しません。公開済みであることも、必要な確認が済んだことを自動で示しません。WordPressのstatusは投稿の状態を表す仕組みであり、誰が何を読んだかを記録する仕組みではありません。公開前の確認項目を別に持ちます。

確認表は長い報告書にする必要はありません。記事ごとに、判断に必要な項目だけを一枚へ残します。たとえば、次のように分けます。

この表は、確認者に責任を押し付けるためのものではありません。公開後に問題が見つかったとき、原稿の内容、WordPressの設定、画像、linkのどこを直すかを分けるためのものです。「記事を確認した」とだけ残すより、どの項目を誰が確認したかを短く残す方が、次の記事も早く出せます。

権限だけでは公開前の確認を代わりにしない

Contributorが自分で公開できないからといって、投稿内容が自動で安全になるわけではありません。Editorが公開できるからといって、出典、料金、営業時間、利用条件まで正しいとは限りません。roleは操作できる範囲を決めます。公開する内容の責任と、事実を確認する作業は別に残ります。

たとえば、記事内に外部linkを置く場合、公開担当はlinkを開き、移動先が本文の説明と合っているかを確認します。問い合わせを案内する場合は、formが表示されるだけでなく、送信後の画面と受信先まで確認します。画像を追加する場合は、media libraryへ置いただけでなく、公開pageで見出しや本文を隠していないかを見ます。投稿を公開する操作は、こうした確認の最後に置きます。

WordPressの標準roleへpluginや独自codeがcapabilityを追加している場合、管理画面の見え方や操作できる範囲が標準と異なることがあります。role名だけを見て、必ず同じ操作ができると決めつけません。新しい利用者を加える前に、test用のaccountで投稿一覧、下書き保存、画像追加、公開操作を確認します。権限を一度に広げず、必要な作業ができる最小の範囲から始めます。

外部の制作会社へ保守を頼む場合も、作業を任せることと、WordPress accountや投稿の履歴をsite側で確認できることは別です。管理者accountを一つだけ外部の担当者が持つ状態では、担当変更や緊急時に投稿を直せません。少なくとも、site側で管理するaccount、連絡先、backup、公開手順を把握します。

公開後は公開画面と記録を確認する

公開した直後に、管理画面の一覧だけを見て終わりにしません。loginしていないbrowserで記事を開き、title、本文、画像、category、tag、関連linkを確認します。mobile画面では、長いtitleやtableが読めるか、linkを押せるかも見ます。管理画面で保存できても、themeが公開側でどう出力するかは別の確認です。

公開日時を指定する記事では、本文に書いた日付とWordPressの公開日時を同じ意味に扱います。記事の基準日、実際に表示する公開日、後から変更した日を混ぜると、読者も運用者もいつの情報か分からなくなります。公開後に直す必要が出た場合は、直した本文、理由、確認した人を記録します。大きな変更なら、元の判断を残したまま、何を更新したかを明らかにします。

1. 執筆者、確認者、公開者を決める。
2. それぞれが必要とする操作からWordPress roleを選ぶ。
3. 記事ごとに、本文、出典、URL、画像、link、公開日時を確認する表を作る。
4. test accountで下書き保存と公開までの操作を試す。
5. 公開後はloginしていない状態で記事を開き、表示とlinkを確認する。
6. 公開した日時、確認者、未確認項目、修正内容を残す。

この流れは、投稿を遅くするためのものではありません。原稿作成、確認、公開のどこで止まったかを分かるようにし、無関係な管理者権限を増やさずに記事を続けて出すためのものです。最初の一手は、次に公開する記事一件について、原稿を書く人と公開buttonを押す人を別に書くことです。