タグアーカイブ 管理画面

WordPress 7.1の管理画面テーブル変更、一部プラグインに影響の可能性

WordPress 7.1の管理画面テーブル変更、一部プラグインに影響の可能性

WordPress 7.1が2026年8月19日にリリース予定だ。このバージョンでは管理画面のアクセシビリティを大幅に改善する変更が含まれる。具体的には、投稿一覧などの管理用テーブルでHTMLのセマンティクスが修正される。この修正自体は好ましい進化だが、一部のプラグインやテーマで管理画面の動作に影響が出る可能性がある。特に、管理用のテーブル構造を前提にCSSやJavaScriptでカスタマイズしている場合は注意が必要だ。

変更の規模はそれほど大きくないが、プラグイン開発者だけでなく、サイト運営者も事前に互換性を確認しておくことで、アップデート後のトラブルを回避できる。この記事では、変更の具体的な内容と、利用者・開発者それぞれが取るべき対策を簡潔にまとめる。

管理画面テーブルのHTML構造が変わる

管理画面テーブルのHTML構造が変わる

WordPress 7.1では、投稿・固定ページ・カスタム投稿タイプなどを一覧表示する管理画面のテーブル(リストテーブル)のHTMLマークアップが一部変更される。修正の対象は、主に各行の左端にあるチェックボックス列と、投稿タイトル列だ。変更点を整理すると以下のようになる。

  • チェックボックス列が <th>(行ヘッダー)から <td>(通常のセル)に変更される
  • 投稿タイトル列が <td> から <th scope="row">(行ヘッダー)に変更される
  • 投稿タイトルの行ヘッダーには、投稿名を含む aria-label 属性が追加される
  • レスポンシブ表示時の折りたたみセルがFlexboxレイアウトに更新される

この変更によって、スクリーンリーダーを利用するユーザーは、各行で「どの投稿を操作しているのか」を正確に認識できるようになる。従来は、チェックボックス列が行ヘッダーだったために「すべて選択」といった無意味なラベルが読み上げられることが多く、特に投稿がロックされている場合などは混乱の原因になっていた。

変更前と変更後のコード比較

具体的にHTMLがどのように変更されるのか、簡単な例を示す。まずは現行バージョンの構造だ。

<tr>
<th scope="row" class="check-column">
<input type="checkbox" name="post[]" value="123">
</th>
<td class="title column-title column-primary page-title">
<a class="row-title" href="...">Hello world!</a>
</td>
<td class="author column-author">admin</td>
</tr>

これがWordPress 7.1では以下のように変わる。

<tr>
<td class="check-column">
<input type="checkbox" name="post[]" value="123">
</td>
<th scope="row" class="title column-title column-primary page-title" aria-label="Hello world!">
<a class="row-title" href="...">Hello world!</a>
</th>
<td class="author column-author">admin</td>
</tr>

チェックボックスのセルが <th> から <td> になり、代わりにタイトル列が <th scope="row"> として行の見出しの役割を担う。これにより、支援技術は「Hello world!」という投稿タイトルを行の識別子として扱えるようになる。

従来のテーブル行(Before)
チェックボックス列(th)
「すべて選択」と読み上げられる
タイトル列(td)
行の見出しではない
WordPress 7.1のテーブル行(After)
チェックボックス列(td)
ラベルなし、単なるセルに
タイトル列(th scope=”row”)
「Hello world!」が行見出しとして読み上げ
チェックボックス列が行ヘッダーから通常セルに  タイトル列が行ヘッダーに昇格

この変更は、サイトのフロントエンド(公開側)には一切影響しない。問題が発生するのはあくまで管理画面の投稿一覧テーブルをカスタマイズしている場合に限られる。

11年越しのバグ修正がもたらすアクセシビリティ向上

WordPressのコア開発チケット「#32892」は、この問題を報告してから実に11年が経過していた。修正が長期化した背景には、管理画面のテーブルマークアップが広範囲に影響するため、影響範囲の調査とテストに時間を要したことがある。

