TablePress 3.4更新後にテーブルが表示されない時の原因と安全な復旧手順
TablePress 3.4に更新した後にテーブルがショートコード [table id=28 /] のまま表示されない場合、まずプラグインが停止しているか、ショートコードの処理が途中で失敗しているかを確認する。サイト内検索まで動作しなくなったケースでは、古いテーブルデータの保存形式に不整合が起きている可能性が高いが、バックアップを取ればデータを失わずに復旧できる。
TablePress 3.4への更新後にテーブルが表示されない原因
TablePress は、投稿や固定ページに書かれた [table id=28 /] というショートコードを、実際の表の HTML に置き換えて表示する仕組みになっている。プラグインが無効化されていたり、更新の途中で停止していたりすると、この置き換えが行われず、ショートコードがそのまま画面に出る。
更新直後にショートコードだけが見える症状と、プラグイン停止という原因の関係を表したものだ。停止が原因なら再有効化だけで表は戻る。
ショートコードがそのまま表示される仕組み
ショートコードは、WordPress のプラグインがページ表示のタイミングで処理する仮の置き場だ。TablePress が有効な状態なら表に変換されるが、無効になると [table id=28 /] という文字列が読者に見えてしまう。更新後にこの症状が出た場合は、更新処理が最後まで完了せずプラグインが自動で停止したケースが多い。
更新後にプラグインが自動で停止していないか確認する
WordPress の管理画面で「プラグイン」メニューを開き、TablePress の状態を確認する。「有効化」ボタンが表示されていれば、更新後に何らかの理由で停止している。まず一時的に有効化し、テストページで表が表示されるか、サイト内検索が動くかを順に確かめる。
なぜ更新後にサイト内検索が動かなくなったのか
TablePress のデータは、WordPress の投稿と同じデータベースの wp_posts テーブルに保存されている。テーブル本体は JSON という書式で格納されるため、3.4 更新後に古い形式のデータを読み込む処理が変わると、サイト全体の投稿一覧や検索クエリにエラーを引き起こすことがある。特に公開サイトの検索フォームが正常に動作しなくなる症状が報告されている。
古いテーブルデータの保存形式と不整合のリスク
長年運用してきたサイトでは、TablePress が過去に保存したテーブルデータが現在の期待する形式と異なる場合がある。3.4 ではテーブルの読み込み処理が更新されたため、旧形式のデータをそのまま読み込むと PHP の警告や致命的エラーが発生し、結果として検索機能まで落ちることがある。
検索が壊れたときはプラグイン切り分けで特定する
TablePress を無効化して検索が復活したなら、原因は TablePress 側にある可能性が高い。より正確に切り分けるには、TablePress を有効化したままテーブルを1つずつ再保存し、どのテーブルで検索が止まるかを調べる。これにより、データの破損箇所を特定できる。
バックアップを取ったうえで安全に復旧する手順
復旧作業は、必ず現状のバックアップを確認してから進める。ショートコードが表示されたままの公開ページを放置せず、次の手順で原因の切り分けと復旧を行う。
復旧の作業は5段階で進める。いきなり全テーブルを変更せず、表示と検索を細かく確認しながら原因を絞り込むのが安全だ。
復旧前に実施するバックアップの確認
UpdraftPlus のようなバックアッププラグインで、サイト全体とデータベースのバックアップが最新であることを確認する。バックアップの復元方法も1度確認しておくと、万が一テーブルデータを誤って書き換えても元に戻せる。
プラグインの再有効化と表示確認
プラグイン画面で TablePress を有効化し、問題が出ているページを1つだけ開いて表が表示されるか確認する。このときサイト全体のキャッシュが残っていると古い画面が見えるため、シークレットウィンドウや別ブラウザで確認すると正確だ。
古いテーブルを1つずつ再保存して切り分ける
TablePress の管理画面で「テーブル一覧」を開き、公開している各テーブルを編集画面で開いて「変更を保存」を押す。再保存で現在の形式にデータが整い、古い形式に起因するエラーが解消されることが多い。1つ保存するたびに検索が動くかを確認すれば、問題のあるテーブルを特定できる。
ブラウザとサイトのキャッシュを削除して再確認
再保存後も症状が続く場合は、WordPress のキャッシュ系プラグインやサーバー側のキャッシュを削除し、ブラウザのキャッシュもクリアする。キャッシュが残ったままだと、修正後の状態を確認できない。
古いテーブルデータの不整合を調べて修正する方法
古いテーブルデータの不整合が原因で検索まで壊れた場合は、テーブルを再保存するだけでなく、データの中身を直接確認する方法も有効だ。焦らず1つずつ確認すれば、過去の歴史データを失わずに済む。
どのテーブルが古い形式かを特定する方法
TablePress のテーブル一覧で、更新日時が古いテーブルや、長期間編集していないテーブルを優先して確認する。古い形式のデータは、特に大量の行を持つテーブルで問題を起こしやすい。まず行数の多いテーブルから再保存を試す。
JSONデータの破損を修復する手順
TablePress のテーブルは JSON 形式でデータベースに保存されている。破損が疑われる場合は、TablePress の「エクスポート」機能で CSV として書き出し、内容を確認してから新しいテーブルとして読み込む。これにより JSON の構造が新しく作り直され、破損が解消される。
エクスポートと再インポートでデータを整える
元テーブルをエクスポートして CSV を保存し、TablePress の「インポート」で新しいテーブルとして取り込む。取り込み後にショートコードの ID が変わらないよう、元のテーブルを削除して同じ ID に割り当てるか、元テーブルを編集して CSV を貼り直す。ID を変えたくない場合は、テーブル編集画面で内容を丸ごと貼り直すのが安全だ。
旧バージョンへ戻す一時的な対処と再更新の判断
場合によっては、TablePress 3.4 自体の不具合が原因で、データを整えても検索や表示が直らないことがある。その場合は旧バージョンへ戻して一時的に安定させ、修正版のリリースを待つのが現実的な選択になる。
旧バージョンを入手して手動で戻す手順
WordPress.org の TablePress プラグインページにある「詳細を表示」から過去のバージョンを取得する。管理画面の「プラグイン > 新規追加 > プラグインのアップロード」で旧バージョンの ZIP をアップロードすると、現在のバージョンを上書きして戻せる。アップロード前には必ずバックアップを取り直す。
ロールバック後に再度更新するタイミング
旧バージョンへ戻したら、WordPress の更新通知で TablePress 3.4 の修正版が出るまで自動更新を止めておくことも検討する。修正版が公開されたら、テスト環境か深夜の時間帯で更新し、表示と検索を再確認してから本番に適用する。
よくある質問
TablePress を再有効化したら検索が再び壊れるのでは？
まずテーブルを1つずつ再保存してから検索を確認すれば、問題のあるテーブルだけを特定できる。再保存後も検索が壊れるなら、旧バージョンへ戻すか、プラグインの修正版を待つ。バックアップがあれば元に戻せるため、慌てて全データを消す必要はない。
古いテーブルだけが表示されないのはなぜか
古いテーブルはデータの保存形式が現在の TablePress と一致していない場合がある。編集画面で開いて保存し直すと現在の形式に変換され、表示されるようになることが多い。
TablePress を無効化したままでもデータは消えないか
プラグインを無効化しても、テーブルのデータはデータベースに残る。プラグインを削除しない限り過去のデータは保持される。ただし安全のため、無効化中もバックアップを取っておく。
ショートコードが表示されたまま放置するリスクは？
訪問者に [table id=28 /] という文字列が見え続けると、サイトの信頼性が下がる。検索エンジンのクローラーも表の内容を取得できないため、早めに再有効化か代替表示へ切り替える。
キャッシュ系プラグインを使っている場合の注意点は？
修正後も古い画面が表示され続ける場合は、キャッシュ系プラグインの全キャッシュ削除とブラウザのキャッシュクリアを行う。サーバー側のキャッシュが残っていることもあるため、ホスティングの管理画面も確認する。
この記事のポイント
- 更新後にショートコードが見えるのはプラグイン停止が主な原因
- まずバックアップを確認し、それから再有効化する
- 検索が壊れた場合は古いテーブルデータの不整合を疑う
- テーブルを1つずつ再保存して問題箇所を特定する
- 直らないときは旧バージョンへ戻して修正版を待つ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている