タグアーカイブ プラグイン

  1. ホーム   /  タグ付きの投稿: "プラグイン" ( 固定ページ4 )
Yoast SEOが原因でWordPress 7.0の編集画面が読み込めない時の対処
2026年7月6日 0

Yoast SEOが原因でWordPress 7.0の編集画面が読み込めない時の対処

WordPress 7.0 の編集画面で、改訂（リビジョン）を視覚的に比較できる新機能が使えなくなったり、iFrame 版エディターの読み込みに問題が出るケースがある。これは、Yoast SEO のクラシックメタボックスが存在すると、WordPress 7.0 が新機能を意図的に無効化する仕様になっているためだ。Yoast SEO の設定を残したまま問題を回避したい場合は、該当の投稿タイプに対して Yoast SEO のメタボックスを設定からオフにすればよい。

なぜ Yoast SEO が有効だと WordPress 7.0 の新エディター機能が使えなくなるのか

なぜ Yoast SEO が有効だと WordPress 7.0 の新エディター機能が使えなくなるのか

WordPress 7.0 では、ブロックエディターが iFrame 版に移行し、改訂の比較画面がこれまでより直感的な UI に変更された。ところが、Yoast SEO に限らず、ひとつでもクラシックメタボックスが有効な状態だと、WordPress はこれらの新機能を自動的にオフにして旧来の改訂画面にフォールバックする。これは WordPress の意図的な挙動であり、Yoast SEO 単体のバグや不具合ではない。

クラシックメタボックス経由で保存された値（SEO タイトルやメタディスクリプションなど）は、現状の仕組みでは改訂を復元する際に正しく戻せない。そのため、互換性を保証できないメタボックスがある場合は、改訂のビジュアル比較のような高度な機能をまるごと制限する方針がとられている。

全メタボックスをコードで削除する対処がおすすめできない理由

全メタボックスをコードで削除する対処がおすすめできない理由

一部のユーザーは do_meta_boxes フックを使って投稿画面からメタボックスをすべて除去するコードを導入しているが、この方法には大きな副作用がある。公開ボックスだけを残して他の全メタボックスを削除してしまうため、Yoast SEO の SEO 設定が編集画面から消えるだけでなく、入力した値が保存されなくなる。結果として、検索エンジン向けの重要な情報が失われてしまう。

さらに、他のプラグインが提供するメタボックスも同時に削除されるため、カスタムフィールドや追加の設定パネルが一斉に使えなくなり、サイトの運用に支障をきたす可能性が高い。

Yoast SEO の SEO 設定を残したまま問題を解決する手順

Yoast SEO の SEO 設定を残したまま問題を解決する手順

Yoast SEO の開発チームは、特定の投稿タイプでのみ SEO コントロールを無効にする標準的な方法を用意している。この手順を使えば、他の投稿タイプには影響を与えず、該当の編集画面でのみ Yoast SEO メタボックスを非表示にできる。

ただし、現時点ではメタボックスを無効にすると、Yoast SEO の SEO タイトルやメタディスクリプションといった設定欄そのものが編集画面から消える点に注意が必要だ。編集画面のサイドバーにある Yoast SEO のパネルは、内部でメタボックスに依存しているため、メタボックスをオフにするとサイドバーも機能しなくなる。

STEP 1 WordPress 管理画面の左メニューから「Yoast SEO」→「設定」を開く
↓
STEP 2 「コンテンツタイプ」タブを選択し、対象の投稿タイプ（投稿、固定ページ 等）を見つける
↓
STEP 3 「SEO コントロールとアセスメントを有効にする」のトグルをオフにして変更を保存する

この設定変更は該当の投稿タイプにのみ適用され、他の投稿タイプでは引き続き Yoast SEO の全機能を利用できる。もし WordPress 7.0 の新エディター機能をどうしても優先したい場合の現実的な手段といえる。

メタボックスを非表示にした後、SEO 設定はどこで操作するのか

メタボックスを非表示にした後、SEO 設定はどこで操作するのか

この問題について Yoast チームは、現在メタボックスに依存している構造を刷新する作業を進めていると明かしている。将来的には、メタボックスをオフにしてもサイドバーから SEO 設定を操作できるようになる見込みだが、現時点では具体的な対応時期は公表されていない。

また、WordPress 7.1 で導入が検討されているリアルタイム共同編集機能への対応についても、Yoast チームは前向きな姿勢を示している。しかし、多数のアドオンが複雑に連携するエコシステム全体との互換性を保つ必要があるため、拙速なリリースは避け、慎重に開発を進めている段階だ。

一時的な回避策としてメタボックスを残しつつ運用するには

一時的な回避策としてメタボックスを残しつつ運用するには

SEO 設定を引き続き編集画面で操作したい場合、現時点では Yoast SEO のメタボックスを有効にしたまま、WordPress 7.0 の新改訂機能を使わずに従来の改訂画面で作業を続けることになる。これは不具合ではなく WordPress の設計上の制限であるため、Yoast SEO 側のアップデートを待つのが最も安全な対応といえる。

よくある質問

Yoast SEO 以外のプラグインでも同じ現象は起きるのか

起きる。クラシックメタボックスを提供しているプラグインであれば、どのプラグインでも同様の理由で WordPress 7.0 の新エディター機能が制限される。特定のプラグインに限った問題ではない。

設定をオフにした投稿タイプの SEO データは消えてしまうのか

保存済みの SEO タイトルやメタディスクリプションなどのデータが削除されることはない。設定を再度オンにすれば、以前のデータはそのまま復帰する。

コードで特定のメタボックスだけを削除することは可能か

技術的には可能だが、公式に推奨されている方法ではない。Yoast SEO の内部構造に依存するため、アップデートで動作しなくなるリスクが高い。どうしてもコードで対処する場合は、上書きした設定が保存されなくなる副作用を十分に理解したうえで行う必要がある。

この問題は Yoast SEO のアップデートで解決されるのか

Yoast チームはメタボックスへの依存を解消する改修を進めている。時期は未定だが、いずれはメタボックスを無効にしてもサイドバーから全機能を利用できるようになる予定だ。

この問題は WordPress 6.7 以前のバージョンでも発生するのか

発生しない。WordPress 7.0 で新たに導入された仕様であり、6.7 以前のバージョンではクラシックメタボックスが存在していても改訂機能が制限されることはない。

この記事のポイント

  • WordPress 7.0 で Yoast SEO のメタボックスが原因となり新エディター機能が制限されるのは、WordPress の意図的な仕様である
  • 全メタボックスをコードで削除する対処は SEO 設定の消失を招くため推奨されない
  • Yoast SEO の設定画面から特定の投稿タイプの SEO コントロールをオフにすることで問題を回避できる
  • メタボックスをオフにすると SEO 設定欄そのものが使えなくなる点に注意が必要
  • Yoast チームはメタボックス依存の解消を進めており、将来的には問題が根本的に改善される見込み
佐々木 太陽
, , , , ,
お悩み・トラブル解決
OptinMonsterやTrustPulseが原因でWordPressが乗っ取られた時の対処
2026年7月4日 0

OptinMonsterやTrustPulseが原因でWordPressが乗っ取られた時の対処

特定のプラグインをインストールしていた WordPress サイトで、管理者アカウントが勝手に作られたり、マルウェアを仕込まれる被害が広がっている。無効化した状態でも影響を受けるため、すぐにユーザー一覧とプラグインフォルダを確認しなければならない。

なぜ無効化したプラグインで侵入されたのか

なぜ無効化したプラグインで侵入されたのか

被害報告が相次いでいるのは、OptinMonster、TrustPulse、PushEngage という 3 つのプラグインだ。いずれも単体で配布されているほか、MonsterInsights Pro にバンドル（同梱）されて提供されている。注目すべきは、有効化していなくてもプラグインとして存在するだけで攻撃対象になった点だ。WordPress はプラグインを無効化しても、ファイル自体はサーバー上に残る。攻撃者はそのファイルに含まれる脆弱性を利用して外部からコードを実行し、管理者アカウントの新規作成や Cloudflare／ClearFake マルウェアの設置を行った。

無料版の Wordfence では検知できなかったケースが確認されている。シグネチャ（攻撃パターン）が更新されるまでの時間差や、攻撃手法が亜種に変化していたことが原因とみられる。そのため、目視での確認が不可欠だ。

侵入前 プラグインが無効で放置、ファイルはサーバー上に存在
↓
侵入後 不明な管理者アカウントが追加され、不正な PHP ファイルが設置される
■ 侵入前（ファイルはあるが無害に見える）　■ 侵入後（管理者アカウントやマルウェアが追加される）

このデモは、プラグインファイルが放置された状態から攻撃者が侵入し、追加の不正な要素を仕込む流れを示している。

自分のサイトが影響を受けているか確認する手順

自分のサイトが影響を受けているか確認する手順

管理者アカウントの一覧を調べる

WordPress 管理画面の「ユーザー」→「すべてのユーザー」を開き、覚えのない管理者権限のアカウントが追加されていないかを確認する。アカウント名やメールアドレスに覚えがないもの、登録日時が直近のものがあれば要注意だ。

プラグインフォルダに不審な PHP ファイルがないか調べる

FTP ソフトやレンタルサーバーのファイルマネージャーで /wp-content/plugins/ 以下を開く。特に OptinMonster、TrustPulse、PushEngage のフォルダ内に、本来あるはずのない名前の PHP ファイルや、暗号化されたような文字列が書かれたファイルがないかを確認する。

プラグインをすでに削除してしまった場合でも、/wp-content/ 直下や /wp-includes/、テーマフォルダ内に不審な PHP ファイルが残っていないか、更新日時が最近のものに心当たりがないかを見ておくとよい。

STEP 1 管理画面「ユーザー」で管理者アカウントを確認
↓
STEP 2 FTP で /wp-content/plugins/ 以下の不審ファイルを調査
↓
STEP 3 .htaccess や wp-config.php に追記がないかも確認

管理者アカウントとファイルの両面から、侵入の痕跡を短時間で洗い出す手順を示している。

不正アクセスが発覚した場合の緊急対応

不正アクセスが発覚した場合の緊急対応

不正な管理者アカウントを即座に削除する

覚えのない管理者アカウントを見つけたら、すぐにそのユーザーを削除する。削除時に「すべての投稿を帰属させる」選択肢が出るが、攻撃者が作成した投稿や固定ページがなければそのまま削除してよい。念のため、削除前にゴミ箱や下書きに不審なコンテンツがないかも確認しておく。

不正ファイルを削除し、該当プラグインを完全に除去する

不審な PHP ファイルは必ずバックアップを取った上で削除する。OptinMonster、TrustPulse、PushEngage のいずれかがインストールされているなら、今後も脆弱性が残る可能性を考え、プラグイン自体を完全に削除するのが安全だ。同梱元の MonsterInsights Pro を利用している場合も、これらのアドオンが自動でインストールされていないか確認する。

サイト全体のマルウェアスキャンを実施する

Wordfence や Sucuri などのセキュリティプラグインで手動の詳細スキャンを実行する。無料版の自動スキャンだけでは検知漏れが起こる可能性があるため、手動でフルスキャンをかける。Sucuri のサイトチェック（外部スキャナ）を併用すると、サーバー内部からは見えにくい改ざんも検出しやすくなる。

再発防止と今後のセキュリティ対策

再発防止と今後のセキュリティ対策

使用していないプラグインやテーマは「無効化」ではなく「削除」する

WordPress では、プラグインを無効化してもファイルはサーバー上に残り続ける。今回の事例が示すように、無効状態でもファイルが存在するだけで攻撃の足場になる。今後は使わないと判断したプラグインやテーマは、面倒でも完全に削除する習慣をつけるのが鉄則だ。

プラグインの更新を常に最新に保ち、導入元を精査する

公式リポジトリ外のプラグインや、長期間更新が止まっているものはリスクが高い。どうしても必要な場合を除き、信頼できる提供元のものだけを使う。自動更新を有効にしておくと、脆弱性が公表された直後の修正パッチを適用しやすくなる。

定期的な管理者アカウントとファイルの監査を組み込む

月に一度は「ユーザー一覧」を開き、見慣れないアカウントがないかを目視点検する。あわせて、サーバーのファイル更新日時を確認し、心当たりのないタイミングで変更されたファイルがないかをチェックする。人が目で見る作業は、自動ツールの検知漏れを補う最後の砦になる。

よくある質問

無効化していてもなぜハッキングされたのか

無効化はあくまでプラグインの動作を止めるだけで、ファイルはそのままサーバーに残る。今回の攻撃はファイルの存在を前提に外部から直接コードを実行する手法だったため、有効か無効かは関係なく被害が発生した。

Wordfence が入っていれば安心なのか

今回の事案では、無料版 Wordfence で検知できなかった例がある。セキュリティプラグインに過度な期待をせず、定期的な手動確認と不要なファイルの削除を組み合わせることが欠かせない。

MonsterInsights を使っているが該当プラグインは入れていない

MonsterInsights Pro の一部バージョンでは、これらのプラグインが同梱されて自動インストールされる場合がある。プラグイン一覧を開き、OptinMonster、TrustPulse、PushEngage が存在しないか今一度確認してほしい。

すでに削除したが、まだ不安が残る場合の最終確認方法は

レンタルサーバーの管理画面で最近のアクセスログを確認し、不審な IP アドレスや POST リクエストがないかを調べる。データベースの wp_users テーブルと wp_usermeta テーブルを直接 SQL で確認し、管理者権限（wp_capabilities に administrator を含む）のユーザーに不明なものがないかを調べる方法も有効だ。

この記事のポイント

  • OptinMonster、TrustPulse、PushEngage は無効化でも攻撃対象になる
  • 管理者一覧とプラグインフォルダをすぐに目視確認する
  • 不正アカウントと不審ファイルは即座に削除する
  • 今後は使わないプラグインを無効化で放置せず完全削除する
  • セキュリティプラグインだけに頼らず定期手動監査を組み込む
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
プラグイン更新後に管理画面が真っ白になった時の原因と直し方
2026年7月3日 0

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

プラグイン更新直後に管理画面が真っ白になりエラー表示された場合、FTP で該当プラグインフォルダをリネームして無効化すればすぐに復旧する。特に Groovy Menu 無料版 1.4.7 で発生する `Call to undefined method GroovyMenuSettings::dashboard()` エラーでは、PHP の未定義メソッドが呼ばれているため管理画面が表示できなくなる。

なぜプラグイン更新で管理画面がクラッシュするのか

なぜプラグイン更新で管理画面がクラッシュするのか

原因はプラグイン更新後のコードに含まれる不具合だ。今回のケースでは GroovyMenuSettings クラスに `dashboard()` メソッドが存在しないのに `render()` から呼び出そうとしたため、PHP の致命的なエラーが発生した。これにより WordPress のフック処理が中断され、管理画面が表示されない「重大なエラー」画面に切り替わる。

この種のエラーは特定のプラグインに限らず、バージョンアップ時の関数名の誤りや非互換の変更が原因でよく起こる。Query Monitor などのデバッグプラグインを入れていると、エラーメッセージとコールスタックが確認できる。

管理画面を復旧させる具体的な手順

管理画面を復旧させる具体的な手順

最も確実な方法は、FTP クライアントまたはサーバーのファイルマネージャーを使って問題のプラグインフォルダ名を変更し、WordPress にそのプラグインを無効化させることだ。以下の手順で行う。

STEP 1 FTP クライアントでサーバーに接続する
↓
STEP 2 /wp-content/plugins/ ディレクトリに移動する
↓
STEP 3 問題のフォルダ（例 groovy-menu-free）を右クリック →「名前の変更」
↓
STEP 4 末尾に -disabled など任意の文字列を付けてリネームする
↓
結果 管理画面を再読み込みすると正常に表示される。サイト表側も問題がなければ動作する。

上のデモは Groovy Menu 無料版の例だ。フォルダ名変更によって WordPress が「プラグインが見つからない」と解釈し、自動的に無効化してエラーループから抜け出せる。

FTP が使えない場合の代替方法

  • レンタルサーバーの管理パネル（コントロールパネル）にログインする
  • 「ファイルマネージャー」機能を開き、上記と同じ操作でフォルダ名を変更する
  • フォルダ名を変えたら管理画面にアクセスし、復旧を確認する

FTP もファイルマネージャーも使えない時のデータベース無効化

FTP もファイルマネージャーも使えない時のデータベース無効化

サーバーの制限で上記の操作ができない場合、WordPress のデータベースに直接アクセスしてプラグインを無効化する手段がある。

STEP 1 phpMyAdmin または管理パネルのデータベース管理画面を開く
↓
STEP 2 wp_options テーブルを選択し、option_name が active_plugins の行を探す
↓
STEP 3 option_value カラムの編集画面を開き、一時的に値を空文字列 "" に変更して保存する
↓
結果 管理画面にアクセスできるようになる。その後、プラグイン一覧画面で改めて必要なプラグインだけを有効化する。

データベースを直接操作するとリスクが伴うため、作業前に必ずバックアップを取得しておく。正常に管理画面へ入れるようになったら、すぐに問題のプラグインを削除するか、安定版がリリースされるまで更新を控える判断が必要になる。

同じトラブルを防ぐための再発防止策

同じトラブルを防ぐための再発防止策

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

プラグイン更新を本番サイトに適用する前に、ステージング環境（本番と同じ構成のテストサイト）で動作確認を行うとトラブルを未然に防げる。多くの国内レンタルサーバーではワンクリックでステージングを作成できる機能が提供されている。

自動更新を制御する

WordPress の管理画面ではプラグインごとに自動更新のオン／オフを設定できる。信頼性の高いプラグインだけ自動更新を許可し、不安定なアップデートが多いものは手動更新に切り替えておくと安全だ。

定期バックアップとデバッグモードの活用

更新前にプラグイン一覧とデータベースをバックアップしておけば、万一の問題発生時にも迅速にロールバックできる。また、`wp-config.php` で `WP_DEBUG` を `true` に設定すると詳細なエラー内容が表示され、原因特定が容易になる。ただし本番公開サイトでは普段は `false` に戻しておく。

よくある質問

プラグインを無効化したらサイトの表示が崩れたがどうすればいい？

無効化によってメニューやレイアウトが一時的に変わることはあるが、管理画面が復旧した時点で別のバージョンのプラグインを再インストールすれば元に戻せる。必ず復旧後に適切なバージョンを入れ直すことが前提だ。

エラーログの確認方法は？

FTP で `wp-content/debug.log` が生成されていればダウンロードして確認できる。なければ `wp-config.php` に `define(‘WP_DEBUG_LOG’, true);` を追加してエラーを記録すると、後から詳しい原因を読み取れる。

フォルダ名を変更しても直らない時は？

キャッシュ系プラグインやサーバー側のキャッシュが残っている可能性がある。ブラウザキャッシュのクリア、CDN のキャッシュ削除、サーバーキャッシュのクリア（管理パネルに機能があれば）を順に試すと改善しやすい。

プラグイン開発者が修正版を出すまで待つしかないのか？

問題のバージョンを避けて1つ前の安定版を手動で上書きアップロードすれば一時的に復旧できる。公式リポジトリの「以前のバージョン」から ZIP ファイルを入手し、FTP で上書きすると過去の状態に戻せる。

この記事のポイント

  • プラグイン更新後の管理画面クラッシュは、該当フォルダのリネームで直ちに復旧できる
  • FTP が使えなくてもファイルマネージャーやデータベース操作で対処可能
  • 原因は未定義メソッドの呼び出しで、デバッグログで特定できる
  • ステージング環境での事前テストと定期バックアップが最も有効な予防策
佐々木 太陽
, , , ,
お悩み・トラブル解決
Events Manager更新後に公開イベントが下書きに戻る原因と修正
2026年7月3日 0

Events Manager更新後に公開イベントが下書きに戻る原因と修正

Events Manager 7.3.7.4 にアップデート後、公開済みイベントの編集画面で「更新」をクリックすると、ステータスが「下書き」に戻ってしまう現象が報告されている。原因は、終日設定のイベントに対してタイムレンジ（時間範囲）が重複してデータベースに登録されてしまうことだ。このバグにより、プラグイン内部のバリデーションが失敗し、自動的に下書きへと巻き戻される。データベースの重複を削除し、プラグインファイルに一時的なパッチをあてることで解決する。

なぜ公開済みイベントが更新時に下書きに戻ってしまうのか

なぜ公開済みイベントが更新時に下書きに戻ってしまうのか

Events Manager はイベントを表す EM_Event クラスが、記事が保存される前に validate_meta() メソッドで内部データの整合性をチェックしている。このチェックに引っかかると wp_insert_post_data フックが介入し、投稿ステータスを強制的に「下書き」に変更する仕様だ。

今回の問題では、「Timeranges cannot overlap with each other.（タイムレンジが重複しています）」というエラーが発生している。しかし、エディタ上では終日（All Day）設定の単一の時間範囲しか表示されていない。実際にデバッグ出力を取得すると、同一イベントに属する同一の終日タイムレンジ（開始 00:00:00、終了 23:59:59）が2件存在しており、これが重複エラーの直接的な原因だ。

データベースで重複したタイムレンジを削除する手順

データベースで重複したタイムレンジを削除する手順
STEP 1 phpMyAdmin でデータベースのバックアップを取得する
↓
STEP 2 重複を検出するSQLクエリを実行する
↓
STEP 3 古い重複行を安全に削除する
↓
STEP 4 イベント編集画面で「更新」して正常化を確認する

STEP 1：必ずデータベースをバックアップする

今回の作業ではデータを直接操作するため、必ず事前にデータベース全体のエクスポートを取得する。何か問題が起きても元に戻せるようにしておこう。

STEP 2：重複タイムレンジを検出する

テーブル名はプラグインの設定により異なるが、多くは wp_em_timeranges となる。phpMyAdmin のSQLタブで次のクエリを実行し、同一 event_id・同一 timerange_start・timerange_end の組み合わせが複数存在しないか確認する。

SELECT event_id, timerange_start, timerange_end, COUNT(*)
FROM wp_em_timeranges
GROUP BY event_id, timerange_start, timerange_end
HAVING COUNT(*) > 1;

結果が返ってきたら、該当の event_id をメモしておく。

STEP 3：重複行のうち一方を削除する

重複している行のうち、より古いIDの行を削除する。以下のクエリは最も小さい ID 以外を削除する例だ。必ず削除対象を SELECT で事前確認してから実行する。

DELETE t1 FROM wp_em_timeranges t1
INNER JOIN wp_em_timeranges t2
WHERE t1.timerange_start = t2.timerange_start
AND t1.timerange_end = t2.timerange_end
AND t1.event_id = t2.event_id
AND t1.ID > t2.ID;

STEP 4：イベントを再編集して正常に保存されるか確認する

データベースの重複を除いたら、WordPress管理画面に戻り、該当のイベント編集画面を開く。内容を微修正して「更新」をクリックし、再び「下書き」に戻らず公開状態が維持されることを確かめる。

プラグインファイルの一時修正で重複登録を防ぐ

プラグインファイルの一時修正で重複登録を防ぐ

根本的な原因は、何らかのトリガーでタイムレンジオブジェクトが二重に追加されてしまうことだ。以下は EM_Event::validate_meta() の中で重複を除去する応急処置のコード例だ。必ずファイルのバックアップを取ったうえで追記する。

// events-manager/classes/em-event.php の validate_meta メソッド内
public function validate_meta( $data, $postarr ) {
    // タイムレンジを取得して重複を排除する
    $timeranges = $this->get_timeranges();
    $unique_timeranges = [];
    foreach ( $timeranges as $timerange ) {
        // timerange_group_id などのキーで一意にする
        $key = $timerange->timerange_group_id . '_' . $timerange->timerange_start . '_' . $timerange->timerange_end;
        if ( ! isset( $unique_timeranges[ $key ] ) ) {
            $unique_timeranges[ $key ] = $timerange;
        }
    }
    // 重複排除済みのコレクションでバリデーション
    if ( ! $unique_timeranges || ! $this->validate_timeranges_collection( $unique_timeranges ) ) {
        // エラー処理...
    }
    // 以下略
}

ただし、このパッチはあくまで暫定的なものだ。プラグインが公式に修正をリリースするまでは、更新のたびに再適用が必要になる。公式サポートフォーラムを定期的に確認し、バグ修正版がリリースされたら速やかにアップデートしよう。

よくある質問

この問題はイベントマネージャーのどのバージョンから発生したのか

少なくとも 7.3.7.4 で報告されている。それ以前のバージョンでは発生していなかった可能性が高いが、同様の重複が偶発的に起きているケースもある。

クラシックエディターを使えば回避できるか

根本原因はデータ保存時のバリデーションにあるため、グーテンベルクエディターかクラシックエディターかは関係ない。ただし、編集画面のUIの違いでトリガーが変わる可能性は否定できない。試す価値はある。

終日イベント以外でも起こるのか

現在報告されているのは終日設定時のケースだ。しかし、時間指定のあるイベントでも重複が起きれば同じエラーで下書きに戻る。該当イベントの編集時は要注意だ。

データベースを直接触らずに直す方法はあるか

現時点では、管理画面から重複を操作できる機能はない。比較的安全な方法としては、一度イベントを複製→元のイベントを削除→複製イベントを公開する、という手順でタイムレンジが正常な状態になることがある。

公式の修正はいつリリースされるのか

これはバグトラッカーや公式フォーラムを見守るしかない。開発チームが認識している問題であれば、次のパッチに含まれる可能性がある。

この記事のポイント

  • Events Manager 7.3.7.4 で発生する既知のバグで、バリデーションエラーによってステータスが下書きに変更される
  • 原因は終日イベントのタイムレンジがデータベース上で重複していること
  • phpMyAdmin から重複行を削除することで一時的に解決する
  • プラグインファイルの修正パッチで再発を防げるが、公式アップデートまでは注意が必要
  • データベース操作前には必ずバックアップを取得する
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WordPress更新後にサイトが完全にダウンした時の復旧手順
2026年7月2日 0

WordPress更新後にサイトが完全にダウンした時の復旧手順

プラグインやテーマの更新後にサイト全体がダウンし「このサイトで重大なエラーが発生しました」と表示される場合、多くの原因は .htaccess に書き込まれた不適切な指示がサーバー設定と衝突していることにある。FTP / SFTP でサーバーに接続し .htaccess から問題の行を削除するかファイルを一旦削除したあと、WordPress 管理画面でパーマリンク設定を再保存すれば復旧できる。

更新後にサイトが完全にダウンする仕組み

更新後にサイトが完全にダウンする仕組み

一部のプラグインやテーマは、更新時にパフォーマンス向上や URL の取り回しを目的として .htaccess に独自のルールを自動挿入する。これがサーバーの許容範囲を超えると、Apache が起動時に設定ファイルを解釈できず「500 Internal Server Error」を返し、フロントエンドも管理画面もアクセス不能になる。

典型的なのが Option MultiViews のような指示を勝手に追記するケースだ。この機能は Apache のコンテントネゴシエーション（ファイル名の拡張子を自動補完してリクエストを解決する仕組み）を有効にするが、レンタルサーバーや共用ホスティングではセキュリティとルーティングの競合を防ぐために AllowOverride で無効化されていることが多い。許可されていない場所に書かれた Option MultiViews は「ここでは許可されていません」というサーバーエラーを引き起こし、サイト全体を落とす。

WordPress 本体の更新ではこのような追記はほぼ発生しない。問題が起きるのは、更新と同時に .htaccess を操作する一部のキャッシュ系プラグイン、セキュリティ系プラグイン、多言語プラグインだ。プラグイン開発者のテスト環境と本番サーバーの設定が異なるために発生する「動作確認済み」とされる更新でも、自分の環境では致命的になることがある。

.htaccess のエラーでアクセス不能になった時の復旧手順

.htaccess のエラーでアクセス不能になった時の復旧手順
STEP 1 FTP クライアントやサーバーのファイルマネージャでサイトに接続する
↓
STEP 2 WordPress インストールディレクトリ直下の .htaccess をダウンロードしてバックアップする
↓
STEP 3 問題の行（例 Option MultiViews）を削除するか .htaccess を一旦削除する
↓
STEP 4 WordPress 管理画面にログインし「設定」→「パーマリンク」を開いて「変更を保存」をクリックする

FTP 接続と .htaccess の場所を確認する

まずは FTP クライアント（FileZilla など）や契約中のサーバーが提供するファイルマネージャでサーバーに接続する。WordPress をインストールしたディレクトリ（多くの場合は public_html か httpdocs）を開き、直下に .htaccess というファイルがあるかを確認する。ドットで始まるファイルはデフォルトで非表示になっている場合があるので、FTP クライアントの設定で隠しファイルを表示するように切り替える必要がある。

エラーログを確認して原因行を特定する（可能な場合）

サーバーのエラーログを見られれば原因の特定は早い。cPanel やコントロールパネルに「エラーログ」または「Error Log」という項目があるので、直近のエントリを確認する。今回のようなケースでは .htaccess: Option MultiViews not allowed here というエラーメッセージが記録されている。この行がログに残っていれば .htaccess 内の Option MultiViews を含む行やブロックを削除するだけで復旧する可能性が高い。

Before（問題のある .htaccess）
# BEGIN WordPress
…
Option MultiViews
…
# END WordPress
↓
After（該当行を削除）
# BEGIN WordPress
…
…
# END WordPress
■ エラーを引き起こす行　■ 削除後

.htaccess を削除して WordPress に再生成させる方法

エラーログを確認できない場合や問題の行を特定できない場合は .htaccess を一旦削除してしまうのが手っ取り早い。削除する前に必ずファイルをダウンロードして手元にバックアップを取っておく。削除後、サイトが表示されるようになったら WordPress 管理画面の「設定」→「パーマリンク」を開き、何も変更せずに「変更を保存」ボタンを押す。これで WordPress が必要最小限の .htaccess を自動生成する。

パーマリンク設定を保存して再生成された .htaccess には WordPress の標準ルールだけが書かれているため、問題を引き起こしていた余計な指示は含まれない。この状態でサイトが正常動作していれば復旧成功だ。

原因となったプラグインの特定と対処

.htaccess を修正しても、問題のプラグインをそのままにしておくと再度更新が走ったときや設定変更時に同じことが起きる。更新直前にどのプラグインやテーマを更新したかを確認し、該当するものを一時的に無効化しておく。

管理画面に入れるなら「プラグイン」画面から該当プラグインを停止する。管理画面にも入れない場合は、FTP で /wp-content/plugins/ ディレクトリにアクセスし、該当プラグインのフォルダごと名前を変更する（例: plugin-name を plugin-name-disabled にする）。これでプラグインが強制的に無効化され、管理画面にアクセスできるようになる。

.htaccess を修正しても直らない場合の追加対応

.htaccess を修正しても直らない場合の追加対応

ブラウザキャッシュとサーバーキャッシュをすべて削除する

.htaccess を修正してもまだエラー画面が表示される場合、キャッシュが古いエラー状態を保持している可能性がある。ブラウザのキャッシュを削除し、サーバー側で Varnish や OPcache などのキャッシュ機構が動いている場合はそれらもクリアする。コントロールパネルにキャッシュ管理機能があればそこから削除し、WordPress 用のキャッシュプラグインを導入しているなら FTP で /wp-content/cache/ ディレクトリの中身を手動で削除する。

全プラグインを強制無効化して標準テーマに切り替える

.htaccess の問題ではなく、更新されたプラグインやテーマのコードそのものが PHP の致命的エラーを起こしている可能性もある。FTP で /wp-content/plugins/ フォルダ全体を plugins-temp などにリネームし、使用中のテーマ（/wp-content/themes/テーマ名）もリネームする。WordPress はプラグインがなくても動作し、有効なテーマがない場合は標準テーマ（Twenty Twenty-Five など）に自動でフォールバックする。これで管理画面に入れれば、あとは問題のプラグインやテーマを一つずつ戻して原因を絞り込む。

サーバー会社に AllowOverride 設定を確認する

Option MultiViews のような指示がサーバー側でどう扱われるかは Apache の AllowOverride 設定で決まる。自前で httpd.conf やバーチャルホスト設定を編集できない共用サーバーでは、サーバー会社に「.htaccess に Option MultiViews を記述したところサイト全体が停止した。この指示を許可する設定に変更できるか」と問い合わせる手段もある。ただしセキュリティ上の理由で許可されないケースが大半なので、その場合はプラグインの設定を見直すか、代替プラグインを検討する必要がある。

更新による .htaccess 破損を防ぐための対策

更新による .htaccess 破損を防ぐための対策
更新前 必ずサイト全体と .htaccess をバックアップする
更新時 可能ならステージング環境で先にテストする
更新後 即座にサイト全体が表示されるか確認し、問題があれば即座にロールバックする

更新前にかならずバックアップを取る習慣をつける

WordPress 本体、プラグイン、テーマのいずれを更新する場合でも、更新前にサイト全体とデータベースのバックアップを取ることは最も基本的で強力な防御策だ。.htaccess も設定ファイルの一つとしてバックアップ対象に含めておく。バックアップがあれば、今回のようにサイトが完全にダウンしても数分で元の状態に戻せる。

ステージング環境で事前に検証する

本番環境に直接更新を適用する前に、ステージング環境（本番と同一のサーバー設定を持つテストサイト）で動作確認を行うことで、.htaccess の競合や PHP エラーを事前に検出できる。多くの国内レンタルサーバーはコントロールパネルから簡単にステージングサイトを作成できる機能を提供している。少なくとも重要なプラグインのメジャーアップデートでは、このステップを踏むことで大規模なダウンを回避できる。

プラグインの変更履歴を確認し .htaccess 操作の有無を把握する

更新前にプラグインの変更履歴（Changelog）を確認する習慣も有効だ。特に「Improved .htaccess rules」「Added server-level optimizations」などの記述がある場合は要注意で、更新後に .htaccess が書き換わる可能性が高い。こうした更新は必ずバックアップを取ったうえで適用し、適用直後に .htaccess の内容を確認して想定外の追記がされていないかチェックする。

よくある質問

更新後に管理画面だけでなくフロントエンドも真っ白になるのはなぜか