従来の構造では、スクリーンリーダーが各行を読み上げる際に、チェックボックスに関連付けられたラベル(多くの場合「すべて選択」)を読み上げてしまい、ユーザーはどの投稿の行にいるのか理解しづらかった。特に投稿が他ユーザーによってロックされている時に表示される鍵アイコンには、読み上げ用のラベルがなく、スクリーンリーダーは「すべて選択」と繰り返すだけだった。今回の変更により、行の主たる識別子である投稿タイトルが適切に読み上げられるようになり、管理画面の操作性が大きく改善される。

サイト運営者が今すぐすべきこと

サイト運営者が今すぐすべきこと

影響を受けるのは、管理画面の投稿一覧に対して何らかの情報や操作を追加しているプラグインのみだ。具体的には、CSSやJavaScriptで特定の <th><td> をターゲットにしてカスタマイズしているプラグインが対象となる。多くのサイトでは問題は起きないが、念のため以下の手順で確認することをおすすめする。

プラグインの互換性情報を確認

WordPress 7.1の公開後、利用中のプラグインが互換性テストをパスしているかどうかをまずチェックしよう。方法は簡単で、「プラグイン名 changelog」や「プラグイン名 WordPress 7.1」で検索すれば、開発元の公式ブログやチェンジログが見つかる。プラグインが「7.1対応済み」と明記されていれば、先にプラグインを最新版に更新してからWordPress本体のアップデートを行うと安全だ。

互換性が未確認の場合は、本番環境に直接アップデートを適用せず、ステージングサイト(テスト環境)で事前に動作確認を行うことが望ましい。特に管理画面に大きく依存したワークフローを構築しているサイトでは、ステージングでのテストは必須に近いと考えていい。

主要SEOプラグインへの影響はほぼなし

多くのサイトで利用されているYoast SEO、Rank Math、All in One SEO(AIO SEO)の3つのSEOプラグインには、管理画面の投稿一覧に独自のカラムを追加する機能が含まれている。こうしたプラグインこそ影響を受けやすいように見えるが、Search Engine Journalの記事によると、公開されているコードを確認した限りでは、今回変更される <th><td> の構造に依存したセレクタは見つからなかったという。したがって、これらのプラグインがWordPress 7.1で即座に動作しなくなる可能性は極めて低い。

ただし、これは公式の保証ではない。各プラグインの公式ブログやチェンジログで、7.1対応についてアナウンスがないか確認しておくに越したことはない。

万が一問題が出た場合の対処

仮にプラグインが管理画面の投稿一覧で表示崩れや機能停止を起こしたとしても、フロントエンドの表示やSEO評価に直接影響が出ることはまずない。管理画面の一部の機能が不安定になる程度と考えてよい。その場合は、問題のプラグインを一時的に無効化するか、開発元の対応を待つことになる。落ち着いてステージング環境で原因を特定し、本番への影響を最小限に抑える対応を取ろう。

プラグイン開発者とカスタム実装者に向けて

プラグイン開発者とカスタム実装者に向けて

WordPress向けのプラグインや管理画面のカスタマイズを行っている開発者は、今回の変更を事前に把握し、影響を受けるセレクタを修正する必要がある。特にノーコードツールやAIによるコーディング(いわゆるVibe Coding)で生成されたコードをそのまま利用している場合、セレクタの記述が <th><td> に依存している可能性が高いため、注意が必要だ。

修正すべきセレクタの典型例

問題となるのは、以下のようなCSSやJavaScriptのセレクタだ。

  • #the-list tr th.check-column のような、チェックボックスの <th> を前提としたCSSルール
  • document.querySelectorAll('tbody td.title') のように、タイトル列を <td> として取得するJavaScript
  • カスタムカラムを追加する際に、<td> の直後に <td> を挿入するロジック

