制作・引き渡し
WordPressで顧客の誤操作を防ぐには
顧客がWordPressの文章や画像を更新しながら、レイアウトを崩しにくくするには。ブロックの挿入制限とロック、公開前後の確認、リビジョンとバックアップを使い分け、案件ごとの編集範囲と戻し方を決めます。

写真を差し替えるつもりが、周りの見出しやボタンまで消えてしまう。日々の更新を顧客に任せる前に、こうした操作も想定して編集画面を整えておきます。
文章や画像は顧客が更新できるようにし、日常の更新に不要な構造の変更は制作者が担当します。それでも誤操作は起こり得ます。公開結果をどう確認し、間違えたときにどう戻すかまで決めておきます。
変える内容と、形を保つ部分を分ける
たとえば、仕事紹介ページに「見出し・写真・説明・応募ボタン」が並んでいるとします。採用担当者が担当するのは写真と説明の差し替え。並び順や余白の変更は制作会社へ依頼する、という分担です。
この場合、ページ全体を編集不可にすると日常更新も止まります。文章と画像を編集できる状態は残し、それらを囲むグループや応募ボタンを動かしにくくする方が、この分担に合っています。
まず顧客が変更する内容を聞き、その範囲に合わせてロックを選びます。写真の差し替えだけでなく、項目の追加、順番変更、リンク先変更、公開停止まで聞いておきます。まだ決まっていない操作があれば、要件定義の確認項目で確認します。制作者の判断だけで制限をかけないためです。
あわせて、公開や復旧を誰が担当するかも決めておきます。まだ決まっていなければ、更新担当の役割分担で、入力する人、確認する人、問題時に直す人を分けてください。
ブロック制御は、止めたい操作で選ぶ
WordPressのブロック制御には、追加を制限するものや既存の配置を保つものなどがあります。止めたい操作に合わせて選びます。
| 制御 | 向いている使い方 | それだけでは決まらないこと |
|---|---|---|
| 挿入できるブロックの種類を絞る | 段落、見出し、画像など、日常更新に使う候補を限定する | すでにあるブロックの配置や、保存処理の権限 |
| 個別ブロックの移動・削除をロックする | 応募ボタンなど、残しておきたい部品を固定する | 文章やリンク先まで編集不可になるとは限らない |
| ブロック構成を固定する | 必要な見出しや項目を残し、追加・移動・削除を抑える | デザイン設定やロック解除を誰に許すか |
| 内容のみの編集にする | 文章や画像の更新を中心にし、レイアウトの編集を減らす | 採用したブロックで何を編集できるか、解除できるか |
挿入候補の指定にはallowed_block_types_allを使えます。構成の固定は、公式のテンプレートのロックを参照します。たとえばtemplateLockのallは、追加・移動・削除を制限する設定です。
内容のみの編集にはcontentOnlyを使います。ロック操作を許すかどうかの指定はcanLockBlocksです。どちらもブロックロックの公式資料で確認できます。設定名だけで判断せず、入れ子のブロックや解除操作まで、顧客が使うアカウントで確かめます。
記事本文のように、その都度見出しや画像を足す場所まで一律に固定すると、必要な更新ができません。定型の採用ページと自由に書く記事では、制限を変えて構いません。
メニュー非表示は、権限を取り消す機能ではない
使わない管理メニューを隠せば、担当者が更新画面を探しやすくなります。ただし、remove_menu_page()が取り除くのはメニューの表示です。アカウントが持つ操作権限を、それだけで取り消すわけではありません。
禁止したい操作は、直接URLを開いた場合や保存を試みた場合にも拒否される必要があります。権限を見直すときは、顧客へ渡す操作の決め方で対象と操作を確認します。ブロックロックも、編集画面での誤操作を抑える仕組みとして使い、アクセス制御と混同しないでください。
特に、ブロックテーマのサイトエディターでは、ヘッダー、フッター、テンプレート、全体スタイルを扱います。文章の更新だけを担当する人に、サイト全体を変更する操作まで必要かを分けて考えます。
変更ごとに、確認先と戻し方を決める
編集画面を絞ったら、顧客が行う変更を一行ずつ書きます。次は採用ページの設計例です。担当者と対象ページを自分の案件に置き換えて使ってください。
| 変更したい内容 | 編集範囲と制御 | 公開前後の確認 | 間違えたときの戻し方 |
|---|---|---|---|
| 仕事紹介の文章 | 本文は編集可。外側の配置は固定 | 修正した段落と周辺の見出しを確認 | 履歴が残っていれば、該当箇所を以前の内容へ戻す |
| 職場写真 | 画像は差し替え可。周辺の部品は固定 | パソコンとスマートフォンで切れ方・順番を確認 | 旧画像を残し、選び直せるようにする |
| 求人条件 | 必要な入力欄を編集可。表示用の構造とは分ける | 正式な条件と公開ページを照合 | 本文以外の入力項目も戻せる方法を確認しておく |
| 応募ボタン | 通常は配置を固定。リンク先変更は担当者を限定 | 実際の応募先まで移動して確かめる | 変更前のURLと設定値へ戻し、到達を再確認 |
| 共通ヘッダー | 日常更新から分け、制作者が変更 | 変更したページ以外の主要ページも確認 | 共通部分の変更を戻し、影響したページを再確認 |
「見た目が崩れていない」だけでは、求人条件やリンク先の間違いは分かりません。何を変えたかに応じて、確認する場所を指定します。
別の人の承認を挟む場合は、公開済みページの更新にもその手順を適用できるか確認してください。新規記事を下書きにできても、公開済みページの修正を承認まで保留できるとは限りません。
リビジョンで戻せるものを、先に試しておく
WordPressのリビジョンは、保存した改訂を比較し、以前の内容へ戻すために使えます。ただし、履歴の保持設定や投稿タイプの対応状況によって、利用できる範囲は変わります。
求人条件をカスタムフィールドへ保存している場合は、その項目も戻るか確認します。項目の登録設定には、リビジョンを有効にする指定があります。本文とは別に、求人条件も復元できたかを確かめます。
画像ファイルやサイト全体の設定まで戻すには、別の復元手段が必要になることがあります。WordPress公式のバックアップの解説でも、データベースとファイルを分けて扱っています。
一方、文章一か所の修正で、サイト全体を前日の状態へ戻してしまうと、その後の正常な更新まで失うおそれがあります。まず何が変わったかを調べ、戻す対象と時点を選びます。対象を絞れない場合は編集を止め、復旧担当へ引き継ぎます。
納品前に、検証用データで復元を一度試します。バックアップの有無だけでなく、その案件で必要な内容まで戻るかを確かめてください。
顧客用アカウントで、更新から復元まで試す
確認には、本番と同じ構成の検証環境を使います。管理者の画面でロックが見えていても、顧客の画面で同じ動きになるとは限りません。
- 必要な更新ができるか。 代表ページの文章と画像を変え、保存して開き直す。
- 止めたい操作が止まるか。 固定した部品の移動・削除、ロック解除を試す。権限が必要な画面は、メニュー以外の経路からも確認する。
- 変更がどこへ出るか。 決めた承認手順を通し、ログアウトした公開画面で本文・画像・リンク先を確認する。
- 間違いから戻れるか。 検証用データを変更前へ戻し、本文だけでなく入力項目と公開表示も照合する。
- 構造変更後も保護が残るか。 制作者が解除して直した場合は、再保護して顧客用アカウントでもう一度確認する。
必要な更新まで止まった場合も不合格です。解除の依頼がないと日常業務が進まないなら、編集範囲を広げるか、変更方法を見直します。
結果には対象ページ、試したアカウントの権限、期待した動作と実際の動作、復元担当を残します。制作・引き渡しチェックリストへ添えれば、顧客と制作会社が同じ条件で受け入れを確認できます。
2GUの編集保護を使う場合
2GUでは、採用キットが生成し、管理対象になっているページに編集保護を用意しています。日常更新する内容と主要な構造を分け、管理者が構造編集のために一時解除し、再保護する方式です。
任意のページをすべて保護する機能や、バックアップの代わりではありません。今回の表で決めた更新範囲に合うかを、商品固有の操作手順と照合してください。