.htaccess のエラーは PHP の処理に入る手前のサーバーレベルで発生するため、WordPress のエラーハンドリング機構が一切働かない。結果としてフロントエンドも管理画面も同じ「500 Internal Server Error」や真っ白な画面になり、WordPress のデバッグモードでもエラーメッセージが表示されないことが多い。

.htaccess を削除しても問題ないのか

WordPress のパーマリンク設定を保存すれば必要なルールは自動で再生成されるので、.htaccess の削除自体は安全だ。ただし独自に追加したリダイレクトルールや BASIC 認証設定などがある場合はバックアップから手動で戻す必要がある。

FTP でサーバーに接続できない場合はどうすればよいか

サーバー会社が提供するコントロールパネル（cPanel など）のファイルマネージャが使えるかを確認する。多くの場合ブラウザから直接ファイルを編集できる。それも使えない状況であればサーバー会社のサポートに連絡し「.htaccess の特定の行を削除してほしい」と依頼するのが最も早い復旧手段になる。

今回のエラーはプラグインの不具合なのか

厳密にはプラグインのコードに問題があるというより、プラグインが想定するサーバー環境と実際のサーバー設定の不一致によって発生する。プラグイン開発者が Option MultiViews が許可されている環境で開発し、許可されていない共用サーバーでエラーが出るケースが典型だ。したがって「不具合」というより環境依存の問題と呼ぶ方が実態に近い。

同じ問題を起こさないために .htaccess をロックできるか

ファイルのパーミッションを 444（読み取り専用）に設定すれば外部からの書き込みは防げるが、WordPress 本体やプラグインが正当な理由で .htaccess を更新する必要がある場合にエラーの原因となる。現実的な対策は、書き換えが発生する更新の前にバックアップを取り、更新後に diff を取って差分を確認する運用だ。

この記事のポイント

  • .htaccess への不適切な追記が更新後のサイトダウンの直接原因になりやすい
  • FTP で問題の行を削除するか .htaccess を一旦削除すれば即座に復旧できる
  • 削除後は管理画面のパーマリンク設定で必要最小限の .htaccess を再生成する
  • 原因プラグインを特定し無効化しないと再発するため忘れずに対処する
  • 更新前のバックアップとステージング検証が最も確実な予防策になる
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
Advanced Ads 2.0.23 アップデート後の致命的エラーの直し方
2026年7月1日 0

Advanced Ads 2.0.23 アップデート後の致命的エラーの直し方

Advanced Ads 2.0.23 にアップデートした途端に「このサイトで重大なエラーが発生しました」と表示される問題は、Pro版のキャッシュバスティング機能が原因だ。管理画面にアクセスできなければ、FTP またはファイルマネージャーでプラグインを手動で一時無効化し、バージョンを 2.0.22 に戻せば即座に復旧する。

なぜ Advanced Ads 2.0.23 で致命的エラーが起こるのか

なぜ Advanced Ads 2.0.23 で致命的エラーが起こるのか

エラーの直接の原因は、Advanced Ads のコアプラグイン側にある abstract-group.php の 170 行目で、Pro版のキャッシュバスティングモジュールから渡された配列データの型を正しく取り扱えず、TypeError が発生している点だ。PHP 8.4 系の厳格な型チェックによって、以前のバージョンでは警告で済んでいた箇所が致命的エラーに変わった。

内部的には、get_ad_weights メソッドが想定するデータ構造と、キャッシュバスティングが上書きしたグループ情報との間で不整合が起きている。とくに広告グループの重み付け配列に対して isset や empty でアクセスしようとした際に、オフセットとして配列そのものを渡してしまう形になり、PHP が型エラーを投げている。

Before（エラー状態）
Advanced Ads 2.0.23 + Pro キャッシュバスティング有効
→ 「このサイトで重大なエラーが発生しました」
↓
After（解決後）
Advanced Ads 2.0.22 にロールバック
→ サイトが正常表示される
■ エラー状態　■ 修正後

上記のデモは、キャッシュバスティング機能が有効な状態でのエラー発生と、プラグインのダウングレードによる復旧の流れを表している。

管理画面にアクセスできない場合の緊急復旧手順

致命的エラーによって WordPress 管理画面にもログインできない状態では、ブラウザ上の操作だけで問題を解消できない。FTP クライアントか、レンタルサーバーのファイルマネージャーを使ってサーバー上のファイルを直接操作する。

FTP またはファイルマネージャーでプラグインを一時無効化する

サーバーに接続したら、/wp-content/plugins/ ディレクトリへ移動する。ここで advanced-ads フォルダと advanced-ads-pro フォルダの名前を変更する。フォルダ名の末尾に -disabled を付与すれば、WordPress はそのプラグインを認識しなくなり、エラーが止まる。

フォルダ名の変更例は次のとおりだ。
advanced-ads → advanced-ads-disabled
advanced-ads-pro → advanced-ads-pro-disabled

この状態でサイトのフロントエンドにアクセスすると、致命的エラーは出なくなる。ただし広告が一切表示されない点に注意する。次に管理画面へ入れるようになるので、続けてプラグインのバージョンロールバックを行う。

Advanced Ads をバージョン 2.0.22 に戻す

まず FTP でリネームした advanced-ads-disabled フォルダを元の advanced-ads に戻す。Pro版の advanced-ads-pro-disabled は、まだ無効化されたままにしておく。この操作で Advanced Ads の基本プラグインだけが有効化された状態になる。

管理画面にログインし、「Advanced Ads」→「ツール」→「バージョン管理」へ進む。ここでバージョン 2.0.22 を選択し、ロールバックを実行する。ロールバック完了後、Pro版のフォルダ名を元に戻して有効化すれば、2.0.22 の組み合わせで通常運用に復旧できる。

STEP 1 FTP で advanced-ads フォルダと advanced-ads-pro フォルダをリネーム（末尾に -disabled）
↓
STEP 2 advanced-ads フォルダのみ元の名前に戻す（Pro版は無効のまま）
↓
STEP 3 管理画面「ツール」→「バージョン管理」で 2.0.22 にロールバック
↓
STEP 4 Pro版のフォルダ名も元に戻し、有効化して復旧完了

この一連の手順で、管理画面に入れない状態からでも確実にサイトを復旧できる。

キャッシュバスティングを無効化して一時しのぎする方法

キャッシュバスティングを無効化して一時しのぎする方法

管理画面にアクセスできる状態であれば、Pro版のキャッシュバスティング機能をオフにするだけで致命的エラーを回避できる。Advanced Ads Pro の設定画面を開き、「キャッシュバスティング」セクションのトグルを無効化する。これにより cache-busting.class.php の処理が走らなくなり、エラーの発生箇所が呼び出されない。

無効化後にサイトのフロントエンドを再読み込みして、エラーが消えたことを確認する。この方法はあくまで応急処置であり、根本的な修正が公式から提供されるまではキャッシュバスティング機能を使えない点に留意する。広告のインプレッション計測や表示の最適化に影響が出るため、修正版のリリースを待つか、前述のロールバックを適用するほうが望ましい。

PHP 8.4 環境で注意すべきエラーの傾向

PHP 8.4 では、配列オフセットに対する型の取り扱いがさらに厳格化された。今回のエラーも、Cannot access offset of type array in isset or empty というメッセージにあるとおり、配列を別の配列のキーとして使おうとしたコードがエラーになっている。PHP 7.x 系では E_WARNING で済んでいたコードが、8.x 系では TypeError の致命的エラーに格上げされるケースが増えている。

TagDiv Newspaper のような複合的なテーマとビルダー系プラグインを併用している環境では、テーマが内部的にウィジェットブロックを動的サイドバーとしてレンダリングし、その中で Advanced Ads の広告配置が呼び出される。この呼び出し階層が深いほど、わずかな型の不整合がスタックトレース全体を巻き込む致命的エラーに発展しやすい。エラーログのスタックトレースを読むときは、一番上の発生行だけでなく、そのひとつ下の呼び出し元との関係に着目すると原因特定が早まる。

よくある質問

2.0.23 にアップデートしたあとサイト全体が真っ白になるのは同じ原因か

同じ可能性が高い。とくに Pro版のキャッシュバスティングを有効にしている場合、このエラーが発生する。画面が真っ白になるのは PHP の致命的エラーによって WordPress の表示処理が途中で停止しているためだ。サーバーのエラーログを確認すると、今回と同じ TypeError が記録されているはずだ。

ロールバック機能が管理画面から使えないときはどうすればよいか

FTP でプラグインフォルダをリネームして一時無効化し、コアプラグインだけを有効にして管理画面にアクセスできる状態を作る。そのうえで「バージョン管理」からロールバックを実行する。どうしても管理画面に入れない場合は、WordPress 公式プラグインディレクトリから 2.0.22 の ZIP を手動でダウンロードし、FTP で上書きアップロードする方法でもダウングレードできる。

