WPC Linked Variation 更新で管理画面の依存スクリプトエラーを修正する方法
WooCommerceの商品バリエーションを扱うプラグイン「WPC Linked Variation」（WooCommerce用）を使っていると、管理画面のあらゆるページで「依存関係にあるスクリプトが登録されていません」という警告が表示される場合がある。これはバージョン4.4.3以前の不具合であり、最新版4.4.4以降へアップデートすればすぐに消える。
エラー「正しく呼び出されていません」の中身と発生原因
管理画面の任意のページで、「依存関係 wc-enhanced-select, selectWoo が登録されていない」という警告が表示される
プラグイン更新後、または正しい画面チェック付きで読み込まれれば警告は消え、管理画面がすっきりする
上記のようなデモの流れで、管理画面の上部やQuery Monitorに突然エラーが出現する。
WooCommerceは商品編集画面や注文編集画面といった限定された管理ページにのみ、wc-enhanced-selectやselectWooといった選択UIを拡張するためのスクリプトを登録している。ところがWPC Linked Variation 4.4.3は、admin_enqueue_scriptsアクションの中で画面を一切絞り込まずに、これらに依存するwpclv-backendを読み込もうとしていた。
その結果、WooCommerceがスクリプトを用意していない「割引プラグインの設定画面」や「ユーザープロフィール」など、まったく関係のないページで依存先が見つからず、WordPressが「WP_Scripts::add の呼び出しが正しくない」と警告を出す。フロントエンドの表示や動作には影響しないが、管理画面の見通しが悪くなり、Query Monitorなどのデバッグツールを使っていると特に目立つ。
プラグイン更新でエラーを消す手順
プラグイン一覧に更新通知が表示されない場合は、WooCommerce公式マーケットプレイスまたはCodeCanyonから最新版を手動でダウンロードし、FTP経由で上書きする方法もある。いずれの場合も、更新前に必ずサイト全体のバックアップを取得しておく。
バージョン4.4.4では、開発者がadmin_enqueue_scripts内に適切な画面チェックを実装し、WooCommerceの商品編集画面でのみ依存スクリプトを読み込むように修正された。そのため、他のプラグインの設定画面や投稿一覧などで無用な警告が出ることはなくなる。
すぐにアップデートできない場合の一時しのぎ
プロジェクトの都合ですぐにプラグインを更新できない場合、応急処置としてQuery Monitorを一時的に無効化するか、プラグインファイルを手動で編集する方法がある。後者は更新時に上書きされてしまうため、あくまで次のアップデートまでのつなぎと考えてほしい。
コードを直接修正する開発者向け手順
WPC Linked Variationのプラグインフォルダ内にある wpc-linked-variation.php を開き、admin_enqueue_scripts にフックしている関数を以下のように変更する。現在の管理画面オブジェクトを取得し、投稿タイプが product の場合だけスクリプトを読み込む条件を追加する。
// 修正前（問題のあるコード）
add_action('admin_enqueue_scripts', 'wpclv_enqueue_scripts');
function wpclv_enqueue_scripts() {
wp_enqueue_script('wpclv-backend', plugins_url('assets/js/backend.js', __FILE__), array('wc-enhanced-select', 'selectWoo'), WPC_Linked_Variation::VERSION, true);
}
// 修正後（画面チェックを追加）
add_action('admin_enqueue_scripts', 'wpclv_enqueue_scripts_fixed');
function wpclv_enqueue_scripts_fixed($hook) {
$screen = get_current_screen();
if ($screen && $screen->post_type === 'product') {
wp_enqueue_script('wpclv-backend', plugins_url('assets/js/backend.js', __FILE__), array('wc-enhanced-select', 'selectWoo'), WPC_Linked_Variation::VERSION, true);
}
}この修正により、商品の編集・新規追加画面でのみスクリプトが読み込まれ、それ以外の管理画面ではエラーが発生しなくなる。修正後は管理画面をリロードして警告が消えることを確認する。本体のアップデートが可能になった時点で、必ず公式の最新版に差し替えることを推奨する。
よくある質問
このエラーはサイトのフロントエンドに影響しますか
影響しない。あくまで管理画面内でQuery MonitorやWordPressのデバッグ表示が警告を出すだけであり、来訪者が見る商品ページやチェックアウト画面の動作は変わらない。
プラグインを更新する以外の簡単な対処法はありますか
Query Monitorプラグインを無効化すればエラー表示自体は消えるが、あくまで表示上の回避に過ぎない。管理画面のパフォーマンスや他のスクリプト競合のリスクが残るため、プラグイン本体の更新が確実な解決策になる。
ほかのプラグインでも同様の「正しく呼び出されていません」エラーが出ます
多くのプラグインが管理画面用のスクリプトを読み込む際、WooCommerceや他のプラグインが提供するライブラリを依存関係に指定することがある。読み込むページを限定していない場合、同様の依存エラーが発生する。該当プラグインの開発者に報告するか、バージョンアップ情報を確認するのが近道だ。
バージョン4.4.4に更新してもまだエラーが消えない場合は
まずブラウザキャッシュとWordPressのキャッシュ（サーバーキャッシュやプラグインキャッシュ）をすべてクリアする。それでも消えなければ、別のプラグインが同様の問題を起こしている可能性があるため、すべてのプラグインを一時停止し、一つずつ有効化して原因を特定する。WooCommerce本体も常に最新版に保つ。
この記事のポイント
- WPC Linked Variation 4.4.3以前に起因する管理画面のスクリプト依存エラー
- プラグインを4.4.4以降にアップデートすれば完全に解消する
- エラーはフロントエンドに影響せず、管理画面の表示だけの問題
- 応急処置としてQuery Monitor無効化やコード修正も可能だが、公式更新が最も安全
- 他プラグインでも同様の警告が起きる場合、画面チェックの有無を疑う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
埋め込みチャットでNS_ERROR_DOM_COEP_FAILEDエラーが出た時の直し方
サイトに埋め込んだ Teams やその他のチャットウィジェットをクリックした時に NS_ERROR_DOM_COEP_FAILED と表示されて開けない場合、サーバーが返している COEP（Cross-Origin Embedder Policy）ヘッダーが原因だ。htaccess で Cross-Origin-Embedder-Policy を credentialless に変更するか、不要なヘッダーであれば削除することで解決する。
NS_ERROR_DOM_COEP_FAILEDとは何か
COEP は「Cross-Origin Embedder Policy」の略で、ページが他オリジン（別ドメイン）のリソースを読み込む際のセキュリティルールを定める HTTP レスポンスヘッダーだ。このヘッダーが require-corp に設定されていると、埋め込む側のリソースすべてに CORP（Cross-Origin Resource Policy）ヘッダーが付与されていることをブラウザが要求する。
Teams のチャットウィジェットをはじめ、多くのサードパーティ製ウィジェットは自社の配信サーバーから JavaScript や画像を読み込むが、それらのリソースに CORP ヘッダーが付与されていないことが多い。結果としてブラウザが読み込みをブロックし、NS_ERROR_DOM_COEP_FAILED というエラーをコンソールに出力する。
このエラーは Firefox や Chrome などのモダンブラウザで発生し、ウィジェットのボタンは表示されるがクリックしてもチャット画面が開かない、または読み込み中のまま固まるといった症状が出る。
COEPヘッダーを require-corp で返している
配信する JS や画像に CORP ヘッダーが付いていない
NS_ERROR_DOM_COEP_FAILED を出力しウィジェットが開かない
この図のとおり、自サイトのサーバー設定と外部ウィジェットの配信仕様が噛み合わず、ブラウザが安全側に倒して読み込みを拒否するのが根本的な原因だ。
自サイトにCOEPヘッダーが設定されているか確認する手順
まずは自サイトが実際に COEP ヘッダーを返しているかどうかを確認する。ブラウザの開発者ツールを使えば数分で特定できる。
Chrome や Firefox の開発者ツールでレスポンスヘッダーを確認する
サイトの任意のページを開き、F12 キーで開発者ツールを起動する。NetWork タブを開いてページを再読み込みし、先頭のドキュメントリクエスト（多くの場合はページURLそのもの）をクリックする。Response Headers セクションに Cross-Origin-Embedder-Policy という項目があれば、その値が現在の設定だ。
値が require-corp になっている場合、厳格な制限がかかっている状態で、これがエラーの直接原因になる。値が credentialless であればクロスオリジンの埋め込みは許可されているため、別の要因を探す必要がある。ヘッダー自体が存在しない場合は、COEP 以外の原因（CORS 設定やウィジェット側のスクリプトエラーなど）を疑う。
セキュリティプラグインやCDNが自動付与しているケース
WordPress サイトの場合、セキュリティ系プラグインが HTTP レスポンスヘッダーを自動で追加していることがある。また Cloudflare などの CDN サービスを経由していると、CDN 側のセキュリティ設定で COEP ヘッダーが付与されるケースもある。
該当しそうなプラグインを一つずつ無効化してヘッダーの変化を確認するか、CDN の管理画面で「ヘッダー設定」や「セキュリティヘッダー」といった項目をチェックすると原因を絞り込める。
htaccessでCOEPヘッダーを修正してエラーを解決する
原因が COEP ヘッダーの require-corp 設定にあると特定できたら、htaccess ファイルを編集して修正する。Apache サーバーを使っている国内レンタルサーバーの大半は htaccess による上書きが可能だ。
上記 STEP 3 で追記するコードは以下のとおりだ。htaccess の末尾にこのブロックを追加する。
<IfModule mod_headers.c>
Header set Cross-Origin-Embedder-Policy "credentialless"
</IfModule>この設定により、COEP ヘッダーが credentialless モードに切り替わる。credentialless はクロスオリジンのリソース読み込みを許可しつつ、認証情報（Cookie や HTTP 認証）を送信しないモードだ。Teams のチャットウィジェットは認証に Cookie を使わず独自のトークンで認証するため、credentialless モードでも問題なく動作する。
COEPヘッダーを完全に削除する方法
セキュリティ上の要件が特にないサイトであれば、COEP ヘッダー自体を削除する選択肢もある。以下のコードを htaccess に追記すればヘッダーが除去される。
<IfModule mod_headers.c>
Header unset Cross-Origin-Embedder-Policy
</IfModule>どちらの方法を選ぶかはサイトのセキュリティポリシー次第だ。COEP ヘッダーが元々セキュリティプラグインや CDN の自動設定で付与されていたのであれば、credentialless への変更が無難だ。手動で require-corp を指定していた場合は、その意図を再確認した上で削除または変更を判断する。
htaccess編集後に変更が反映されない場合の確認ポイント
ファイルをアップロードしてもヘッダーが変わらない場合、mod_headers モジュールがサーバーで有効になっていない可能性がある。また、CDN を経由しているサイトでは CDN のキャッシュをパージしないと変更がすぐに反映されない。WordPress のキャッシュプラグインを使っている場合も、プラグインの設定画面からキャッシュを全削除する。
変更後は必ず開発者ツールの NetWork タブでレスポンスヘッダーを再確認し、Cross-Origin-Embedder-Policy の値が credentialless に変わっているか、ヘッダー自体が消えているかを検証する。
htaccessが使えないサーバー環境での対処法
Nginx を使っている VPS やクラウド環境では htaccess が使えない。また一部の共用サーバーでは mod_headers が無効化されている場合もある。そうしたケースでの対処法をまとめる。
Nginxの場合
Nginx の設定ファイル（nginx.conf またはサイト単位の conf ファイル）の server ブロック内に以下の行を追加する。
add_header Cross-Origin-Embedder-Policy "credentialless";記述後は nginx -t で設定ファイルの文法チェックを行い、問題がなければ nginx -s reload で設定を再読み込みする。sudo 権限が必要な操作のため、レンタルサーバーではサポートに依頼する必要がある。
CDNやWAFでヘッダーを操作する
Cloudflare を使っている場合、ダッシュボードの「ルール」から「HTTP レスポンスヘッダーを変更」ルールを作成し、Cross-Origin-Embedder-Policy を credentialless に上書きできる。サーバー側の設定を一切触らずに済むため、htaccess 編集に不安がある場合の現実的な代替手段になる。
PHPでヘッダーを直接出力する
WordPress のテーマの functions.php に以下のコードを追加する方法もある。テーマ更新時に消えないよう、必ず子テーマを使う。
function my_set_coep_header() {
header('Cross-Origin-Embedder-Policy: credentialless');
}
add_action('send_headers', 'my_set_coep_header');この方法はサーバー設定に依存せず、WordPress の仕組みだけでヘッダーを制御できる。ただし、テーマの functions.php を編集するため、誤った記述があるとサイトが表示できなくなるリスクを伴う。編集前に必ず functions.php のバックアップを取る。
よくある質問
COEPエラーは特定のブラウザだけに出るのか
Firefox と Chrome 系ブラウザ（Chrome、Edge、Brave など）で発生する。Safari は COEP への対応が遅れていたが、Safari 17.2 以降はサポートしている。ブラウザによってエラーメッセージの文言は異なるが、根本原因は同じ COEP ヘッダーだ。
WordPressのセキュリティプラグインが原因になることはあるか
ある。HTTP セキュリティヘッダーを自動付与する機能を持つプラグイン（セキュリティ全般を扱うプラグインやヘッダー専用プラグイン）が、COEP を含むヘッダーを一括で設定しているケースは多い。プラグインの設定画面で「セキュリティヘッダー」や「HTTP ヘッダー」項目を探し、COEP の値を変更または無効化する。
credentiallessとrequire-corpの違いは何か
require-corp は埋め込み先の全リソースに CORP ヘッダーを必須とする厳格モードだ。一方 credentialless は CORP ヘッダーなしでもクロスオリジン読み込みを許可するが、認証情報（Cookie など）は送信しない。Teams チャットのような独自認証を使うウィジェットでは credentialless で十分動作する。
埋め込みウィジェット側の設定で回避できるか
原則として難しい。COEP エラーは「読み込む側（自サイト）」の制限によって発生するため、ウィジェット提供元（Teams など）の設定で回避する手段はない。ウィジェット提供元が自社の全配信リソースに CORP ヘッダーを付与すれば解決するが、それを個別の利用者が依頼して実現するのは現実的ではない。
htaccess編集に自信がない場合はどうすればよいか
サーバーの管理画面からファイルマネージャーで操作する場合は、編集前に必ず htaccess をコピーしてローカルに保存する。ミスでサイトが表示できなくなったら、そのバックアップをアップロードし直せば元に戻る。どうしても不安な場合は、CDN のヘッダー変更機能や PHP の functions.php で対応する方法を検討する。
この記事のポイント
- NS_ERROR_DOM_COEP_FAILED はサーバーの COEP ヘッダーが require-corp の時に発生する
- Teams など多くの外部ウィジェットは CORP ヘッダーを返さないためブロックされる
- htaccess で COEP を credentialless に変更するかヘッダーを削除すれば解決する
- Nginx 環境や CDN 経由の場合は別の設定手順が必要になる
- 修正後は必ず開発者ツールでレスポンスヘッダーが変わったか確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.1ベータ公開、ノート機能の大幅強化とCSS不要のレスポンシブ編集
WordPress 7.1のベータ版が7月下旬に公開され、編集体験に大きな改善が盛り込まれた。ノート機能がチームでの共同編集に本格対応し、CSSを一行も書かずに端末ごとの見た目を調整できるようになる。正式版はWordCamp USが開催期間中の8月19日にリリースされる予定だ。
今回の目玉は「ノート機能の強化」「レスポンシブスタイリング」「ホバーやフォーカス状態の視覚編集」の3本柱である。さらに、かねてから要望の多かったタブブロックとプレイリストブロックが追加され、管理画面の使い勝手も向上する。テスト段階のため本番環境への適用は避ける必要があるが、正式版までに知っておきたいポイントを詳しく見ていこう。
ノート機能がチーム編集ツールに進化
WordPress 6.9で導入されたノート機能は、ブロック単位の簡素なコメント機能だった。WordPress 7.1ではそれが一変し、複数人でのフィードバックに耐える本格的なツールへと変わる。
@メンションで担当者を直接指名
ノートの入力欄で「@」を打ち込むと、サイトの共同編集者の一覧が検索候補として表示される。目的のメンバーを選択すれば、その人を指名したノートが作成される。これにより「この修正は誰に伝えればいいのか」という迷いがなくなり、チーム内でのやり取りが格段にスムーズになる。
インラインノートで誤解を減らす
これまでのノートはブロック全体に対してしか付けられなかったため、長文の中で「ここを直してほしい」と書いても具体的な箇所が伝わりにくかった。WordPress 7.1では、文章内の特定の語句や文を選択し、その部分だけにノートを付けられる。該当部分はハイライト表示されるため、どの言葉に対する指摘なのかが一目でわかる。WP Beginnerの記事でも「『この部分を言い換えてほしい』という指示が、長い段落の中のどの単語を指すのかを推測する必要がなくなった」と評価されている。
このように、修正箇所と指示がピンポイントで結びつくため、レビューにかかる時間が劇的に短縮される。
その他の改善点
- 同じブロックに対して複数のノートスレッドを立てられる。議題ごとに会話を分離できる
- ノート本文に太字、斜体、コード、リンク、絵文字を使ったリッチテキストが可能
- 長いノートは初期状態で折りたたまれ、サイドバーが散らからない
CSS不要のビジュアルスタイリングが編集画面で完結
WordPress 7.1で最もインパクトが大きいのが、レスポンシブデザインのビジュアル操作である。これまではスマホやタブレット用の見た目を調整するには、CSSメディアクエリを手書きするか、テーマの設定に頼るしかなかった。今回のアップデートで、ブロックエディタ上でプレビューを切り替えながら、直感的にスタイルを設定できるようになる。
端末別のスタイル設定
エディタ上部のプレビュー切り替えで「デスクトップ」「タブレット」「モバイル」を選択すると、以降のブロックスタイルの操作はその画面サイズにだけ適用される。たとえばモバイル表示を選んで見出しのフォントサイズを小さくすれば、実際のスマホでの表示だけが変わる。デスクトップ表示には影響しない。
さらに、ブロック設定パネルには、現在どの画面サイズを編集中かを示す小さなバッジが表示される。意図しない画面用のスタイルを上書きしてしまうミスを防げる。エディタキャンバス自体も、プリセットの3サイズに縛られず、横幅をドラッグして任意の幅での表示をリアルタイムに確認できるようになった。テーマがtheme.jsonで独自のブレイクポイントを定義していれば、その値に合わせたプレビューも可能である。
CSSを書く必要がなくなり、カスタマイズのハードルが大きく下がる。サイト全体に一括適用したい場合は、グローバルスタイルで設定し、変更内容を選択的にグローバルへ反映させることもできる。
ホバーやフォーカス状態も視覚的に編集
ボタンなどのブロックには新たに「状態」ドロップダウンが追加され、ホバー時やフォーカス時、アクティブ時の見た目をエディタ上で直接編集できる。背景色や枠線、テキスト色を状態ごとに変え、その場でプレビュー確認できる。これまではほんの小さな変更であっても、カスタムCSSを追加せざるを得なかったが、今後は組み込みのデザインオプションで完結する。
待望のタブブロックとプレイリストブロック
これまでプラグインで実装していたタブ切り替えのレイアウトが、ついにコアブロックとして導入される。また、音声ファイルをまとめて再生できるプレイリストブロックも新登場する。
タブブロック
商品の仕様、よくある質問、料金プランの比較など、情報をパネルで区切って見せたい場面で重宝する。クリックでパネルを切り替える形式で、長いページを避けたい場合に効果的だ。既存のプラグインで作成したタブは、自動的にはコアブロックに変換されないため、移行の際は手作業が必要になる点に注意しておきたい。
プレイリストブロック
複数の音声ファイルを一つのプレイヤーにまとめ、タイトルやアーティスト名、カバーアート、波形グラフィックとともに表示できる。ミュージシャンや教会、教育機関、ポッドキャスト運営者にとっては、エピソードをまとめて提供するのに理想的なブロックだ。WordPressだけで手軽に音声配信の体裁を整えられるようになる。
加えて、既存のブロックにも多くの改善が加わっている。背景グラデーションと画像の同時適用、テキストシャドウのtheme.json対応、HTMLブロック内でのブロックネストの編集、装飾画像をスクリーンリーダーに読み上げさせない設定、ショートコードのEmbedブロックへの自動変換、ColumnsやGalleryからのグリッドレイアウト変換、アイコンブロックの回転・反転・アイコンセット登録機能など、日常的な制作を後押しするアップデートが多数含まれている。
画像編集とメディア処理の刷新
WordPressに組み込まれている画像編集機能が大幅に変わる。従来の狭いインライン操作から、専用のモーダルウィンドウでの本格的な編集へと進化した。
専用の画像編集モーダル
画像ブロックの「切り抜き」ボタンを押すと、フルスクリーンに近い編集画面が開く。自由トリミング、アスペクト比のプリセット、回転・反転、メタデータの編集を一か所で行える。カバーブロックにも対応しており、背景画像をその場でトリミングできる。本格的な写真編集ソフトには及ばないものの、サイト運営者が日常的に行う作業としては十分な機能を備えている。
ブラウザで画像を前処理しHEICにも対応
WordPress 7.1では、画像のリサイズや圧縮、サムネイル生成の大部分を、アップロード前にブラウザが処理する仕組みが導入される。これにより、サーバーの負荷が大幅に減り、低スペックなホスティング環境でもアップロードエラーが起きにくくなる。
さらに、iPhone標準の画像形式であるHEICをはじめ、UltraHDR、AVIF、WebPといった最新フォーマットへの対応が強化される。これまではサーバー側のImageMagickのバージョンに依存してHEICの変換が失敗することがあったが、ブラウザが変換を担うことで環境を選ばずに済むようになる。なお、ChromeとEdgeではフル機能が利用でき、Safariでは一部がサーバー処理に委ねられ、Firefoxでは従来通りサーバー側で処理される。
アップロードの堅牢性と細かな改善
アップロード中にネットワークが切断されても、キューが自動で一時停止し、再接続後に中断したところから再開される。一括アップロード時には進行状況が表示される。このほか、投稿に添付された画像を自動で引っ張ってくる動的ギャラリーモード、投稿専用の「添付画像」セクションがインサーターに追加され、メディアライブラリは自動読み込みの無限スクロールに対応する。日々のメディア管理のストレスを確実に減らす改良が詰め込まれている。
管理画面と編集体験の快適化
WordPress 7.1では、編集画面と管理画面の連携を改善する数々の小さな改良も施されている。
管理ツールバーが常に表示される
ブロックエディタやサイトエディタで編集しているときも、管理ツールバーが非表示にならず、画面上部に固定される。これにより、作業中でもサイトの管理メニューに素早くアクセスできる。ツールバーそのものもデザインが整理され、戻るボタンがわかりやすい山形アイコンに変更され、サイトアイコンと丸いプロフィールアバターが表示される。アイコン類も旧来のDashiconsからモダンなSVGに置き換わった。もちろん、集中執筆モードではツールバーが隠れるため、文章だけに集中したい場合も安心だ。
コマンドパレットとアイデンティティ設定の進化
コマンドパレット（Ctrl+K / Command+K）は、最近使ったコマンド、一致する候補、おすすめの3つに分類されるようになった。利用履歴はログインをまたいで保存されるため、よく使う操作に素早くたどり着ける。サイトエディタのサイドバーも、ユーザーが選んだ管理画面のカラースキームを反映するようになり、全体的な統一感が増した。
サイトのタイトル、キャッチフレーズ、ロゴ、サイトアイコンといった基本情報は「デザイン」内の「アイデンティティ」セクションにまとめられ、設定画面とテンプレートを行き来する手間がなくなった。
「あの日何を書いたか」ウィジェットとコメント親変更
ダッシュボードに新たに「On This Day」ウィジェットが追加され、過去の同じ日に公開した記事を表示してくれる。長く続けているブログにとっては、更新のネタを見つけるきっかけになる。また、コメント編集画面では「どのコメントへの返信か」を後から変更できるようになり、誤って違うスレッドにぶら下がったコメントを正しい位置に付け替えられる。対象は同一投稿内に限られるが、コメント管理の柔軟性が向上した。
見送られた機能と開発舞台裏
今回のリリースには含まれなかったが、注目すべき開発項目がいくつかある。
リアルタイム共同編集は次期以降に持ち越し
Googleドキュメントのような複数人同時編集は、WordPress 7.1では搭載が見送られた。Gutenbergプラグイン上では既に動作しており、複数人が同じ投稿を同時に編集できる段階にある。しかし、コアチームは協調編集データの保存方法や、完全な機能を提供するか基盤だけを先にリリースするかといった重要な判断を続けている。コミュニティによるテストも継続中で、時期尚早な投入によるデータ消失リスクを避けるための慎重な判断と見られている。WP Beginnerの記事でも「作業内容を失う共同編集機能ほど最悪なものはない」と指摘されており、この慎重さは妥当だろう。
Unicodeメールアドレス対応も見送り
日本語などの非ラテン文字を含むメールアドレスへの対応も、ベータテスト中に課題が見つかり延期された。互換性とセキュリティの検証をコミュニティプラグインで続けた後、改めてコアへの導入を目指す方針だ。
パフォーマンスと開発者向けの内部改善
投稿エディタは常にiframe内で動作するようになり、管理画面のCSSによる表示崩れを根本的に防ぐ。ただし、旧APIで作られたブロックは影響を受ける可能性があるため、プラグイン開発者はBlock API v3への移行が推奨される。アイコンAPIが公開され、プラグインやテーマが独自のSVGアイコンセットを登録・レンダリングできるようになった。そのほか、デザインシステムの成熟や、外部サービス接続の認証方式拡充など、長期的な安定性と拡張性を見据えた改良も進められている。
この記事のポイント
- ノート機能に@メンションとインラインノートが追加され、チームでのフィードバックが格段に正確になった
- レスポンシブスタイリングとホバー・フォーカス状態の編集がCSS不要で行える
- タブブロックとプレイリストブロックがコアに加わり、コンテンツ表現の幅が広がった
- 画像編集モーダルとブラウザベースの画像処理で、メディアまわりの操作性と安定性が向上
- 管理ツールバーの常時表示やアイデンティティ設定の集約など、管理画面の使い勝手が改善された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressサイトがハッキングされた時の難読化PHPコードの見つけ方と完全駆除手順
WordPressサイトのindex.phpなどのコアファイルに難読化された悪意あるPHPコードが埋め込まれ、不審なサイトへリダイレクトされる被害が発生した場合、感染ファイルの完全削除とコアファイルの再インストール、全認証情報の変更を同時に進める必要がある。
この種の改ざんは「goto文」や16進数エンコードした文字列、外部サーバーとの通信機能などを使って巧妙に隠されている。残骸を残さず駆除し、再侵入経路をすべて塞ぐ手順を具体的に追っていく。
なぜWordPressサイトに難読化された悪意あるコードが仕込まれるのか
攻撃者が難読化コードを埋め込む目的は大きく3つある。不正なリダイレクトによるアフィリエイト収益の横取り、サイト訪問者の個人情報やパスワードの窃取（フィッシング）、そしてサイト自体を踏み台にして別のサーバーを攻撃するスパム配信やDDoS攻撃の中継だ。
コードの難読化は、セキュリティプラグインや手動の目視検査をすり抜けるために施される。変数名や関数名をランダムな文字列にし、goto文で処理の流れを複雑に飛ばすことで、実際に何を実行しているのかを読み取りにくくしている。この手のコードは、単独のファイルに留まらず、複数のテーマファイルやアップロードディレクトリに分散して設置されることが多い。
- ● トップページが別ドメインにリダイレクトされる
- ● index.phpの先頭に見慣れない
goto文や16進数文字列のブロックがある - ● 管理画面が重くなり、プラグインの一覧に覚えのない項目が増えている
- ● サイトのURLが正しく表示され、意図しない転送が発生しない
- ● コアファイルが公式のチェックサムと完全一致する
- ● 管理者アカウントやプラグインに不審な追加がない
上記の例は、攻撃者が検索エンジンのボットを判別し、Googleなどのクローラーには元の正常なページを見せ、一般の訪問者だけに不正サイトへ飛ばす「クローキング」という手法の典型的な挙動を示している。
感染したWordPressサイトを手動で完全に駆除する手順
感染が疑われるファイルとディレクトリを優先して検査する
改ざんされたコードは、WordPressのルートディレクトリ直下のindex.phpやwp-config.phpだけでなく、テーマやプラグインのディレクトリ、アップロードディレクトリにも潜む。次の場所を重点的に確認する。
- ルートディレクトリの全
.phpファイル（index.php、wp-load.php、wp-settings.phpなど） /wp-content/themes/配下の全テーマ（特にアクティブなテーマのfunctions.php）/wp-content/plugins/配下の全プラグインファイル/wp-content/mu-plugins/（もし存在すれば）/wp-content/uploads/配下のPHPファイル（本来PHPファイルが存在すべきではないディレクトリ）/wp-includes/配下のコアファイルの改ざん有無（後述のチェックサム検証で判別可能）.htaccessファイル（リダイレクトルールや不正なコードブロックが追記されていないか）
WordPressコアファイルの再インストールとチェックサム検証
wp-content ディレクトリと wp-config.php を除き、WordPressのコアファイルをすべて公式の配布ファイルで上書きするのは安全かつ最も確実な駆除方法だ。管理画面の「ダッシュボード」→「更新」から「再インストール」を実行するか、手動で行う場合は次の手順を踏む。
wp-content ディレクトリと wp-config.php をローカルにバックアップ（退避）するwp-admin と wp-includes を完全に削除し、展開した公式ファイルの同名ディレクトリをアップロード.php ファイル（wp-config.php を除く）を公式ファイルで上書きwp-content と wp-config.php をサーバーに戻し、wp-config.php に手動で追記された不正な行がないか目視確認wp-includes/version.php を確認し、バージョン番号が正しいか検証。その後、プラグイン「WordPress Core Verify」などでチェックサムを検証する管理画面にアクセスできるなら「ダッシュボード」→「更新」の「WordPressを再インストール」ボタンを押すだけで同等の処理が完了する。手動で行う場合も、wp-content と wp-config.php を保護している限り、データ消失の心配はない。
感染源を特定するためにサーバーログとタイムスタンプを照合する
どの脆弱性から侵入されたかを特定するには、改ざんされたファイルのタイムスタンプとサーバーのアクセスログ、エラーログを突き合わせる。ログに「POST /wp-admin/admin-ajax.php」や「POST /xmlrpc.php」への不自然な連続リクエストが記録されていれば、ブルートフォース攻撃やXML-RPCを経由した侵入が疑われる。
ホスティングのコントロールパネルから「Raw Access Logs」や「エラーログ」をダウンロードし、改ざん発生日時の前後を中心に調べる。プラグインやテーマのアップデートを長期間放置していた場合は、脆弱性情報データベース（CVE）で該当バージョンの既知の脆弱性を検索し、侵入経路の仮説を立てる。
適切なファイルパーミッションに設定し直す
ディレクトリは755、ファイルは644を基本とし、wp-config.phpだけは440または400に設定して読み取り権限を厳格にする。特にwp-content/uploads/ 配下にPHPファイルが置かれている場合は、そのディレクトリでPHPの実行を.htaccessで明示的に拒否しておくべきだ。
# .htaccess を wp-content/uploads/ に設置する場合
<FilesMatch "\.(php|php\.)$">
Require all denied
</FilesMatch>プラグインとテーマをクリーンな状態に置き換える
すべてのプラグインとテーマを、公式ディレクトリまたは購入元から再ダウンロードした完全に新しいファイルで上書きする。非公式サイトから入手したプラグインやテーマ、長期間更新が止まっているものは、この機会に削除するか代替に切り替える。
とくに mu-plugins ディレクトリは、手動で設置しない限り通常は存在しない。見慣れないディレクトリ名やPHPファイルがあれば、即座に削除する。
データベース内の不正なコードや管理者アカウントを検査する
phpMyAdminやWP-CLIを使って、wp_options テーブルの「siteurl」や「home」、wp_posts の投稿内容に不審なスクリプトタグやiframeが埋め込まれていないかを調べる。同時に、wp_users テーブルで身に覚えのない管理者アカウントが追加されていないかも必ず確認する。
データベース内の隠し管理者を一括で探すには、WP-CLIで次のコマンドを実行すると早い。
wp user list --role=administrator全認証情報を変更しセキュリティキーを再生成する
駆除作業が完了したら、WordPress管理画面の全ユーザーパスワード、データベースパスワード、SFTP/SSHパスワード、ホスティングのコントロールパネルパスワードをすべて変更する。wp-config.php の「AUTH_KEY」「SECURE_AUTH_KEY」などのセキュリティ用ソルトも、WordPress.orgの公式ソルト生成ツールで新しいものに置き換える。
よくある質問
クリーンなバックアップがない場合、復旧の優先順位はどう決めればよいか
バックアップが存在しない、またはバックアップ自体が感染後のものである場合は、コアファイルの再インストールとプラグイン・テーマの全置き換えを最優先する。データベースの修復はその後で、不正な投稿やユーザーを手動で削除する。サイトのダウンタイムを最小限にするため、メンテナンスモードを有効にして作業するのが安全だ。
無料のプラグインやテーマが感染の原因になることはあるか
公式ディレクトリで配布されている無料プラグインでも、深刻な脆弱性が発見されて更新が滞れば攻撃の糸口になりうる。とくに、公式ディレクトリ以外のサイトから配布されている「nulled（クラック）」版の商用プラグインやテーマは、ほぼ確実にバックドアが仕込まれているため、絶対に使用してはいけない。
データベースを直接編集する際の注意点は何か
phpMyAdminなどでデータベースを直接操作する場合は、必ず事前にデータベース全体のダンプ（エクスポート）を取っておく。wp_options テーブルの「active_plugins」行を誤って削除すると全プラグインが無効化されるため、行の値を直接編集するよりも、WP-CLIのwp optionコマンドを使うほうが安全に操作できる。
cronジョブに疑わしいタスクが仕込まれていないか調べる方法は
WordPressの疑似cron（WP-Cron）はwp_options テーブルの「cron」オプションに格納されている。WP-CLIでwp cron event listを実行すると登録されている全タスクを一覧できる。ホスティング側の本物のcronジョブ（crontab）に不正なエントリが追加されていないかも、ホスティングの管理画面またはSSHで確認する。
攻撃者に検索エンジンのボット判定をすり抜けられた場合の追加対策は
難読化コードがボット判定を行っている場合、駆除後もクローキング用のキャッシュがCDNや検索エンジンに残っている可能性がある。サイト駆除後にGoogleサーチコンソールで「URL検査」→「インデックス登録をリクエスト」を実行し、CDNの全キャッシュをパージする。HTTPヘッダーを改ざんされていないかも、curlコマンドなどで確認しておくべきだ。
この記事のポイント
- 難読化PHPコードは複数ファイルに分散して設置されるため、ルート直下、テーマ、プラグイン、アップロードディレクトリをすべて検査する
- WordPressコアファイルは
wp-contentとwp-config.phpを保護したうえで公式ファイルで完全に上書きする - 改ざんファイルのタイムスタンプとサーバーログを照合し、侵入経路を特定して永続的な対策を講じる
- 全認証情報の変更とソルトの再生成を駆除と同時に行い、再侵入を防ぐ
- クリーンなバックアップがある場合は、全ファイルとデータベースの削除後にバックアップから復元するのが最も確実な方法である
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.0でAIプラグインを作る！Abilities APIとAI Client連携の実際
WordPress 7.0から導入された3つのAI関連コンポーネント、Abilities API、AI Client、そしてMCP Adapterがプラグイン開発の風景を大きく変えようとしている。これらを組み合わせると、AIが画像を解析し、自動で記事を生成するプラグインを驚くほど少ないコードで実装できる。
本記事では、実際に「Photo to Post」というプラグインの構築を通して、各APIの役割と連携方法を具体的に解説する。WordPressの管理画面から画像URLを入力するだけで、AIがビジョンで内容を理解し、下書き投稿を自動生成する流れを追いながら、新しい開発スタイルの全体像をつかんでほしい。
情報源はWordPress Developer Blogのチュートリアル「Build your first AI-Powered WordPress plugin」（2026年7月30日公開）だ。ここで示されるコードと設計思想は、今後のWordPressエコシステムにおけるAI統合の方向性を色濃く反映している。
新しいAI開発基盤の3要素
WordPress 6.9以降で整備されたAbilities API、7.0で正式に取り込まれたAI Client、そしてMCP Adapterは、それぞれ独立して使えるが、組み合わせることで真価を発揮する。まずはこの3つの役割を押さえておく。
Abilities API
Abilities APIは、プラグインが提供する機能を「能力」として登録し、REST APIやAIエージェントなどが統一された方法で発見・実行できる仕組みだ。入力スキーマ、出力スキーマ、パーミッションコールバック、そして実処理を行うコールバックを定義する。これにより、従来のようにエンドポイントを個別に実装する手間が省け、一度登録した能力が管理画面・REST・MCP経由でそのまま利用可能になる。
WordPress AI Client
AI Clientは、プロバイダー（OpenAI、Anthropic、Googleなど）に依存しないPHPライブラリだ。プラグインコードはwp_ai_client_prompt()というフルーエントなビルダーでプロンプトを組み立て、テキスト生成やファイル送信を依頼するだけでよい。プロバイダーの切り替えは管理画面のConnectors API（後述）でAPIキーを設定するだけで済み、コードを一切変更する必要がない。
MCP Adapter
MCP（Model Context Protocol）は、AIエージェント（デスクトップアプリやVS Code拡張など）が外部ツールを呼び出すための標準プロトコルだ。MCP Adapterプラグインをサイトにインストールすると、登録したAbilityがMCPツールとして自動公開される。ClaudeやChatGPTなどのAIクライアントにWordPressの機能を認識させ、「この画像から投稿を作成して」と自然言語で指示するだけで、プラグインの能力が裏側で呼び出される。
同じ能力が3つの入口からシームレスに使える
上の図はAbilities APIの最大のメリットを示している。一度登録すれば、UI、REST、AIエージェントのどこからでも同一の能力を実行できる。エンドポイントごとに別の処理を書く必要はない。
プラグイン「Photo to Post」の仕組み
チュートリアルで構築する「Photo to Post」は、画像URLを入力するとAIが画像の内容を解析し、その説明文をもとにブログ投稿用のタイトルと本文を生成、さらにその画像をアイキャッチに設定した下書き投稿を作成するプラグインだ。
内部では、3つのAbilityが連携している。ここで重要なのは、最後の能力が他の能力を呼び出す「能力の合成（composition）」を実践している点だ。
この合成パターンは、WordPressのフィルターフックやアクションフックで築かれた「小さな機能を組み合わせて大きな機能を作る」という哲学のAI時代バージョンといえる。
実装の流れを追う
ここからはチュートリアルの主要な実装ステップを、要点を絞って解説する。すべてのコードはスタータープラグインをベースにしており、TODOコメントを置き換える形で進められる。AIプロバイダーとしてはOpenAI、Anthropic、Google Geminiなどが利用可能だ。
AIプロバイダーとの接続
WordPress 7.0では、設定メニューに「コネクター」画面が追加された。Connectors APIによって、各プラグインはAPIキーの保存場所を一元管理できる。従来はプラグインごとに設定ページでキーを管理する必要があったが、これで1箇所に集約される。
OpenAI、Anthropic、Googleの公式プロバイダープラグインをインストールし、コネクター画面でAPIキーを登録すれば、あとはAI Clientが自動的にそのプロバイダーを使う。ビジョンモデルを使う場合は、Anthropicのように画像をBase64で送る必要があるが、AI Clientが吸収するためコード上の差異はほとんど生じない。
能力の登録
Abilities APIにおける能力の登録は、wp_register_ability()関数にラベル、説明、入出力スキーマ、パーミッション、コールバックを渡すだけだ。ここで定義したスキーマが、RESTやMCP経由で能力を呼び出す際の「説明書」になる。
チュートリアルでは、describe-image（画像URL → テキスト説明）、generate-post-from-description（説明文 → 投稿タイトルと本文）、create-post-from-photo（画像URL → 下書き投稿）の3つを登録する。
能力を登録したら、wp_abilities_api_initアクションにフックし、RESTで表示するためにメタ情報にshow_in_rest => trueを指定する。これだけでアプリケーションパスワードを使ったcurlで能力の一覧を取得できる。
AI Clientによる画像解析とテキスト生成
最初の能力describe-imageのコールバックでは、wp_ai_client_prompt()でプロンプトを構築し、with_text()とwith_file()で画像のデータURIを渡してgenerate_text()を呼ぶ。戻り値はWP_Errorの可能性があるため、必ずチェックする。
画像はwp_remote_get()で取得しBase64エンコードしたデータURIにして送る。これにより、URLでの画像指定を受け付けないプロバイダーでも動作する。
2つ目の能力generate-post-from-descriptionでは、AIに「画像説明文から魅力的なブログ投稿を生成し、JSONで返す」よう指示する。プロンプトには「markdownコードフェンスで囲まない」と明示するが、AIは非決定論的なため、念のためpreg_replace()でフェンスを除外し、JSON文字列の中からオブジェクトを抽出する防御的なパース処理を入れている。
能力の合成
3つ目の能力create-post-from-photoがこのプラグインの心臓部だ。ここでwp_get_ability()を使って自分自身以外の能力を取得し、execute()で実行する。最初にdescribe-imageを実行して画像説明を取得し、次にその説明を使ってgenerate-post-from-descriptionを実行、最後に得られたタイトルと本文からwp_insert_post()で下書きを作成する。
このように、能力を「LEGOブロック」のように組み合わせられることがAbilities APIの真骨頂だ。各能力は単独でテスト可能であり、後から新しい能力を追加して組み合わせることも容易である。
管理画面の拡張
スタータープラグインに付属するDataFormベースの設定画面を、実際の能力と連携させる。JavaScript側からは@wordpress/abilitiesパッケージのgetAbility()とexecuteAbility()を使い、先ほどPHPで登録したcreate-post-from-photo能力を呼び出す。
スクリプトをモジュールとして読み込み、readyプロミスでAPIが利用可能になるのを待ってから実行する。これで管理画面から画像URLを入力し「投稿を生成」ボタンを押すだけで、一連のAI処理が走り、下書きが作成される。成功すると編集画面へのリンクが表示される。
MCP対応でAIエージェントにも開放
能力の登録時にメタに'mcp' => array( 'public' => true )を追加し、MCP Adapterプラグインを有効化するだけで、その能力がMCPサーバー経由で外部AIエージェントに公開される。
例えばClaudeデスクトップアプリの設定ファイルにWordPressサイトのURLとアプリケーションパスワードを記述すれば、「この写真から投稿を作成して」と話しかけるだけで、create-post-from-photoが自動的に呼ばれる。REST、管理画面、MCPという3つの入口を同じコードで実現できるのは、Abilities APIの設計の妙だ。
実装から見える将来性
WordPressのコアに組み込まれたこれらAIビルディングブロックは、単なる補助機能ではない。プラグイン開発のパラダイムを「単一の機能提供」から「再利用可能な能力の提供と合成」へとシフトさせる可能性を秘めている。
さらに、Connectors APIによるAPIキーの一元管理は、複数プラグイン間の設定のばらつきを解消し、サイト管理者の負担を大きく下げる。開発者は「どのAIモデルを使うか」を気にせず、ビジネスロジックに集中できる環境が整いつつある。
注意点として、AI呼び出しには時間がかかるため、デフォルトのHTTPタイムアウトでは処理が中断される可能性がある。チュートリアルではwp_ai_client_default_request_timeoutフィルタでタイムアウトを120秒に延長する対処が示されている。このような実運用の勘所も押さえておきたい。
プラグイン開発者がこうした基盤を活用し始めれば、WordPressエコシステム全体のAIリテラシーが一気に加速する。非エンジニアでも「写真から投稿を作って」と指示するだけでコンテンツ制作が進む未来は、すぐそこまできている。
この記事のポイント
- WordPress 7.0のAbilities API・AI Client・MCP Adapterにより、AI搭載プラグインを少ないコードで構築できる
- 能力を1回登録すればREST・管理画面・AIエージェントの3経路で同一機能を提供可能
- AI Clientはプロバイダー非依存で、Connectors APIがAPIキー管理を集約
- 能力の合成で「LEGOブロック」のように複雑な自動化を実現
- 実運用ではタイムアウト延長フィルタなど、実装上の注意点も必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
決済手数料プラグイン更新後に商品ページがエラーで崩れる場合の対処法
WooCommerce サイトで Payment Gateway Based Fees and Discounts といった決済手数料プラグインをバージョン 3.2.0 に更新した直後から、商品ページを開くと「このサイトで重大なエラーが発生しました」と表示され、レイアウトが中央に縮まってしまう症状が起きた。このケースはプラグイン内部のクラス読み込み不具合が原因であり、該当プラグインを安全な旧バージョンにロールバックすれば即座に解決する。
なぜプラグイン更新後に商品ページが重大エラーになるのか
エラーログには「Uncaught Error: Class “TycheSoftwares\PaymentGatewayFees\Lite\WC_Tax” not found」というメッセージが記録されている。これは、プラグインのアップデートで参照している PHP クラスが適切に読み込まれていないことを示す。WooCommerce 本体やほかのプラグインとの同時アップデートが引き金になることもあるが、切り分けテストで当該プラグインを無効化すると正常に戻るなら、原因はそのプラグインの新バージョンにあると断定できる。
エラーを安全に切り分ける手順
問題が発生したら、むやみに設定を触らず、まず以下の手順で原因を特定する。同時にアップデートしたプラグインが複数ある場合も、この順序で一つずつ無効化していくと確実だ。
上記の操作は管理画面にアクセスできない場合でも使える。プラグインを無効化するだけなら、PHP の動作を変更しないため、エラーが解消された後に管理画面から安全にアンインストールや再インストールが可能だ。
旧バージョンにロールバックしてサイトを元に戻す
原因が特定できたら、問題のない旧バージョンに置き換える。ロールバックの方法は大きく分けて3つある。状況に応じて選ぶとよい。
プラグイン「WP Rollback」を使って管理画面から戻す
WordPress 管理画面にアクセスできる状態なら、無料プラグインの WP Rollback をインストールすると、プラグイン一覧から直接任意の旧バージョンに切り替えられる。操作は数クリックで完了し、面倒なファイル操作が不要なため最も簡単だ。ロールバック後は念のためキャッシュを全削除し、エラーが出なくなったことを確認する。
公式 ZIP ファイルを手動でアップロードする
管理画面に入れない場合は、WordPress 公式プラグインディレクトリの旧バージョン ZIP を直接ダウンロードし、FTP やサーバーのファイルマネージャーで上書きする。対象プラグインの開発者ページにアクセスし、右下の「Advanced View（詳細を表示）」から目的のバージョンを選んで ZIP を取得する。その後、/wp-content/plugins/ ディレクトリに解凍して配置すれば完了だ。このとき、既存のプラグインフォルダは必ずリネームしてから新しく解凍するか、上書きする前にバックアップを取っておく。
WP-CLI でコマンド操作する
サーバーに SSH 接続できる上級者向けの方法だ。WP-CLI が使える環境であれば、以下のようなコマンドでプラグインをダウングレードできる。公式 ZIP の URL を指定してインストールし、有効化するだけだ。
wp plugin install https://downloads.wordpress.org/plugin/checkout-fees-for-woocommerce.3.1.0.zip --activateロールバック後は自動更新を一時的に停止し、修正版がリリースされるまでバージョンを固定することを推奨する。 具体的には、プラグイン編集画面か wp-config.php で該当プラグインの自動更新フィルターを無効化するか、プラグイン一覧から手動更新に切り替えておく。
開発者が修正するまでに取るべき応急処置
問題のバージョンに致命的な不具合がある場合、修正版がリリースされるまでは旧バージョンでの運用が必須だ。その間、以下の点に気をつける。
- サポートフォーラムや公式リポジトリを定期チェックする。 同じ不具合が報告され、ベータ版や修正版が先に出ることがある。
- ステージング環境で新バージョンを検証する。 いきなり本番環境に適用せず、テストサイトで動作確認してから更新する習慣をつける。
- WooCommerce 本体と関連プラグインの同時更新を避ける。 依存関係の競合を避けるため、数日ずらして様子を見ながら更新するのが安全だ。
よくある質問
エラーログの確認方法がわからない
サーバーコントロールパネルのエラーログ機能を使うか、wp-config.php に define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); を追記すると、/wp-content/debug.log にエラーが記録される。本番環境ではデバッグ表示を無効にしておき、ログだけ有効にする設定が推奨される。
ロールバック中に「インストールに失敗しました」と出る
多くの場合、既存のプラグインフォルダが残っていることが原因だ。FTP で対象フォルダを削除またはリネームし、空の状態にしてから ZIP を解凍するか、WP Rollback が自動で処理するのを待つ。
プラグインを無効化すると手数料計算が狂わないか
決済手数料を動的に追加しているサイトでは、プラグインを無効化すると手数料が適用されなくなる。ロールバックが完了するまでの間は手数料の表示が消えることを顧客に通知するか、保守モードを有効にして注文自体を一時停止する判断も必要だ。
今後同じようなアップデート事故を防ぐには
WooCommerce サイトでは、本番適用前にステージング環境でプラグインの更新テストを行うのが最も確実な防止策だ。また、更新前に必ずサイト全体のバックアップを取得し、自動更新設定を重要なプラグインでは「手動」に切り替えておくことも有効である。
この記事のポイント
- Payment Gateway Based Fees and Discounts 3.2.0 の更新後、クラス未定義エラーで商品ページが崩れる
- 原因はプラグイン内部のクラス読み込み不具合で、同プラグインを旧バージョン（3.1.0）に戻せば直る
- ロールバックには WP Rollback プラグインか、公式 ZIP を手動アップロードする方法が使える
- 修正版が配布されるまでは自動更新を停止し、本番環境での同時更新を避ける
- 更新前のステージング環境テストとサイト全体のバックアップが最も有効な予防策
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
プラグイン更新後に WordPress ログイン不能になる「Cookie がブロックされました」エラーの直し方
CF7 Google Sheet Connector バージョン 5.2.1 へのアップデート直後から、WordPress の管理画面にまったくログインできず、ログインページで「Cookie は予期しない出力のためにブロックされました」というエラーが表示されるなら、直接の原因はそのプラグインの不具合にある。FTP を使ってプラグインフォルダをリネームし、強制的に無効化すればログイン機能をすぐに回復できる。
プラグイン更新後に WordPress へログインできなくなる根本原因
WordPress のプラグインやテーマは、PHP の開始タグを閉じずにファイルを記述するのが一般的だ。しかし、何らかの原因でファイルの末尾に余分なスペースや空行が紛れ込んだり、意図しない echo や print が実行されたりすると、WordPress 本体が HTTP レスポンスを送信する前に「予期しない出力」が生まれる。
この予期しない出力は、ログイン機能で使われるセッション Cookie や setcookie() 関数の動作を妨げる。PHP は一度でも出力が行われると、後から HTTP ヘッダーを書き換えられないため、WordPress が正しく Cookie を発行できなくなり、結果として「重大なエラー」画面や「Cookie は予期しない出力のためにブロックされました」というエラーメッセージを返すようになる。
このデモが示すのは、問題のプラグインが WordPress のログインプロセスに割り込んでしまう仕組みだ。CF7 Google Sheet Connector 5.2.1 をはじめ、ごく一部のバージョンでこの現象が発生するケースが海外フォーラムでも報告されている。根本的には、プラグイン開発者が PHP ファイルの末尾やインクルード処理に余計な出力を残してしまうヒューマンエラーに起因する。
「Cookie がブロックされました」はなぜ起こるのか── unexpected output の詳細
「Cookie は予期しない出力のためにブロックされました」は、WordPress のログイン時でなくても、プラグインの有効化画面で「このプラグインは有効化中に 3 文字の予期しない出力を生成しました」といった警告文とともに現れる。この警告は、まさに PHP が <?php の開始タグよりも前やファイル末尾に余計な空白文字を出力している証拠だ。
コンタクトフォームの送信自体は成功し、Google スプレッドシートへのデータ転送も動いているのに、ログインだけが機能しなくなるのは、フォーム送信とログイン認証で通る PHP の実行経路が異なるためだ。フォーム送信時にはセッション Cookie を新たに発行する必要がないため、表面上は問題が表面化しにくい。しかし wp-login.php や管理画面の認証周りでは、必ず Cookie のセットが行われるので、エラーが必ず検出される。
FTP で問題のプラグインを無効化する具体的な手順
管理画面にログインできない状態では、ブラウザ上の操作だけではプラグインを停止できない。ここで必要なのが、契約しているレンタルサーバーの FTP アカウントを使った直接のファイル操作だ。FTP クライアントやサーバー管理画面のファイルマネージャー機能を利用して、次の手順を実行する。
/wp-content/plugins/ ディレクトリに移動するcf7-google-sheet-connector）を探し、リネームする（末尾に _disable などをつける）/wp-admin/ にアクセスし、通常通りログインできるか確認するリネームはフォルダ名の先頭や末尾に「_」を付けるだけでも十分であり、WordPress がそのプラグインを認識できなくなる。ログインが回復したら、管理画面の「プラグイン」一覧から、無効化された状態の当該プラグインを確認できる。ここで「削除」を選べば、問題のバージョンは完全に取り除かれる。
プラグインを以前のバージョンに戻して再発を防ぐ
CF7 Google Sheet Connector を使い続ける必要があるなら、安定していた旧バージョンに戻すか、開発元が修正パッチを公開するのを待つことになる。WordPress 管理画面からプラグインを再インストールする際は、あえてバージョン 5.2.1 を避け、プラグインページ下部の「以前のバージョン」セクションや、WP Rollback のようなロールバック専用プラグインを使って前のバージョンにダウングレードできる。
また、問題が発生したプラグインをどうしても最新で使い続けたいのであれば、プラグインのサポートフォーラム（WordPress.org 内）で「バージョン 5.2.1 で unexpected output が発生しログイン不能になる」という事象を報告し、修正を促すのが建設的だ。開発者が原因を把握すれば、比較的早期に新しいバージョンがリリースされる可能性が高い。
よくある質問
FTP アカウント情報がわからない場合はどうすればいいか
契約しているレンタルサーバーの管理画面（コントロールパネル）に、FTP アカウントの設定やファイルマネージャー機能が用意されているケースが多い。cPanel なら「FTP アカウント」メニューから新規作成やパスワード再設定が可能だ。サーバー会社のサポートに問い合わせれば、FTP 接続情報を再発行してもらえることもある。
プラグインを無効化してもログインエラーが直らない
同様の症状が他のプラグインやテーマでも発生する可能性がある。全プラグインを無効化し、標準テーマ（Twenty Twenty-Five 等）に切り替えた状態で症状が消えるかどうかを確認する。それでも直らない場合は、サーバーの PHP エラーログを調べ、別の致命的エラーが起きていないか検証する必要がある。
プラグインの更新を止める方法はあるか
WordPress の標準機能では特定プラグインの自動更新だけを選択的に止めることはできないが、プラグイン「Easy Updates Manager」を使うと、プラグイン単位で自動更新を無効化できる。問題のあるバージョンを避けつつサイトを安全に保つには、ステージング環境で事前に更新テストを行うのが最も確実だ。
フォームのデータが送信されていれば問題ないのか
フォームが動いているからといって放置するのは危険だ。ログイン不能はサイト全体の管理を妨げるだけでなく、同じ予期しない出力が他の機能（RSS フィードや REST API）にも影響を及ぼす恐れがある。できる限り早急に原因のプラグインを停止し、サイト全体の健全性を取り戻す必要がある。
プラグインを手動で削除してもデータは残るのか
CF7 Google Sheet Connector の場合、コンタクトフォームの設定や Google スプレッドシートとの認証情報はデータベースに保存される。そのため、プラグインフォルダを削除しても設定情報は消えない。再度同じプラグインをインストールすれば、以前の連携設定を引き継げる可能性が高いが、念のためデータベースのバックアップを取ってから削除するのが安全だ。
この記事のポイント
- CF7 Google Sheet Connector 5.2.1 では unexpected output によりログイン不能になる不具合が報告されている
- 「Cookie がブロックされました」は PHP の予期しない出力が原因で、FTP を使ったプラグイン無効化で回復する
- 管理画面にログインできなくても、FTP やファイルマネージャーからプラグインフォルダをリネームすれば強制停止可能
- 旧バージョンへのダウングレードや開発元へのフィードバックで再発を防止できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressホスティングの「セキュア」は本当か？実検証が明かした真実
WP Tavernのポッドキャスト「Jukebox」に、WordPressセキュリティ企業PatchstackのMaciek Palmowski氏が出演した。同氏はWordCamp Europe 2026で「Testing the promise: does secure hosting deliver?」と題した講演を行い、ホスティング会社が掲げる「セキュアホスティング」の実態を検証した結果を発表した。
テストには30の既知のプラグイン脆弱性を用い、複数の主要ホストで同一条件のペネトレーションテストを実施した。結果は衝撃的で、WordPress固有の攻撃の大半が防御をすり抜けるというものだった。ここではポッドキャストの内容を基に、テストの詳細と、そこから得られる実務への教訓を解説する。
「セキュア」の看板をどう検証したのか
この調査のきっかけは、Patchstackが公開したWordPressセキュリティレポートに対する、WordPress共同創設者Matt Mullenweg氏の反応だった。WP TavernのポッドキャストでPalmowski氏は、「ホスティング会社がすでに対処しているのではないか」という趣旨の問いを受けたと述べている。同社はこれに対し、感覚ではなくデータで示す必要があると判断し、実環境でのテストに踏み切った。
30の既知の脆弱性と標準化手法
テストは2段階で行われた。最初の小規模な試験で、すでに「攻撃の80%が成功する」という結果が出たため、範囲を拡大した本試験が実施された。
- 対象: 30種類以上のプラグイン脆弱性。いずれもPatchstackのバグ報奨金プログラムを通じて報告され、攻撃手順（PoC）が確立しているもの。
- 環境: 複数の大手ホスティング会社で、提供されているすべてのセキュリティ機能を有効化した上でテスト。
- 脆弱性の種類: ファイルアップロード、パストラバーサル、SQLインジェクションなど、WordPressプラグインに典型的なものからEC向けまで幅広く選定。
つまり、現実に存在し、攻撃手法も公開されている脆弱性を「ホスティングがどこまで防げるか」を公平に調べたものだ。
この設計により、「マーケティング上のうたい文句」と「実際の防御力」の差が浮き彫りになった。
検証結果が示すギャップ
本試験の結果、WordPressに特化した攻撃の約70〜80%がホスティングの防御を通過した。Palmowski氏は「問題があるとは思っていたが、ここまで大きいとは」と語っている。
同じセキュリティツールでも結果はバラバラ
興味深いことに、同じサードパーティ製セキュリティツール（例としてCloudflareが示唆された）を導入しているホスト間でも、防御の成否に大きな差が出た。これは「どのツールを入れるか」より「どのように設定・運用するか」の重要性を示している。
この差は、設定の積極性と利便性のトレードオフにも関係する。攻撃を厳しくブロックすれば誤検知が増え、ユーザー体験を損なう可能性がある。一部のホストはユーザーへの影響を恐れて設定を緩めていると考えられる。
ホストの「その後の対応」にも差
テスト後、Patchstackは全対象ホストに結果を通知し、どの攻撃が通過したかを共有した。Palmowski氏によると、一部のホストは速やかに設定を修正し、防御力を大幅に改善した。一方で、通知後も何も手を打たなかったホストも存在したという。
「問題があること自体よりも、それを指摘された後の行動のほうが重要だ」と同氏は強調する。セキュリティに終わりはなく、発見→修正のループを回せるかどうかが本質的な強さを決める。
スイスチーズモデルと多層防御
Palmowski氏は、理想的なセキュリティを「スイスチーズモデル」で説明した。どの防御層にも穴（欠陥）は存在する。重要なのは、複数の層を重ねることで、全体として穴をふさぐことだ。
このモデルから言えるのは、ホスティングの防御は重要な第1・第2層だが、それだけでは不十分という点だ。特に第2層の「WordPressアウェア」な保護がないホストでは、第1層だけに頼ることになり、テストのように攻撃が素通りしてしまう。
AI時代の攻撃スピードとパッチ未適用問題
2026年のセキュリティ議論でAIの話題は避けられない。Palmowski氏は「攻撃の高速化」と「パッチ未適用率の高さ」の2点をリスクとして挙げた。
脆弱性公表から攻撃開始まで5時間
Patchstackの内部データによると、脆弱性が公表されてから実際に攻撃が観測されるまでの平均時間は約5時間だ。数年前はもっと長かったが、AIによる攻撃コードの自動生成がこの時間を劇的に短縮している。
「毎週の手動更新で大丈夫」というアドバイスは、2026年においてはほぼ無力だ。攻撃は日単位や週単位ではなく、時間単位で動いている。リアルタイムの防御か、少なくとも自動更新と組み合わせた仕組みが求められる。
50%の脆弱性は公表時点で未パッチ
さらに深刻なのは、発見された脆弱性の約半数が、ベンダーへの通知から30日が経過しても修正されずに公表されている事実だ。これは「とにかく更新すれば安全」という前提を崩す。更新したくてもパッチが存在しないケースが大量にあるからだ。
→ 30日間の修正猶予
STEP 2 未修正のまま公表（ケースの約50%）
→ 平均5時間で攻撃開始
STEP 3 パッチ不在のまま攻撃が拡散
このタイムラインを見れば、「プラグイン開発者が対応してから更新すればいい」という姿勢がいかに危険かがわかる。パッチが存在しない期間こそ、ホスティングレベルでの脆弱性ブロックや仮想パッチが有効になる。
ホスティング選びで問うべき質問
では、利用者や代理店はどのようにホスティングを評価すればいいのか。Palmowski氏は「WordPressに特化したセキュリティ層の有無を確認すること」が最初の一手だと述べる。
「WordPressアウェア」かどうかを見極める
営業担当者やドキュメントに「Webアプリケーションファイアウォールを備えている」とだけ書かれている場合は要注意だ。これはPHP全体に対する汎用防御であり、WordPressのプラグイン固有の脆弱性を検知できるとは限らない。
- 具体的な質問例: 「御社のセキュリティは、WordPressの特定プラグインの脆弱性を検知・ブロックする機能がありますか？」
- 答えられない、または「WAFで対応」とだけ返ってくる場合は、WordPressアウェアな層が存在しない可能性が高い。
- 逆に、特定のセキュリティパートナー（Patchstack、WPScanなど）と連携していると明言できるホストは、少なくともその層を意識していると判断できる。
「すべてを守る」という表現に注意
Palmowski氏は、ホスティング会社が「セキュリティは全てお任せください。追加ツールは不要です」と断言する場合に警戒が必要だと指摘する。同氏の言葉を借りれば、「現実には、どの防御層も完璧ではない」のだ。
「『当社はこの層を担当しますが、最終的なサイト運用のセキュリティはお客様の責任です』と明言するホストのほうが、かえって誠実で信頼できる」とPalmowski氏は評価する。完璧をうたうマーケティングよりも、限界を認めつつ強みを説明する姿勢が、これからの「セキュアホスティング」には求められる。
この記事のポイント
- 複数ホストでの実検証で、WordPress固有の攻撃の70〜80%が防御を通過していた。
- 同じセキュリティツールでも設定や運用次第で結果が大きく異なる。
- 「WAFがあるから安全」ではなく、WordPressのプラグイン構成を理解した層が必須。
- 脆弱性公表から平均5時間で攻撃が始まる現状では、手動更新だけでは不十分。
- 「スイスチーズモデル」に基づき、ホスティングの防御と自社の運用プロセスを重ねる必要がある。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GS Team Membersアップデート後にDiviサイトが壊れた場合の復旧と修正手順
GS Team Membersプラグインのバージョン2.7.17へのアップデート後にDiviサイトが壊れ「このサイトで重大なエラーが発生しました」と表示された場合、開発者が公開した修正版2.7.18へアップデートすれば解決する。リカバリーモードで管理画面に入りプラグインを一時停止したあと、最新版へ更新するだけでサイトは復旧する。
どんなエラーが発生しているのか
GS Team Members 2.7.17では、Diviテーマ向けの統合モジュールに含まれるファイル「TeamMembersModule.php」の25行目で、必要なインターフェースが見つからないという致命的なエラー（E_ERROR）が発生する。PHPが「インターフェースが存在しない」と判断し処理を停止するため、サイト全体が表示不能になる。
エラーメッセージの要点は次の通りだ。「Interface "ET\Builder\Framework\DependencyManagement\Interfaces\DependencyInterface" not found」という内容で、Diviのビルダーフレームワークが提供するDependencyInterfaceというインターフェースを読み込もうとしたが見つからなかったことを示している。
このエラーは管理画面にもフロントエンドにも影響し、WordPress本体が自動的にリカバリーモードへ移行させる。スタックトレースにはGoogle Site Kitも登場するが、これはエラーの連鎖で巻き込まれただけで、根本原因ではない。
なぜアップデートでサイトが壊れたのか
原因はGS Team Members側のコード不備だ。バージョン2.7.17でDivi向けの統合コードを更新した際、Divi本体のバージョンによっては存在しないインターフェースを参照してしまった。PHPでは存在しないクラスやインターフェースを使おうとすると即座に致命的エラーを投げるため、その瞬間にサイト全体の処理が停止する。
スタックトレースを見ると、DependencyInterfaceを読み込もうとした箇所からエラーが始まり、REST APIの初期化処理へ飛び火している。管理画面のダッシュボードでは複数のプラグインがREST API経由でデータを取得するため、Google Site Kitや他のプラグインの処理が次々にエラーに巻き込まれているが、これらは二次的なものだ。
根本的な問題はGS Team Members 2.7.17のコードにあるため、Diviを使っているユーザーだけがこのエラーに遭遇する。他のテーマやページビルダーを使っている場合は問題が起きない。
リカバリーモードで管理画面にアクセスする手順
サイトが壊れて管理画面にもアクセスできなくなった場合、WordPressは自動的にリカバリーモードへのリンクを記載したメールを管理者アドレスに送信する。このメールを使って管理画面へ入り、問題のプラグインを停止するのが最初の復旧手順だ。
リカバリーモードのリンクは24時間の有効期限が設定されている。メールが届かない場合は迷惑メールフォルダを確認し、それでも見つからなければFTPやサーバー管理ツールでプラグインフォルダの名前を変更して強制的に無効化する手段も取れる。
GS Team Membersを最新版へアップデートする
GS Team Membersの開発者はバージョン2.7.18でこの問題を修正している。アップデート内容は「Uncaught Error: Dependency Interface」への対応で、Diviテーマとの統合コードを修正したものだ。プラグインを停止した状態で管理画面の「プラグイン」ページを開き、「GS Team Members」が更新可能になっていればそのままアップデートを実行する。
更新が完了したらプラグインを再度有効化し、サイトのフロントエンドと管理画面の両方が正常に表示されることを確認する。この時点でプラグインのキャッシュが残っている可能性があるため、ブラウザキャッシュの削除も忘れずに行う。
もし更新通知が表示されない場合は、プラグインを一度削除してから新規インストールし直す方法もある。この場合、プラグインの設定や登録済みのチームメンバーデータが保持されるかどうかを事前に確認しておく必要がある。
FTPから手動でプラグインを停止する方法
リカバリーメールが届かない、あるいはメールアドレスが古くなっているなどで管理画面に入れないケースでは、FTPやサーバーのファイルマネージャーを使ってプラグインを一時停止する。手順は単純で、対象プラグインのフォルダ名を変更するだけだ。
サーバーに接続し「wp-content/plugins/」ディレクトリへ移動する。その中にある「gs-team-members」フォルダを「gs-team-members-backup」などにリネームする。WordPressはフォルダ名でプラグインを認識するため、名前が変わると自動的にプラグインが無効化される。
これでサイトが正常に表示されるようになったら管理画面へログインし、「プラグイン」ページでGS Team Membersが解除扱いになっていることを確認する。そのまま管理画面から最新版をインストールし、フォルダ名を変更した古いバージョンは削除しておく。
再発を防ぐためのアップデート前確認事項
プラグインのアップデートでサイトが壊れるリスクを減らすには、いくつかの事前対策が有効だ。第一に、本番サイトで直接アップデートを実行するのではなく、ステージング環境で事前にテストする方法が最も安全だ。国内のレンタルサーバーの多くは管理画面からワンクリックでステージング環境を作成できる機能を提供している。
第二に、WordPressにはプラグインの自動更新機能があるが、ビジネス用途で使っているサイトではこれをオフにし、すべてのアップデートを手動で確認する運用が推奨される。プラグイン一覧で更新通知を受け取ったら、そのプラグインの変更履歴（changelog）を読み、自分の環境に影響がありそうかを判断してから実行する。
第三に、バックアッププラグインを必ず導入し、アップデート前の状態をまるごと保存する習慣をつける。もし何か起きても数分で元に戻せる安心感が、トラブル時の心理的負荷を大きく下げる。
よくある質問
GS Team Members以外のプラグインでも同じようなエラーは起きるのか
起きる可能性は十分ある。特にDiviやElementorのようなページビルダー向けのアドオンを提供するプラグインは、テーマ側のバージョンと整合性が取れていないアップデートをリリースしてしまうことがある。致命的エラーに遭遇したら、まず該当プラグインを停止し、最新バージョンの有無を確認するのが基本だ。
リカバリーモードのメールが届かない場合はどうする
サーバーのメール送信設定が正しくない、管理者メールアドレスが古い、または迷惑メールに振り分けられている可能性がある。FTPで問題のプラグインを停止してから、WordPressの「設定」→「一般」で管理者メールアドレスを最新のものに更新し、SMTPプラグインを導入してメール送信を安定させるのが長期的な解決策になる。
Diviを使っていなければこのエラーは起きないのか
その通りだ。今回のエラーはGS Team MembersのDivi統合用コードに起因するため、他のテーマを使っているサイトでは発生しない。ただし、プラグインのアップデートで別のテーマとの組み合わせに問題が生じるケースは常にあり得るため、油断は禁物だ。
プラグインの更新前に毎回ステージングテストは必要なのか
小規模なサイトや個人ブログであれば必須ではないが、ECサイトや企業サイトなどビジネス用途では強く推奨される。数分のテストで数時間のダウンタイムを防げるなら、手間をかける価値は十分にある。最近の国内レンタルサーバーはステージング機能を標準搭載しているところも多い。
Google Site Kitは関係しているのか
関係していない。エラーのスタックトレースにGoogle Site Kitが登場するのは、REST APIの初期化時にたまたま処理が巻き込まれたためだ。GS Team Members単体の問題であり、Google Site Kit側での対応は不要だ。
この記事のポイント
- GS Team Members 2.7.17はDivi環境で致命的エラーを引き起こす
- リカバリーモードで管理画面に入りプラグインを停止すればサイトは復旧する
- 開発者が公開した修正版2.7.18へアップデートすれば根本解決する
- FTPでの手動停止も有効な代替手段だ
- 重要なサイトではステージング環境での事前テストが再発防止に効く
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
The Events Calendarでカレンダー表示にならない原因と直し方
The Events Calendar でカレンダー表示（月表示）を設定しているのに、一覧（リスト表示）しか出てこない原因は、多くの場合「今後のイベントが存在しない」ことによるフォールバック動作だ。今後のイベントが1件もない場合、The Events Calendar は自動的に直近の過去イベントをリスト形式で表示する。そのため、設定を変えてもカレンダーが表示されず、タブ状の一覧だけが現れる。
カレンダー表示にならずリスト表示になるのはなぜか
この現象は、The Events Calendar プラグインが持つ「今後のイベントがない場合のフォールバック機能」により発生する。プラグインの仕様として、直近で開催予定のイベントがない状態で月表示ページにアクセスすると、デフォルトで「直近の過去イベント」がリストビューで表示される。したがって、カレンダーの月グリッドが見えないのは表示設定の不備ではなく、表示する「今後のイベント」がデータベース上に1件も存在しないことが根本原因だ。
管理画面のイベント設定や表示オプションをいくら変更しても、今後のイベントが0件であればリスト表示へのフォールバックが優先され、見た目は変わらない。特に「イベントを作成して公開したはず」と思っていても、日付が過去に設定されていたり、下書きのまま放置されていたケースが多い。
イベントが存在するのにカレンダーが出ない場合のチェックポイント
イベントの日付が過去になっていないか確認する
管理画面の「イベント」→「すべてのイベント」から各イベントの開始日時を確認する。日付が過去のものであれば、そのイベントは「今後のイベント」として認識されない。イベント編集画面で開始日を未来の日付に修正し、「更新」をクリックするだけで、カレンダー表示に反映される。
イベントの投稿ステータスが「公開済み」かを調べる
イベントが「下書き」や「非公開」のまま保存されていると、フロントエンドのカレンダーには表示されない。一覧画面でステータス列を確認し、公開済みになっていないイベントがあればステータスを「公開」に変更する。カレンダー表示に使われるのは公開済みのイベントだけだと覚えておく。
カテゴリページの表示設定を確認する
特定のイベントカテゴリページ（例：「学生向けイベント」カテゴリ）でリスト表示になってしまう場合、そのカテゴリに属する今後のイベントが存在しない可能性が高い。イベント編集画面で該当カテゴリを割り当てた未来イベントを最低1件作成する。カテゴリページの URL を直接確認し、月表示のクエリ文字列がついているかもあわせてチェックする。
テンプレートの上書きやテーマの干渉を調べる
The Events Calendar の表示テンプレートを子テーマやカスタムテーマで上書きしている場合、意図しないテンプレートファイルが読み込まれて月表示が無効化されることがある。特に `tribe/events/v2/month/` 配下のテンプレートファイルを触っていないか、`/wp-content/themes/使用テーマ/tribe-events/` ディレクトリの有無を FTP やファイルマネージャーで確認する。
根本原因かどうかを1分で見極めるテスト手順
この4ステップのテストでカレンダーが正常に表示されれば、根本原因は「表示すべき未来イベントの不在」だと特定できる。もしこれでも改善しない場合、プラグインの競合やテーマの上書きを疑い、別のトラブルシューティングに進む。
今後のイベントが0件でもカレンダーグリッドを強制的に表示させる方法
どうしても空のカレンダーグリッドを表示させたい場合は、`functions.php` にフィルターフックを追加するか、The Events Calendar のアドオン「The Events Calendar Pro」で追加されるカスタマイズオプションを利用する。無料版のまま対処するなら、`tribe_events_views_v2_use_period_for_request` フィルターを使ってフォールバックの挙動を変更できる場合があるが、これは将来のアップデートで動作が変わる可能性もある。
直近の過去イベントではなく「今後のイベントはありません」といったメッセージとともに空のカレンダーを出す運用がどうしても必要な場合は、子テーマのテンプレートを修正する方法が確実だ。
よくある質問
イベントは10件以上あるのにリスト表示のままなのはなぜか
すべてのイベントが過去日付で作成されている可能性が高い。イベント一覧で「開始日」の列を確認し、未来の日付が1件もない場合は、フォールバック機能によりリスト表示になる。1件でも未来の日付のイベントを公開すれば月表示に切り替わる。
特定カテゴリのページだけリスト表示になるのはなぜか
そのカテゴリに属する今後のイベントが存在していないためだ。カテゴリページでは、当該カテゴリに割り当てられた未来イベントが1件もないと、フォールバックでリスト表示に切り替わる。該当カテゴリを付与した未来イベントを作成すれば直る。
The Events Calendar で「月」表示をデフォルトに設定するにはどうすればよいか
管理画面の「イベント」→「設定」→「表示」タブにある「デフォルトのイベント表示」で「月」を選択する。ただしこの設定は今後のイベントが存在することが前提であり、未来イベントが0件の状態では設定にかかわらずフォールバックが作動する点に注意が必要だ。
メニューからカレンダーページに直接リンクしているのにリストが出るのはなぜか
URL が正しく `/events/month/` を指していても、表示する未来イベントがなければリスト表示のフォールバックが優先される。リンク切れや設定ミスではなく、データの問題だと判断してイベントの日付とステータスを確認するのが先決だ。
カレンダー表示が壊れているのか、フォールバック動作なのかを見分ける方法は
未来の日付で公開済みのテストイベントを1件作成し、フロントエンドで該当ページを再読み込みする。これで月グリッドが表示されればフォールバック動作だと確定できる。表示がまったく変わらない、あるいはレイアウトが崩れる場合はプラグインの競合やテーマの干渉を調べる必要がある。
この記事のポイント
- 今後のイベントが0件だと The Events Calendar はリスト表示にフォールバックする
- 未来日付で公開済みのイベントを1件作れば月表示に切り替わる
- カテゴリページでも同じフォールバック動作が発生する
- テーマのテンプレート上書きやプラグイン競合は二次的な原因にすぎない
- 空カレンダーの強制表示には子テーマやフィルターフックでの対応が必要
“`
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている