WordPress 4.7のcustom bulk actionは一括処理する投稿と確認方法を先に決める

WordPress 4.7では、投稿などのlist tableへcustom bulk actionを追加できます。一覧で複数の項目を選び、同じ処理を行うための仕組みです。ただし、一括で選べることと、一括で変更してよいことは別です。処理する投稿の条件、何を変えるか、処理後にどこを確認するかを先に決めます。

custom bulk actionは、list table画面のBulk Actionsに独自の選択肢を加えるために使えます。たとえば特定の投稿へ同じ分類を付ける、内部の確認状態を更新する、独自の処理を開始する、といった仕事をまとめられます。便利なのは繰り返し操作を減らせる点であり、異なる目的の投稿を同じ状態へ変えることではありません。

一覧で選ぶ条件と処理の内容を分ける

一括処理を作る前に、何を選んだ投稿へ適用するのかを言葉にします。「今月更新した記事」のように日付だけで選ぶのか、「内容確認が済み、同じ分類へ入れる記事」のように状態も確認するのかで、処理の安全性が変わります。一覧で複数選べるからといって、選ぶ基準まで自動でそろうわけではありません。

説明用の仮例として、複数の記事へ同じtopicの分類を付ける場合を考えます。titleに同じ語があるからとまとめて選ぶと、内容の違う記事まで分類へ入るかもしれません。先に各記事が扱う問いを読み、同じ分類へ置く理由を確認します。一括操作で分類を付ける作業と、分類の意味を決める作業は別です。

反対に、同じ処理を何十回も繰り返す必要があり、選ぶ条件が明確なら、一括処理は役に立ちます。たとえば一定の確認を終えた記事へ、内部用の状態を付ける場合です。このときも、状態を替える前に、対象の記事数、選んだ条件、処理する人を記録します。作業を速くすることより、どの記事を変えたかを後から確認できることを優先します。

処理した件数と正しく変わった件数を同じにしない

一括処理を実行したあと、画面に処理件数が出ても、すべての投稿が意図どおり変わったとは限りません。権限がない投稿、必要なdataがない投稿、別の設定で処理できない投稿が混ざる場合があります。件数の表示を完了報告にせず、代表する投稿を開いて結果を確認します。

確認する投稿は、一番簡単なものだけにしません。通常の記事、画像を含む記事、別の分類が付いている記事など、処理の条件が違うものを選びます。分類を変えたなら、個別記事の表示だけでなく分類archiveを開きます。内部の状態を変えたなら、一覧で見える値と、公開pageに意図しない表示が出ていないかを見ます。処理する画面と利用者へ見える画面は別です。

説明用の仮例で、独自の一括処理が記事へ確認済みの印を付ける場合を考えます。一覧で十件を選び、処理後に十件と表示されても、その印が公開pageへ出る設定なら、利用者が読む本文まで変わります。内部だけに使う印のつもりなら、公開pageで見えないことを確認します。管理用の状態と、読者へ伝える内容を同じ設定にしないことが必要です。

失敗した場合に、もう一度全件を選んで実行する前に、どの投稿が処理されなかったかを確認します。原因が権限、入力不足、外部処理の停止などで違えば、再実行しても同じ問題が残ります。対象の投稿、実行日時、処理結果、確認した人を残し、問題のある投稿だけを分けて調べます。一括処理は、失敗を一括で見えなくするためのものではありません。

処理前の状態を確認することも必要です。分類を追加するなら、すでに付いている分類を記録します。公開状態に関わる処理なら、下書き、公開済み、予約投稿を同じ対象として選ばないようにします。戻す必要が出たときに、何が変わる前だったかが分からなければ、正しい復旧はできません。元に戻す操作があるかどうかだけでなく、戻したあとにどのURLと一覧を確認するかも決めます。

一括処理の実行前には、選んだ投稿数と画面に表示されているtitleを読みます。同じtitleに見えても、別のカテゴリや別の投稿typeが混ざることがあります。数十件をまとめて選ぶ場合ほど、最初と最後だけでなく、途中の数件も開いて条件を確かめます。作業時間を短くするための機能でも、選択内容を読む時間までは省けません。

公開中の記事へ変更を加える場合は、処理後の確認を先延ばしにしません。分類や表示条件を替えた直後に、代表記事、一覧page、関連linkを開きます。利用者が読む内容に影響がない内部処理でも、themeやpluginがその値を表示に使っていることがあります。管理画面の成功表示と公開sideの結果を別に確認します。

実装と運用の責任を分ける

WordPress 4.7では、developerがlist tableのBulk Actionsへ独自の選択肢を登録できます。画面に選択肢を足すことと、運用側がその処理を使ってよい条件を決めることは別です。themeやpluginを作る人は、どのscreenで選択肢を出し、どの投稿typeへ処理するかを決めます。運用する人は、どの投稿を選び、いつ実行し、結果を誰が確認するかを決めます。

外部の制作会社へ機能追加を頼む場合は、「一括で更新できるようにする」とだけ依頼しません。対象の投稿type、選ぶ条件、変更するdata、公開pageへ影響するか、確認するURL、取り消しが必要な場合の手順を伝えます。制作会社が処理を実装できても、どの記事を同じ扱いにするかを決める人とは限りません。機能を作る作業と、投稿内容の責任を分けます。

一括処理を増やしすぎると、一覧画面で何を選べばよいか分からなくなります。利用頻度が低い処理や、毎回内容を読んで判断する処理まで一括化する必要はありません。手作業で一件ずつ確認する方が安全な場合もあります。処理を追加する理由が、作業時間を減らすことだけでなく、同じ条件を守れることかを確認します。

最初の一手は、一括で行いたい作業を一つ選び、対象の投稿、変える項目、処理後に開くpageを一行に書くことです。その条件で代表投稿を試してから、同じ条件の投稿へ広げます。