開発者は、セレクタをタグ名ではなくクラス名(.check-column.title)に基づいたものに書き換えることで、新旧両方のマークアップに対応できる。WordPress 7.1への移行期間中は、<th><td> の両方にマッチするようなセレクタを用意するか、バージョン分岐処理を入れるのが安全だ。変更自体は単純なため、対応に膨大な工数がかかることはないだろう。

問題のあるセレクタ(Before)
tr th.check-column で背景色を変更
→ 7.1では <td> になるためスタイルが当たらなくなる
安全なセレクタ(After)
tr .check-column で背景色を変更
→ クラス名で指定するため、タグ変更に影響されない
タグ名に依存したセレクタは7.1で無効化される  クラス名ベースに修正すれば互換性が保たれる

なお、公式の発表では、テーマのフロントエンド側マークアップには一切手が加えられていないことが明言されている。管理画面のカスタマイズだけをメンテナンスすればよく、影響範囲は極めて限定的だ。

この記事のポイント

  • WordPress 7.1ではアクセシビリティ向上のため、管理画面の投稿一覧テーブルのHTML構造が変更される
  • チェックボックス列が <th> から <td> に、タイトル列が <td> から <th scope="row"> に変わる
  • フロントエンドへの影響はなく、管理画面のカスタマイズに依存する一部プラグインのみ注意が必要
  • 主要SEOプラグイン(Yoast、Rank Math、AIO SEO)は現時点で影響が確認されておらず、互換性情報の確認を推奨
  • 開発者はタグ名ではなくクラス名ベースのセレクタに修正することで新旧両対応が可能
WordPressサブディレクトリ環境でプラグイン管理画面が404になる原因と対処

WordPressサブディレクトリ環境でプラグイン管理画面が404になる原因と対処

WordPress をサブディレクトリに置いている環境で、一部プラグインの管理画面にアクセスすると「ページが見つかりません(404)」になる。これはプラグイン内部で作られた管理画面の URL が、実際のディレクトリ構造と合っていないのが主な原因だ。プラグインの更新で修正されることが多く、一時的に URL へ正しいパスを手動で加えればすぐに操作を再開できる。

なぜ管理画面のプラグインページが404になるのか

なぜ管理画面のプラグインページが404になるのか

WordPress の管理画面は通常 /wp-admin/ で始まるが、Bedrock(roots.io スタック)のようなカスタム構成では、コアファイルを /wp/ の下に配置する。管理画面の URL は /wp/wp-admin/ のようにサブディレクトリが一段深くなる。ここで、プラグインが管理画面へのリンクを作る際に「/wp-admin/ はルート直下にある」という前提でコードを書いていると、リンク先が https://example.com/wp-admin/... のようにサブディレクトリを反映しない形になり、フロントエンドで処理されて結果的に404になる。

これはコアファイルの場所を変更していない標準的なインストールでは表面化しない。Bedrock や独自に /cms/ などへ配置を変えているサイトで、かつプラグインが管理画面のパスをハードコード(直書き)している場合に限って起こる。エラーログには何も残らず、ただ「ページが見つかりません」と表示されるため、原因の特定に手間取ることが多い。

✕ エラー状態(Before)
プラグインが生成したURL(ルート相対)
/wp-admin/admin.php?page=milo-subscriptions#/payments
→ フロントエンドの /wp-admin/… を探しに行き404
✔ 修正後(After)
サブディレクトリを考慮した正しいURL
/wp/wp-admin/admin.php?page=milo-subscriptions#/payments
/wp/ が入り、管理画面として正常に開く

上記デモのとおり、プラグインが出力したパスに /wp/ が1つ欠けているために「そんなページはフロントエンドに存在しない」と判断され、404 が返っている。見た目はありふれた存在しないページへのアクセスと変わらず、管理画面の一部だけが突然消えたように感じる。

サブディレクトリ環境で発生する404の一時的な回避策

サブディレクトリ環境で発生する404の一時的な回避策

プラグインのアップデートを待たずに、今すぐ該当画面を操作したい場合は、ブラウザのアドレスバーで404になった URL を直接編集する。たとえば /wp-admin/ の直前に、自分の環境で実際に使っているサブディレクトリ名(Bedrock なら /wp/)を挿入して再度アクセスすれば、多くの場合そのまま画面が開く。修正後の正しいパスは /wp/wp-admin/admin.php?page=... の形になる。

この操作はあくまで一時しのぎで、管理画面内の他のリンクも同じ問題を抱えている可能性がある。ページを移動するたびに手動で URL を直すのは現実的ではないため、根本的な解決にはプラグインの修正が必要になる。

プラグインのアップデートで完全に解決する

プラグインのアップデートで完全に解決する

この種の不具合は、プラグインが WordPress 標準の関数(admin_url() など)を使わずにパスを決め打ちで書いてしまったために起こる。開発者がこの問題に気づけば、次のバージョンで修正されるのが一般的だ。実際、今回の事例の Milo Subscriptions でも、内部の管理画面リンクを WordPress が返す正しい URL から組み立て直す修正がバージョン 1.8.7 で適用された。まずは管理画面の「プラグイン」から当該プラグインの更新がないか確認し、最新版が提供されていれば即座に適用する。

更新がすぐに提供されていない場合でも、問題が発見された後のバージョンでは修正されていることが多い。プラグインの公式ページの「Changelog(変更履歴)」に “Fix admin URLs on subdirectory installs” のような記載があれば、それを当てるだけで解決する。

恒久的な修正のためにプラグイン開発者へ報告する

恒久的な修正のためにプラグイン開発者へ報告する

まだ修正されていないプラグインで同じ症状が出るなら、サポートフォーラムや公式リポジトリの Issues で「サブディレクトリ構成だと管理画面のリンクが404になる」と具体的に伝えるのが最も建設的だ。報告の際は、自分の WordPress が /wp//cms/ などのサブディレクトリにインストールされていること、問題が起こる画面の URL、使っているテーマや主要プラグインのバージョンを添えると、開発者が原因を特定しやすい。サブディレクトリ環境に限ったバグはテストで見落とされやすいため、利用者からの報告がなければ長期間放置される可能性がある。

よくある質問

サブディレクトリへ WordPress をインストールするのは特別なのか

標準的な構成であっても、WordPress 本体を /wp//cms/ といったサブディレクトリに置くことは公式にも認められた設定だ。Bedrock や一部のセキュリティ寄りのスタックは、コアファイルをルートから分離する目的でこの構造を採用している。ただし、プラグインやテーマの開発者が標準構成だけを想定してテストしていると、今回のようなパス解決のミスが残りやすい。

サブディレクトリ環境だと他にどんな不具合が起きるのか

管理画面のリンク切れ以外にも、REST API や Ajax のエンドポイントが見つからずに動作が止まるケースがある。たとえば画像の一括処理やリアルタイム検索が動かなくなることがある。いずれも WordPress が提供する URL 取得関数(rest_url()admin_url())を使わずにパスを直書きしていることが原因だ。

自分でプラグインのコードを修正してもよいのか

管理画面のリンクをすぐに直す必要があるなら、プラグインの該当ファイルを子テーマやカスタムプラグインで上書きできれば対処できる。ただし、元のプラグインが更新されると上書きが無効になるため、恒久的な対応としては推奨しない。一時しのぎと割り切ったうえで、開発者へのフィードバックとセットで行うのが現実的だ。

Bedrock 以外の構成でも同じ問題は起こるのか

WordPress を /wp/ 以外の任意のディレクトリ(/cms/ /admin/ など)に配置している場合、まったく同じ仕組みで発生する。また、マルチサイトのサブディレクトリ構成でも、特定の管理画面リンクが正しく生成されないことがある。原因の構造は共通しているため、対処の考え方は変わらない。

この記事のポイント

  • サブディレクトリ環境ではプラグインの管理画面リンクが404になることがある
  • 原因はプラグインがパスをルート相対でハードコードしていること
  • 一時的には URL へ正しいサブディレクトリを手動で挿入すればアクセスできる
  • プラグインの最新版を確認し、修正があればすぐに更新する
  • 修正がまだなら開発者へ具体的な環境情報を添えて報告する
プラグイン更新後に管理画面が真っ白になった時の原因と直し方

プラグイン更新後に管理画面が真っ白になった時の原因と直し方

このエラーはプラグイン開発側の不具合によるものだ。FTP やレンタルサーバーのファイルマネージャーで当該プラグインフォルダを一時的にリネームすれば、管理画面へ再びログインできるようになる。

プラグイン更新後に「重大なエラー」でログイン不能になる原因

今回の事象は「protect-login」1.5.0 へのアップデート後に起きている。エラーログを確認すると「Uncaught TypeError」とあり、ある関数が文字列を期待しているのに配列が渡されたためにスクリプトが停止した。このような PHP の型不整合は、プラグイン内部のロジック変更やテスト不足で起こりやすい。WordPress は致命的エラーが発生すると「このサイトで重大なエラーが発生しました」と表示し、管理画面へのアクセスも遮断する仕組みだ。

エラー発生前後の状態
Before(エラー発生)
プラグイン更新後、ログイン画面で「このサイトで重大なエラーが発生しました」と表示され管理画面に入れない
After(プラグイン無効化後)
問題のプラグインが無効化され、管理画面へ通常通りアクセスできる
エラー状態  復旧後

管理画面に入れない状態からプラグインを無効化する手順

管理画面に入れない状態からプラグインを無効化する手順

管理画面が完全に使えなくても、サーバー上のファイルを直接操作すればプラグインを無効化できる。FTP クライアントの接続情報がわからないケースも多いため、多くのレンタルサーバーが提供する「ファイルマネージャー」機能を使うのが最も現実的だ。

ファイルマネージャー操作の流れ
STEP 1 サーバー管理画面にログインする
STEP 2 ファイルマネージャーで /wp-content/plugins/ に移動する
STEP 3 問題のプラグインフォルダを「protect-login_off」などにリネームする
STEP 4 管理画面にログインできることを確認する

ファイルマネージャーでプラグインフォルダをリネームする

レンタルサーバーの管理画面で「ファイルマネージャー」や「FTP ツール」と呼ばれる機能を開く。WordPress をインストールしたディレクトリに移動し、wp-contentplugins と進む。今回の事例では「protect-login」というフォルダが該当するが、任意のプラグイン更新後に同様の事態になった場合は、最後に更新したプラグインのフォルダ名を探す。

該当フォルダ名を右クリックし「名前の変更」で末尾に「_bak」や「_off」を付加する。たとえば「protect-login」を「protect-login_bak」に変えるだけで、WordPress はそのプラグインを読み込まなくなる。これで致命的エラーが解消され、管理画面へ再びアクセスできる。

FTP 接続情報が手元にある場合の操作

FTP クライアント(FileZilla や Cyberduck など)にホスト名やユーザー名、パスワードを設定して接続できるなら、同様に /wp-content/plugins/ に移動し、問題のフォルダをリネームする。FTP のほうがファイル操作は素早いが、接続情報が不明な場合はサーバー管理画面のファイルマネージャーを使う手順で問題ない。

復旧後に原因プラグインをどう扱うか

復旧後に原因プラグインをどう扱うか

プラグイン開発者の修正状況を確認する

管理画面にログインできたら、WordPress の「プラグイン」一覧で問題のプラグインは「無効化」状態で表示される。開発者が修正版をリリースしているかどうかを、WordPress.org のプラグインページや開発者の公式サイトで確認する。今回の事例でも、開発者から「同日中に修正を配布する」というアナウンスが出ている。修正が確認できたら、プラグインを最新版に更新してから再度有効化を試みる。

以前のバージョンに戻す方法

プラグインの「開発版」タブや公式 SVN リポジトリから旧バージョンの ZIP をダウンロードし、手動でアップロードし直す方法もある。具体的には、WordPress.org の該当プラグインページ下部にある「以前のバージョン」セクションから、安定していたバージョンを選んでダウンロードする。管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選んでインストールし、既存のプラグインを上書きできる。