Pro版のキャッシュバスティングを無効にすると広告収益にどの程度影響があるか

キャッシュバスティングは広告の表示を毎回動的に変えることでキャッシュによる同一広告の連続表示を防ぐ仕組みだ。無効化すると、ページキャッシュが効いた状態では同じ広告が繰り返し表示される可能性が高まり、インプレッションの多様性が下がる。短期的な暫定対処としては許容できるが、修正版リリース後は必ず再有効化するほうがよい。

今回のエラーは Advanced Ads 無料版だけでも発生するのか

エラーの起点はコアプラグインの abstract-group.php だが、実際に問題を引き起こしているのは Pro版のキャッシュバスティングモジュールだ。無料版のみの利用では通常発生しない。ただし同じ PHP 8.4 環境で他のアドオンを使っている場合は、類似の型エラーに注意が必要だ。

この記事のポイント

  • Advanced Ads 2.0.23 + Pro キャッシュバスティングの組み合わせで発生する
  • 管理画面にアクセスできないときは FTP でプラグインフォルダをリネームして無効化する
  • コアプラグインを 2.0.22 にロールバックすれば復旧できる
  • キャッシュバスティングの無効化は暫定対処であり根本解決にはならない
  • PHP 8.4 の厳格な型チェックがエラーの引き金になっている
佐々木 太陽
, , , ,
お悩み・トラブル解決
プラグイン更新後に管理画面が真っ白になった時の原因と直し方
2026年6月30日 0

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

このエラーはプラグイン開発側の不具合によるものだ。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-content → plugins と進む。今回の事例では「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/ 内の該当フォルダをリネームする
  • 復旧後は開発者の修正状況を確認し、安全を確かめてからプラグインを再び有効化する
  • 日頃からステージングテストやバックアップを習慣化し、自動アップデートの対象を絞っておく
佐々木 太陽
, , , ,
お悩み・トラブル解決
LightSync ProでクリエイティブツールとWordPressを直接連携
2026年6月30日 0

LightSync ProでクリエイティブツールとWordPressを直接連携

LightSync Proとは何か

LightSync Proとは何か

LightSync Proは、クリエイティブツールとWordPressメディアライブラリを直接同期させるプラグインだ。LightroomやCanva、Figma、Dropboxといった「画像の発生源」をWordPressに一本化する。従来の「エクスポート→ダウンロード→再アップロード」という手間が消え、画像の取り込みと同時に最適化まで完了する仕組みになっている。

従来のフロー（Before）
Lightroom エクスポート → ダウンロードフォルダ を探す → WordPress にアップロード
※各画像を手動で処理するため、ミスや重複が発生しやすい
↓
LightSync Pro 導入後（After）
Lightroom → LightSync Pro → WordPress
※同期と最適化が自動で行われ、一括管理も可能

このデモで示した通り、画像を扱うすべての作業が「選んで同期を実行する」だけに変わる。WP Mayorの記事が伝えるこのツールの核心は、単なるファイル移動ではない。画像編集ツールと公開プラットフォームをつなぐ「見えないパイプライン」を構築するところにある。

技術的な差別化ポイント

技術的な差別化ポイント

認証情報をサイトに残さないブローカー型セキュリティ

通常、外部サービスと連携するプラグインはAPIキーをWordPressのデータベースに保存する。この方法はシンプルだが、サイトが侵害されたり、クライアントに引き渡す際に秘密情報の削除漏れといったリスクが常につきまとう。

LightSync Proはこの常識を覆す。WordPressインストールは、認証情報を保持する独立したブローカーとのみ通信する。LightroomやDropboxに直接APIキーを送ることはない。WP Mayorの記事によれば、このアーキテクチャは特許申請中（米国出願番号19/440,404）であり、技術的な独自性の高さを示している。

セキュリティフローの比較
従来の方式
WordPress ↔ 【APIキーを保持】 ↔ 外部サービス
LightSync Pro の方式
WordPress ↔ 【認証ブローカー】 ↔ 各種クリエイティブツール
■ リスク: APIキーがサイトDBに露出　 ■ 安全: キーは外部ブローカーが管理

この設計の真価は、複数サイトを管理する制作会社やフリーランスにとって特に大きい。クライアントサイトからAPIキーを引き剥がす手間、引き継ぎ時のセキュリティ説明といった地味に重い業務を根こそぎ排除できる。

「同期」は一度きりのインポートではない

多くのツールは「インポート」と「同期」を混同している。一度メディアを引っ張ってくるだけなら単なるコピーだ。真の課題は、Lightroomで再編集した写真やCanvaで修正したグラフィックを、どうWordPressに反映させるかにある。

LightSync Proでは、同期を再実行すると既存のファイルが更新される。画像の添付IDは変わらない。したがって、その画像を参照しているすべての投稿や固定ページ、テンプレートは自動的に最新版を表示する。WP Mayorの記事の著者も、画像の再アップロード後にリンク切れを修正する苦労を語っていたが、その問題を根本解決するロジックが、無料プランにも含まれているのは評価すべき点だ。

取り込みと同時の画像最適化

4MBのPNGファイルをそのままアップロードし、後から最適化プラグインを走らせる。この二度手間はWordPress運用のあるあるだ。LightSync Proは、画像をライブラリに取り込むブラウザ内のプロセスで、AVIFやWebP、JPEGへの変換と圧縮を同時に行う。

これにより、サイトに保存されるファイルは最初からWeb表示に適した状態になる。PageSpeed Insightsのスコアを下げる「大きすぎる画像」が、最初から生まれない仕組みだ。特にWooCommerceなど画像点数が膨大なサイトでは、サイトパフォーマンスと検索順位に直結する点を見逃せない。

注目すべき連携ソースと拡張性

注目すべき連携ソースと拡張性

対応するソースは、Lightroom、Dropbox、Figma、Shutterstockに加え、2026年4月にCanvaが追加された。クリエイティブワークの主要な「入口」をカバーしており、制作から公開までの導線を一本化するという製品思想が明確だ。

対応ソース一覧
Lightroom → Dropbox → Figma → Canva → Shutterstock
共通の出口 → WordPress メディアライブラリ
各ソースから直接インポートされ、AVIF/WebPに変換・圧縮される

今後対応ソースが拡大すれば、あらゆるビジュアル制作をWordPressに集約するハブとしての地位を固めるだろう。現時点で自分の使うツールが含まれていなくても、ロードマップや開発者へのリクエストを通じて将来性に期待できる。

AIによるメディア操作

AIによるメディア操作

2026年現在、最も実験的で将来性を感じさせるのがMCP（Model Context Protocol）を通じたAIアシスタント連携だ。Claudeのようなアシスタントに話しかけるだけで、接続されたソースを参照し、必要な画像をWordPressに取り込める。

STEP 1 ユーザーが「Lightroomの最新カタログからブログ用の写真を選んで」と指示
↓
STEP 2 AIアシスタント（Claude等）がMCPでLightSync Proを操作
↓
STEP 3 画像が自動でWordPressに同期・最適化される

操作は管理画面のクリックではなく「会話」に変わる。まだ登場したばかりの機能であり、WP Mayorの記事でも試行錯誤が必要と指摘されている。しかし、メディア管理の自動化という新たな次元をWordPressにもたらすことは間違いない。すでに業務フローにAIを取り入れているチームにとって、最初に試す価値のある野心的な機能といえる。

ライセンスと価格

ライセンスと価格

LightSync Proは3つのプランを提供している。

  • 無料プラン（LightSync Pro）: 無制限のアルバムと画像、全5ソース連携、AI画像生成（OpenRouter経由）、Shopify連携、自動WebP変換、最適化分析が含まれる。非常に寛大な無料提供だ。
  • Pro+（年額199ドル）: 自動同期、MCP経由のAIアシスタント、「ライブラリモード」「タスクビルダー」「ヒーローピッカー」、AVIF最適化、自動altテキスト生成、Google Search Console連携、A/B画像テストが追加される。
  • Agency（年額699ドル）: マルチサイト管理が必要な制作会社やマーケティングチーム向け。

無料プランだけでも基本的な同期とWebP変換が行えるため、個人ブロガーから小規模ビジネスまで導入ハードルは低い。Pro+でアンロックされるAVIF対応や自動altテキスト生成は、SEOや表示速度をシビアに管理したいサイトにとって費用対効果が高い。

誰が導入すべきか

誰が導入すべきか

LightroomやCanvaから画像を定期的にWordPressへ移しているなら、このプラグインは作業時間の大幅な短縮に直結する。特に制作会社はブローカー型セキュリティのメリットを、WooCommerce運用者は画像最適化の自動化によるパフォーマンス改善を、それぞれ評価するだろう。

