• WordPress 4.4のshow_uiは公開URLと管理画面の表示を分けて決める

WordPress 4.4のshow_uiは公開URLと管理画面の表示を分けて決める

公開日: 執筆:佐藤

独自投稿タイプを登録するときは、公開URLを持たせるかどうかと、WordPressの管理画面で編集するかどうかを別に決めます。WordPress 4.4では、show_uiがfalseの投稿タイプについて、手でURLを入力しても投稿一覧と編集画面へ入れなくなります。以前はメニューに出していなくても直接URLで扱えていた処理があれば、更新前に設定を見直します。

ここで問題になるのは、メニューを隠していることではありません。日常の更新に必要な編集画面まで隠しているのに、担当者やプラグインが直接URLで開く前提になっていることです。非公開のデータだから管理画面を使わない、公開する投稿だから誰でも編集できる、とまとめて決めません。公開範囲、編集画面、メニュー、権限、データの利用先を分けます。

4.4ではshow_uiがfalseの編集画面を直接開けない

WordPressの開発者向け資料によると、WordPress 4.4ではshow_uiがfalseの投稿タイプに対し、投稿一覧と編集画面がより厳密に制限されます。以前は管理メニューに表示しなくても、URLを手入力すればこれらの画面へ入れることがありました。4.4ではその動作に頼れません。

たとえば、予約記録、問い合わせ記録、連携用データのように、利用者へ公開しない投稿タイプでも、担当者がWordPressの編集画面で内容を確認する必要がある場合があります。このときshow_uiをfalseにしたまま、ブックマークした編集URLだけを担当者へ渡していると、更新後に入口を失います。

公式資料は、そのような場合にshow_uiをtrueへし、必要に応じてshow_in_menu、show_in_nav_menus、show_in_admin_barをfalseにする方法を案内しています。つまり、編集画面は使えるようにしながら、通常の管理メニュー、ナビゲーションメニューの選択肢、管理バーには出さない構成です。

決めること 関係する設定や確認先 問い
管理画面で編集するか show_ui 担当者が一覧と編集画面を使うか
管理メニューに出すか show_in_menu 日常の操作でメニューから入る必要があるか
メニュー項目として選べるか show_in_nav_menus サイトのナビゲーションへ使わせるか
管理バーに出すか show_in_admin_bar 管理中の近道として必要か
利用者へ公開するか 投稿タイプの公開設定とテンプレート 個別ページや一覧を読者へ見せるか
誰が変更できるか ロールと権限 更新担当以外へ編集を許すか

show_uiは、投稿タイプを公開するかどうかを単独で決める設定ではありません。また、編集権限そのものでもありません。管理画面を出すか、メニューへ出すか、読者へ公開するかを一つの設定名から判断すると、意図した運用と違う状態になります。

たとえば、予約の内容を読者へ公開しないが、担当者は管理画面で確認して更新したい場合を考えます。この場合は、投稿タイプを読者向けの一覧に出さない判断と、担当者へ編集画面を渡す判断が両方必要です。show_uiをfalseにして入口までなくすのではなく、編集画面を使えるようにし、必要でなければ通常の管理メニューへ出さないようにします。どの担当者がどの画面から入るかを手順書へ残しておけば、制作担当者だけが直接URLを知っている状態を避けられます。

反対に、記事や実績のように読者へ公開する投稿タイプでも、管理画面のメニュー構成まで自動で正しいとは限りません。日常的に更新する人が一覧へ入れるか、新規追加した投稿が意図したtemplateで表示されるか、サイトのnavigationへ誤って追加できないかを別々に確認します。公開用か非公開かという一語では、運用の入口を決められません。

URLを手入力して使っている処理を先に探す

4.4の変更で困りやすいのは、メニューに出ない投稿タイプを、担当者だけが直接URLで開いている場合です。外部制作会社が作った管理画面、社内で共有したブックマーク、プラグインの案内文、手順書などに、edit.php?post_type=...や投稿編集画面のURLが残っていることがあります。

更新前に、独自投稿タイプごとに次を確認します。

  1. show_uiの値と、管理メニューへの表示を確認する。
  2. 一覧と編集画面を、メニューからと直接URLの両方で開く。
  3. 投稿を一件だけ新規作成または更新し、保存後に一覧へ戻れるかを見る。
  4. テーマやプラグインがその投稿タイプのデータを表示、送信、集計している場合は、一件の値で結果を確認する。
  5. 直接URLが使えなくなるなら、担当者がどの画面から入るかと、必要な設定変更を記録する。

手順書にURLを書いてあるからといって、その画面が現在も許可されているとは限りません。更新後に「メニューから見えないのでデータが消えた」と判断する前に、投稿タイプの設定と編集画面の入口を確認します。画面が見えないことと、データが削除されたことは別です。

確認用には、公開しない内容を含まないテスト投稿を一件使います。管理画面で保存できたこと、一覧で見つかること、担当者の権限で編集できること、公開側へ意図しないURLが出ていないことを順に見ます。更新作業と同時に実データを大量に編集すると、設定が原因の表示不良と、内容の変更による違いを分けにくくなります。まず一件で入口と保存を確かめ、その後に通常の更新へ戻します。

非公開データは見えないことより、扱う人を決める

非公開の投稿タイプでは、メニューを隠すことが目的になりがちです。しかし、問い合わせ、予約、会員情報のように内容そのものが重要なデータなら、誰が確認し、どこで更新し、作業を引き継いだ後にどのアカウントで入るかを決める方が先です。メニューを隠しても、権限が広すぎれば情報を守れません。反対に、権限を絞っても、担当者が必要な画面へ入れなければ運用が止まります。

制作を委託する場合は、投稿タイプの登録コードだけでなく、show_ui、メニュー表示、更新担当、公開範囲、使う画面を一覧で受け取ります。設定を作った人と、日常的に入力する人が違っても、入口と権限が分かれば引き継げます。

最初の一手は、独自投稿タイプを一つ選び、公開先、編集担当、管理画面の入口を三行で書き出すことです。直接URLに頼っているなら、4.4へ更新する前にshow_uiとメニュー設定を決めます。

戻る