代替プラグインへの切り替えを検討する

問題のプラグインが長期間修正されない、あるいは開発が停滞している場合は、同様の機能を持つ別のプラグインを検討する。ログイン試行制限機能であれば「Limit Login Attempts Reloaded」や「Wordfence Security」のログイン保護モジュールなど、更新が継続的で評価の高い選択肢が存在する。

同様のトラブルを未然に防ぐ運用のポイント

同様のトラブルを未然に防ぐ運用のポイント

ステージング環境で事前テストする

本番サイトに直接プラグイン更新を適用する前に、ステージング環境(複製サイト)を用意して動作確認する習慣を持つと、致命的なエラーでサイトが停止するリスクを回避できる。多くの国内レンタルサーバーはワンクリックでステージングを作成する機能を備えている。

自動アップデートの対象を絞る

WordPress にはプラグインごとに自動アップデートを有効・無効にする設定がある。重要なプラグインほど、メジャーアップデートが行われるタイミングを自分でコントロールし、更新直後はサイトの状態を確認できるスケジュールを組むと安全だ。

定期的なバックアップの重要性

万が一、プラグインのリネームでは復旧できないほど深刻な不具合が起きた場合、最新のバックアップがあればサイト全体を以前の状態に戻せる。UpdraftPlus や BackWPup などのプラグインで、データベースとファイルを定期的にバックアップし、サーバー外のクラウドストレージに保存しておく。

よくある質問

エラーメッセージをメールで受け取るにはどうすればいいか

WordPress の管理画面にすら入れない状況では、サーバー側のエラーログを確認するか、WordPress の wp-config.php にデバッグモードを設定してログファイルに出力させる方法がある。define('WP_DEBUG', true);define('WP_DEBUG_LOG', true); を追記すると、/wp-content/debug.log に詳細が記録される。

プラグインフォルダを削除しても問題ないか

削除でも無効化は可能だが、リネームのほうが安全だ。削除するとプラグインの設定データがデータベースに残るかどうかはプラグイン次第で、完全に消えるケースもある。リネームしておけば、修正版がリリースされたときに元の名前に戻すだけで設定を維持したまま再度使い始められる。

「このサイトで重大なエラーが発生しました」という表示を訪問者に見せない方法はあるか

WordPress 5.2 以降、致命的エラーが発生するとこのメッセージが表示される。管理者には回復モードへのリンクが入ったメールが送信される仕組みだが、メールが届かない場合もある。根本的には、エラーそのものを発生させないことと、前述のファイル操作による迅速な復旧が最も重要だ。

更新前に自動でバックアップを取る方法はあるか

プラグイン「UpdraftPlus」のプレミアム版や「BlogVault」は、WordPress のコアやプラグイン更新の直前に自動でサイト全体をバックアップする機能を持っている。更新後に問題が発生しても、管理画面から数クリックで直前の状態に復元できるようになる。

レンタルサーバーのファイルマネージャーが見当たらない場合の対処法

契約しているサーバー会社の管理画面(cPanel や独自パネル)に「ファイルマネージャー」がない場合でも、「FTP アカウント」セクションから接続情報を作成し、PC の FTP クライアントで接続できる。どうしてもわからなければサーバー会社のサポートに問い合わせて、WordPress のプラグインを手動で無効化したいと伝えれば手順を案内してもらえることが多い。

この記事のポイント

  • プラグイン更新後の致命的エラーは、サーバー上のファイル操作でプラグインを無効化すれば即座に復旧できる
  • ファイルマネージャーや FTP で /wp-content/plugins/ 内の該当フォルダをリネームする
  • 復旧後は開発者の修正状況を確認し、安全を確かめてからプラグインを再び有効化する
  • 日頃からステージングテストやバックアップを習慣化し、自動アップデートの対象を絞っておく