記事で言及されていた「ヒーローピッカー」や「A/B画像テスト」といったPro+機能は、コンテンツマーケティングを数値で改善したい企業にとって魅力的だ。これらの機能は単なる省力化を超え、画像マーケティングの成果に踏み込むための装備といえる。

この記事のポイント

  • LightSync Proは主要クリエイティブツールとWordPressを直接同期する新プラグイン
  • 認証情報をブローカーに一元化し、サイトのDBにキーを残さない特許出願中のセキュリティ設計
  • 同期は上書き更新式で、既存の投稿やページ参照を壊さず最新画像を反映する
  • インポート時にAVIF/WebP変換と圧縮を行い、サイト高速化とSEOに貢献
  • MCP経由のAIアシスタント操作は、WordPressメディア管理の新たな自動化の可能性を示す
海田 洋祐
, , , , ,
WordPress
WordPressプラグインがAI検索で推奨される方法と獲得施策
2026年6月28日 0

WordPressプラグインがAI検索で推奨される方法と獲得施策

WordPressプラグインの購入検討者が、検索結果ページをスキップしてChatGPTやGeminiに直接「おすすめのバックアッププラグインは？」と質問する流れが広がっている。GoogleのAI Overviewも同様に、青いリンクをクリックせずに答えだけを見る行動が増えた。AI検索で自社製品が名前を挙げられなければ、その製品は存在しないに等しい。

この変化に対して「ブラックボックスを攻略するハック」は必要ない。WP Mayorの記事が紹介するAhrefsの最新調査からは、AIがツール推薦の情報源としている実態が明らかになった。Webサイト、ベストリスト記事、YouTubeが重要な役割を担っている。

本記事では、この調査データを紐解き、WordPressプラグインやテーマを提供する企業がAI推奨を獲得するための具体的な施策を解説する。

AI検索がプラグイン発見の重心を変えた

AI検索がプラグイン発見の重心を変えた
従来のプラグイン発見フロー（Before）
ユーザー Google検索 → 検索結果ページ → 複数サイトを見て比較 → プラグイン決定
検索エンジンのランキング上位表示が集客の主戦場だった
↓
AI検索時代のプラグイン発見フロー（After）
ユーザー ChatGPTなどに質問 → AIが推奨プラグイン名を提示 → リンクを辿らずにAIの回答で判断
AIに名前を挙げてもらえるかどうかが勝負

このデモは、従来の検索行動とAI検索の違いを概念的に示したものだ。青字の「ユーザー」部分は共通だが、情報収集のプロセスが大きく変わっている。

自社サイトの情報がAIの信頼基盤になる

AI検索が台頭しても、自社のWebサイトが「情報の原本」として扱われる点は変わらない。Googleが示すAI向けの最適化ガイドでも、クローラビリティの確保、実用的なコンテンツの作成、技術的な構造の整理、信頼性の証明をページ上部に配置することなど、基本中の基本が重視されている。

つまり、通常の検索ランキングで結果を出すための施策と、AIに引用されるための施策は地続きだ。派手な隠しスキーマや「アルゴリズムの裏をかく」手法は必要ない。ホームページや機能紹介ページで何をするプラグインか、誰の役に立つか、実績や証拠を明確に表現するだけで、AIは正確な情報を拾い上げる。

AIは「ベストリスト」記事から推薦を引き出す

Ahrefsの調査によれば、ChatGPTが回答のソースとして参照した26,283件のURLのうち、実に43.8％が「ベスト◯◯」形式のリスト記事だった。ベストバックアッププラグインやベストメンバーシッププラグインといった比較記事が、AIの推薦エンジンを支える主要な情報源になっている。

ベストバックアッププラグイン記事 → AIモデルが学習 → ChatGPTが「おすすめはプラグインA」と回答
Ahrefsの調査では、ChatGPTが参照したURLの43.8%がこの種のリスト記事だった。

この流れを考えれば、集客の目標設定も変わる。従来は「リスト記事で上位表示させてクリック流入を狙う」だったが、これからは「そのリストに掲載されることでAIの回答に名前が載る」ことこそがゴールになる。Ahrefsの分析によると、AI Overviewが表示される場合、最上位にランクしているページでもクリック率が約58%低下するという。AIが回答を先に出してしまうため、クリックを待つよりも推薦の中に自社プラグインが含まれている状態を目指すべきだ。

YouTubeがAIの隠れた情報源になっている理由

YouTubeがAIの隠れた情報源になっている理由

もうひとつ注目すべき発見が、YouTubeの言及とAI可視性の高い相関だ。Ahrefsが75,000のブランドを調べたところ、ChatGPTやAI Overviewでの可視性とYouTubeでの言及回数との相関係数は約0.737に達した。これは調査されたすべてのシグナルの中で最も強い数字だった。

相関と因果は別物だが、「動画コンテンツがAIに読まれている」というメカニズムは十分に説得力がある。YouTubeはAIにとって巨大な書き起こしデータベースだ。チュートリアルやデモ、レビュー動画、ポッドキャスト形式の対談、これらはすべて自動でテキスト化され、AIモデルが学習可能な情報になる。

YouTube動画
「メンバーシッププラグイン導入方法」のチュートリアル動画
↓
書き起こしテキスト
音声が自動でテキスト化され、AIが解析可能に
↓
AIモデルの知識ベース
「プラグインAはメンバーシップ機能に強い」といった情報を獲得
※相関係数0.737は、YouTubeでの言及が多いブランドほどAI検索で可視化されやすい傾向を示している（Ahrefs調べ）。

派手な編集や高額な機材は必要ない。自社のプラグインが何を解決するのか、どんなユーザーに向いているのか、実際の設定手順はどうなのかを淡々と説明する動画で十分だ。顧客インタビューや比較検討のガイドも有効に働く。

AI推奨を獲得するための実践アクション

AI推奨を獲得するための実践アクション

ここまでの調査が示す方向性は極めて実直だ。短期的なハックではなく、情報資産を地道に積み上げる活動がAI検索時代の競争を決める。具体的に取り組むべき施策を整理した。

  • コアページの品質を徹底する。ホームページや機能紹介ページで、何をするプラグインか、誰の役に立つか、実績や証拠を明確に記載する。AIはこれらのページを引用して製品を説明する。
  • 関連する「ベスト◯◯」比較記事に掲載される。ターゲット読者が読む比較記事を特定し、自社製品を掲載してもらうよう働きかける。これがAI推奨への最も直接的なルートになる。
  • YouTubeの情報資産を築く。派手な映像は不要。プラグインの機能や設定方法、選び方のガイド、顧客インタビューなど、実用的で正確な動画を数本でも公開する。動画のテキスト情報がAIに学習される。
  • 第三者による信頼性の高い言及を増やす。レビュー、ケーススタディ、ポッドキャストでの紹介など、複数の信頼できる情報源が自社製品を正確に説明すればするほど、AIは自信を持って推薦できるようになる。

いずれも派手さはないが、それこそが要点だ。AI検索で勝つ企業は、インターネット上に「十分な証拠」を積み上げてきた企業にほかならない。役に立つプロダクトを届け、それを明確に説明し、第三者が語るのを助ける。その積み重ねが、AI時代の信頼残高になる。

この記事のポイント

  • ChatGPTなどのAI検索では、従来の検索エンジンランキングとは異なる推薦メカニズムが働く。AIは「ベストリスト記事」と「YouTubeのテキスト情報」を主な情報源としている
  • 自社Webサイトの基本情報（機能説明、実績、事例）がAIの信頼基盤になるため、検索エンジン最適化の基本を外さないことが重要
  • 自社製品が「ベストプラグイン」系の記事に掲載されることで、AI回答の候補に入る確率が格段に高まる
  • YouTube動画の制作は、凝った編集よりも「役に立つ内容」を優先し、テキスト情報としてAIに読み取られることを意識する
  • AI推奨の獲得は短期的なハックでは不可能で、正確な情報と実績をインターネット上に積み重ねる地道な活動が不可欠
海田 洋祐
, , , , ,
WordPress
WooCommerce PayPal決済が断続的に失敗する原因と直し方
2026年6月28日 0

WooCommerce PayPal決済が断続的に失敗する原因と直し方

WooCommerce PayPal Payments プラグインで決済が断続的に失敗し OrderProcessor.php のエラーが発生する場合、注文 ID のセッション保存が決済リダイレクトと競合しているか、PayPal ウェブフックの署名検証に失敗している可能性が高い。原因をログから特定し、設定と更新状況を見直せば、決済の取りこぼしを止められる。

なぜ PayPal 決済やカード決済が断続的に失敗するのか

なぜ PayPal 決済やカード決済が断続的に失敗するのか

断続的に発生する決済失敗は、一定の条件が重なった時だけ起こる「競合状態」が原因になっていることが多い。WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal にリダイレクトされる直前に注文 ID をセッションへ保存する処理と、PayPal 側の承認完了後の戻り処理がうまく噛み合わず、注文 ID を見失うケースが報告されている。

また PayPal から届く CHECKOUT.ORDER.APPROVED ウェブフックの署名検証に失敗すると、ブラウザ経由の戻りが完了しなかった注文を復旧できず、売上が失われる。キャッシュや最適化を完全に停止しても再発するケースは、プラグイン内部のタイミング問題である可能性が極めて高い。

エラーログから失敗のパターンを特定する

エラーログから失敗のパターンを特定する

WooCommerce PayPal Payments の詳細ログを有効にする

管理画面の「WooCommerce」から「設定」へ進み「決済」タブを開く。PayPal の項目にある「接続を管理」画面の下部に「ログ」というチェックボックスがあるので、これを有効にして保存する。有効化後は決済のたびにログが蓄積され始めるので、エラーが出たタイミングを正確に追える。

ログに記録されるエラーメッセージを読み解く

失敗時のログには「Payment failed: There was an error processing your order. OrderProcessor.php:109」と出力される。ただしこのメッセージだけでは表面的な情報に過ぎない。同じ時刻付近に PayPal API への注文作成リクエストや capture 呼び出しが記録されているかを確認することが重要だ。

もしログに PayPal 側の注文作成すら残っていないなら、プラグインが PayPal へ処理を引き継ぐ前の段階でコケている。逆に注文作成は成功しているのに capture 呼び出しが見つからないなら、戻り処理かウェブフックの不具合を疑う。

STEP 1 WooCommerce 設定で PayPal の詳細ログを有効にする
↓
STEP 2 失敗時刻の前後で PayPal API 呼び出しの有無を調べる
↓
STEP 3 注文作成ログがない場合はセッションと注文 ID の欠落を疑う

上の手順で失敗パターンを大まかに分類できる。注文作成ログが欠けているパターンは後述の注文 ID 消失問題と合致する。

ウェブフック検証失敗の原因と直し方

ウェブフック検証失敗の原因と直し方

ウェブフックが届いているのに検証に失敗する仕組み

PayPal から WordPress サイトの REST エンドポイント（/wp-json/paypal/v1/incoming）に届いたウェブフックは、プラグインが PayPal の公開鍵を使って署名を検証する。この検証が通らないと、たとえ CHECKOUT.ORDER.APPROVED イベントを受け取っていても支払いを完了できず、注文は保留のままになる。

署名検証が失敗する典型的な原因

まず疑うのはサーバー時刻のずれだ。署名にはタイムスタンプが含まれており、サーバーの時刻が大きく狂っていると検証に失敗する。次に考えられるのがプラグイン内部で保持している PayPal 公開鍵のキャッシュ不整合だ。接続情報を更新した直後や、マルチサイト構成でドメインが一致していない場合にも起こりうる。

ウェブフック検証を復旧させる具体的な対処

最初に PayPal との接続を一度解除し、再度接続し直す。これで公開鍵のキャッシュが強制的に再取得される。それでも直らない場合は WooCommerce の「ステータス」画面から「ツール」タブを開き、「WooCommerce のトランジェントをクリア」と「期限切れのトランジェントをクリア」を順に実行する。最後に PayPal のデベロッパーダッシュボードでウェブフック URL が本番環境の正しいドメインを指しているか確認する。

Before（検証失敗時）
ウェブフック受信 → 署名照合エラー → 注文が未完了のまま放置
↓
After（再接続後）
ウェブフック受信 → 署名照合成功 → 注文が正常に完了
■ 検証失敗　■ 再接続で復旧

上の流れで復旧しない場合はプラグインバージョン固有の不具合が根底にある可能性が高い。

注文 ID がセッションから消える問題に対処する

注文 ID がセッションから消える問題に対処する

リダイレクト前に注文 ID が保存されない既知の不具合

GitHub の issue #4458 でも報告されているが、WooCommerce PayPal Payments 4.0.4 以前のバージョンでは、購入者が PayPal へリダイレクトされる直前に注文 ID を正しくセッションへ格納できないケースがある。これが発生すると、PayPal 上で決済が承認されても、戻ってきた WooCommerce 側でどの注文に紐づければよいかわからず、OrderProcessor がエラーを起こす。

修正パッチやバージョンアップで解決できるか

バージョン 4.1.0 ではこのタイミング問題に対する修正が含まれていると開発者からアナウンスされている。まずはプラグインを 4.1.0 以降へ更新することが最も確実な対処となる。どうしても本番環境で即時の更新が難しい場合は、プラグインの公式サポートチャネルを通じて修正パッチの提供を依頼する手もある。

更新前に検証するべき設定

更新前に WooCommerce の「システムステータス」レポートを取得し、PHP のバージョンが 8.0 以上であること、WordPress 本体と WooCommerce が最新の安定版であることを確認する。多言語プラグイン（WPML 等）を併用している場合は、プラグイン同士の互換性もあわせてチェックしておく。

それでも直らない場合に踏むべき最終手順

それでも直らない場合に踏むべき最終手順

キャッシュとセキュリティ系プラグインの完全な切り離し

速度最適化プラグインやサーバー側の動的キャッシュはすでに無効化していても、WAF（ウェブアプリケーションファイアウォール）やセキュリティプラグインが PayPal からのコールバック通信をブロックしている場合がある。一時的にすべてのセキュリティ系プラグインを停止し、サーバーのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストが 200 ステータスを返しているか確認する。

注文メタデータとセッションデータの直接確認

失敗した注文の詳細画面を開き、カスタムフィールドに _ppcp_paypal_order_id というメタキーが存在するか調べる。これが空になっている注文は、まさに注文 ID の引き継ぎに失敗した注文だ。WooCommerce が生成した注文番号は存在するのに PayPal 側の注文 ID だけ欠落している場合は、前述の競合が再現したと断定してよい。

確認項目
注文メタデータ → _ppcp_paypal_order_id の有無を確認
アクセスログ → /wp-json/paypal/v1/incoming への POST が 200 を返しているか
プラグインバージョン → 4.1.0 以上へ更新済みか
■ データ・技術系の確認ポイント

この三点を確認すれば、問題がインフラ寄りなのかアプリケーション寄りなのか切り分けられる。

よくある質問

PayPal のウェブフック検証失敗は何が原因か

サーバー時刻のずれや PayPal 公開鍵のキャッシュ不整合が最も多い原因だ。接続を一度解除して再接続し、WooCommerce のトランジェントをクリアすることで解決することが多い。まれにホスティング環境のファイアウォールが PayPal の検証用リクエストを遮断しているケースもある。

決済が断続的に失敗する場合、キャッシュが原因か

キャッシュが直接の原因でないケースも多い。キャッシュを完全に停止し、カートやチェックアウトの除外設定を施しても再発するなら、プラグイン内部の競合状態や注文 ID の引き継ぎ不良を疑うべきだ。

WooCommerce PayPal Payments の最新バージョンで問題は修正されたか

バージョン 4.1.0 では、注文 ID のセッション保存タイミングに関する修正が含まれている。4.0.4 以前で OrderProcessor エラーが断続的に出ている場合は、まず 4.1.0 以降へ更新することが推奨される。

注文 ID が保存されない問題はどうやって確認するか

失敗した WooCommerce 注文のカスタムフィールドを確認し、_ppcp_paypal_order_id というメタキーが空かどうかを調べる。空であれば注文 ID の引き継ぎに失敗している。プラグインの詳細ログにも PayPal 側の注文作成リクエストが記録されない。

ウェブフックのエンドポイントにアクセスできるか確認する方法は

サイトのアクセスログで /wp-json/paypal/v1/incoming への POST リクエストを探し、HTTP ステータスが 200 であることを確かめる。PayPal のデベロッパーダッシュボード上でウェブフック URL が本番ドメインを指しているかも同時に検証する。

この記事のポイント

  • ログを有効にして OrderProcessor エラーの前後に PayPal API 呼び出しが存在するか確認する
  • ウェブフック検証失敗は接続の再設定とトランジェントクリアで復旧する可能性が高い
  • 注文 ID のセッション消失は 4.1.0 以上のプラグイン更新で根本対処できる
  • キャッシュ停止だけでは直らない競合はプラグイン内部のタイミング問題を疑う
  • 注文メタデータとアクセスログの二面から原因の切り分けを進める
佐々木 太陽
, , , , ,
お悩み・トラブル解決
« 前ページへ 次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.