佐々木太陽 - 株式会社A&Gウェブ - ライバルには、ひみつ。

2026年8月12日 0

WordPressでデータベース接続確立エラーが出た時の直し方

WordPressで「データベース接続確立エラー」が表示される原因は、wp-config.phpファイル内のデータベース接続情報の誤り、またはデータベースサーバー自体の停止に大別される。まずはこの二点を順に確認すれば、大半のケースは解決する。

エラーメッセージが示す根本的な原因は二つだけ

WordPressのインストール時や運用中に「データベース接続確立エラー」というメッセージが表示された場合、WordPressは設定ファイルに書かれた情報でMySQL（またはMariaDB）データベースへ接続できていない。エラー画面にも表示される通り、原因は大きく分けて次の二つだ。

認証情報の不一致（wp-config.phpのデータベース名、ユーザー名、パスワード、ホスト名のいずれかが間違っている）
データベースサーバーに接続できない（サーバーが停止している、ネットワーク障害がある、ホスト名が間違っている）

新規インストール直後のエラーでは設定ミスが大半を占め、運用中のサイトで突然発生した場合はサーバー側の一時的なトラブルや、何らかの設定変更が影響している可能性が高い。いずれにせよ、対処のステップは決まっている。

エラー「データベース接続確立エラー」が画面に表示される

↓

認証情報確認

wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを再チェック

サーバー確認

データベースサーバーが稼働しているか、管理画面から確認

■ エラー状態　 ■ 認証情報の確認　 ■ サーバー稼働の確認

最初に確認すべきwp-config.phpの設定

データベース接続情報を記述するwp-config.phpは、WordPressのルートディレクトリに設置されている。エラーが起きたら、まずこのファイルの中身をファイルマネージャーやFTPで開き、以下の4項目が正しいか確認する。

データベース名（DB_NAME）の確認

DB_NAMEには、使用するデータベースの正確な名前を指定する。多くのレンタルサーバーでは、契約時に自動生成されたデータベース名にアカウント名のプレフィックスが付与される（例: username_wp001）。phpMyAdminやサーバー管理画面のMySQLデータベース一覧に表示される名前と、一字一句たがわず一致させる必要がある。大文字小文字も区別されるため、コピー＆ペーストで転記するのが確実だ。

ユーザー名（DB_USER）とパスワード（DB_PASSWORD）の精査

データベースに接続するためのユーザー名とパスワードも同様に、サーバー側で作成したMySQLユーザーの情報と完全一致させる。パスワードは暗号化されずに平文で記述されるため、見間違いがないか注意する。また、パスワードに特殊文字（’ ” \ $ など）が含まれていると、PHPが正しく解釈できず接続エラーを引き起こすことがある。必要に応じてシングルクォーテーションで囲む、あるいはパスワード自体を英数字のみの強固なものに変更するのも有効な手段だ。

ホスト名（DB_HOST）の指定

DB_HOSTは、WordPressがデータベースサーバーを探しに行く宛先だ。多くの共用サーバーでは localhost で問題ない。しかし、一部のホスティング環境では、データベースサーバーがWebサーバーとは別のマシンで動作しており、専用のホスト名やIPアドレスが割り当てられている。サーバー会社のマニュアルに記載されているホスト名（例: mysql.example.com）を指定する。稀に 127.0.0.1 で接続できるが localhost だとエラーになるケースもあるため、どちらも試す価値がある。

Before（エラー発生時）

define( 'DB_NAME', 'wordpress' ); /* ← 実在しないDB名 */
define( 'DB_PASSWORD', 'mypassword' ); /* ← 誤ったパスワード */

↓

After（修正後）

define( 'DB_NAME', 'user_wp01' ); /* ← 正しいDB名 */
define( 'DB_PASSWORD', 'C0rrect!Pass#' ); /* ← 正しいパスワード */

データベースサーバーが稼働しているか確認する

wp-config.phpの設定が正しいのにエラーが続く場合、問題はデータベースサーバー側にある。まず、利用しているホスティングサービスの管理画面にログインし、MySQLやデータベースのセクションを確認する。

サーバー管理画面からの状況確認

多くのレンタルサーバーでは、cPanelや独自のコントロールパネルからMySQLサーバーの稼働状況や、データベースの一覧、ユーザー管理が行える。対象のデータベースとユーザーが存在し、かつユーザーに適切な権限が付与されているかを確認する。サーバー会社によっては、メンテナンスや障害発生時にステータスページで告知を行っているため、そちらも合わせてチェックする。

phpMyAdminで直接ログインを試みる

サーバーの管理画面からphpMyAdminを起動し、wp-config.phpで指定したのと同じユーザー名とパスワードでログインできるか試す。ログインできればデータベースサーバー自体は稼働しており、認証情報も正しいことになる。ログインに失敗する場合は、パスワードのリセットやユーザーの再作成を検討する。ローカル環境（LocalWPやXAMPPなど）で作業している場合は、MySQLサービスが起動しているか、タスクマネージャーやサービス一覧で確認する。

STEP 1 サーバー管理画面にログインし、MySQLの項目を開く

↓

STEP 2 データベースとユーザーが存在し、リンクされているか確認

↓

STEP 3 phpMyAdminで同じ認証情報を使ってログインできるかテスト

↓

STEP 4 接続できればデータベースは正常、できなければユーザーの再作成を検討

それでも解決しない場合の追加確認項目

上記の確認で問題が見つからない場合、より深い部分に原因が潜んでいる。以下の点を順に見ていく。

データベースユーザーの権限を再確認する

MySQLユーザーがデータベースにアクセスするための権限が不足していると、WordPressはテーブルを作成・読み取りできず接続エラーを起こす。phpMyAdminやサーバー管理画面で、該当ユーザーに「ALL PRIVILEGES」が付与されているか確認する。特にデータベースを移行した直後や、手動でユーザーを作成した場合に起こりやすい。

データベースの破損をチェックする

サーバーの突然の停止やディスク障害により、MySQLのテーブルが破損することがある。phpMyAdminで該当データベースを選択し、すべてのテーブルをチェックして「テーブルの修復」を実行する。WordPressが管理画面にアクセスできる状態であれば、wp-config.phpに define('WP_ALLOW_REPAIR', true); を一時的に追記し、http://example.com/wp-admin/maint/repair.php にアクセスして修復する手段もある。修復後は必ずこの行を削除する。

wp-content/db.php ファイルの存在を疑う

一部のキャッシュプラグインやデータベース置き換えプラグインは、/wp-content/db.php というファイルを作成してWordPress標準のデータベース接続処理を上書きする。このファイルが破損していたり、古い設定を保持したままだと、突然データベース接続エラーを引き起こす。FTPでdb.phpを一時的に別名にリネームし、エラーが消えるか確認する。

マルチサイトのwp-config.php設定を見直す

WordPressのマルチサイト（サブディレクトリ型やサブドメイン型）を運用している場合、wp-config.phpにマルチサイト固有の定義定数が正しく記述されている必要がある。DOMAIN_CURRENT_SITE や SUBDOMAIN_INSTALL の値が、実際のURL構成やサーバー設定と矛盾していると、内部的なデータベースクエリが失敗して接続エラーに見えることがある。マルチサイト化した直後や、ドメインを変更した後にエラーが起きた場合は、この設定を疑う。

よくある質問

wp-config.phpの修正後にエラーが変わらないのはなぜか

修正内容を保存しても、サーバーのキャッシュやCDN（コンテンツデリバリネットワーク / 配信網）が古いエラー画面を表示し続けることがある。スーパーリロード（Ctrl+F5やCommand+Shift+R）を試し、それでも変わらなければキャッシュ系プラグインを一時停止するか、サーバー側のキャッシュを管理画面からクリアする。

パスワードやユーザー名は合っているのに接続できない

MySQLユーザーが特定のIPアドレスからの接続に制限されている可能性がある。レンタルサーバーでは「localhost」専用のユーザーが作成されるが、外部から接続するように変更してしまうとWebサーバーからのローカル接続が拒否される。phpMyAdminのユーザーアカウント管理で、ホスト名が「localhost」または「127.0.0.1」になっているか確認する。

レンタルサーバーのサポートに連絡するタイミングはいつか

自身でwp-config.phpの設定確認、phpMyAdminからのログインテスト、管理画面からのデータベース稼働状況確認を行っても解決しない場合は、サーバー側の障害や特殊な構成が原因である可能性が高い。サーバー会社のサポートに「WordPressのデータベース接続確立エラーが出ている」「MySQLに接続できない」と具体的に伝えて調査を依頼する。その際、エラーメッセージのスクリーンショットがあるとスムーズだ。

ローカル環境で同じエラーが出る場合の対処法は

LocalWPやXAMPP、MAMPなどのローカル開発環境では、MySQL（またはMariaDB）のサービスが停止していることが原因の大半を占める。各ツールの管理画面で「Start」ボタンを押してサービスを起動し直すか、OSのシステムトレイから再起動する。ポートの競合（特に3306番）が原因で起動に失敗しているケースもあるため、エラーログを確認する。

データベースの修復をしてもすぐにエラーが再発する

テーブルの修復が一時しのぎで終わる場合、ストレージのディスク容量不足や、ハードウェア的な障害が進行している可能性を疑う。サーバーのディスク使用率を確認し、不要なバックアップやログを整理する。根本的にはホスティングサービスのプラン見直しや、サーバー移転を検討する必要がある。

この記事のポイント

データベース接続エラーの原因は「認証情報の不一致」と「サーバー停止」に絞られる
wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを最初に確認する
phpMyAdminで同じ認証情報を用いて直接ログインし、サーバー稼働をテストする
解決しない場合はユーザー権限・DB破損・db.phpの競合・マルチサイト設定を順に疑う
サーバー側の障害が疑われる場合は、ログやディスク容量を確認しサポートに連絡する

佐々木太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・「検索しても答えが見つからなかった」を一つでも減らすことが目標
・エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

佐々木太陽

MySQL, WordPress, wp-config, サーバー障害, データベースエラー, トラブル解決

お悩み・トラブル解決

2026年8月11日 0

WooCommerce商品ページでjQueryが未定義になるエラーはプラグインのasync読み込みが原因

jQueryに依存したフロントエンド向けスクリプトが async 属性付きで読み込まれると、実行順序が崩れて「Uncaught ReferenceError: jQuery is not defined」が発生する。商品ページの動作不良やバリエーション選択UIの不具合につながるこの問題は、プラグイン側で強制された async 指定と prefetch ヒントを外せば解決する。

なぜ商品ページで「jQuery is not defined」が起きるのか

WooCommerce サイトで「重大なエラーが発生しました」ではなく、ブラウザのコンソールに jQuery の参照エラーが出てページの一部が動かなくなるケースがある。このエラーの多くは、JavaScript の依存関係が守られていないことに起因する。

WordPress 本体や多くのプラグインは、JavaScript を安全に読み込むために wp_register_script や wp_enqueue_script で依存関係（例：array('jquery')）を宣言している。しかし、一部のプラグインが表示速度を意識してか、最終的に出力される <script> タグに async 属性を強制的に付与してしまうことがある。

async 属性が付いたスクリプトは、ダウンロードが完了次第すぐに実行される。もしその時点で jQuery 本体（jquery-core-js）の読み込みが終わっていなければ、jQuery is not defined の参照エラーとなる。この実行順序の逆転は、キャッシュや最適化プラグインが介在するとさらに発生しやすくなる。

加えて、問題のプラグインが <link rel="prefetch"> を head 内に自ら出力している場合、ブラウザはそのスクリプトを早期取得しようとし、実行タイミングの競合がさらに深刻化する。

async 読み込みを強制している箇所を特定する手順

まず、エラーがどのスクリプトで起きているのかを絞り込む。WooCommerce 商品ページで特定の動作（数量変更、バリエーション切替など）が効かなくなったら、ブラウザの開発者ツールを開く。

STEP 1 Chrome なら F12 キーで「コンソール」タブを開く

↓

STEP 2 赤いエラー行「Uncaught ReferenceError: jQuery is not defined」を確認し、該当のスクリプトファイル名を特定する

↓

STEP 3 「ネットワーク」タブを開き、該当 JS が jQuery よりも先に取得・実行されていないか読み込み順を調べる

↓

STEP 4 HTML ソース表示で該当スクリプトのタグに async 属性が付与されていないか、prefetch の link タグが head 内に存在しないかを確認する

調査の過程で、プラグインフォルダ（多くは /wp-content/plugins/プラグイン名/）内の enqueue.php やメインのプラグインファイルを開き、以下のような処理が入っていないか検索する。

str_replace( ' src', ' async src', $tag ) のように script タグに async を差し込むコード
wp_register_script で jQuery 依存を宣言しているにもかかわらず、上記で async を上書きしている箇所
echo '<link rel="prefetch" href="' ... .js'>' の形でプリフェッチヒントを出力している処理

これらのコードが確認できれば、プラグインが意図せず実行順序を壊している原因と断定できる。

プラグインのコードを修正して async を外す方法

問題を解消するには、async の強制付与と prefetch の出力を取りやめる必要がある。理想はプラグイン開発者が修正版をリリースすることだが、すぐに動かす必要がある場合は以下のようにコードを直接修正する。修正前に必ずバックアップを取り、子テーマや独自プラグインによる上書きが可能ならそちらを優先する。

修正前後の script タグ比較

Before（エラー状態）

<script async src=’…/custom.js’></script>

async 属性が付与されている

↓

After（修正後）

<script src=’…/custom.js’></script>

async が外れ、依存関係が守られる

■ エラー状態（async あり）　 ■ 修正後（async なし）

実際の修正は、プラグインファイルの該当行をコメントアウトまたは削除することで行う。

async 強制付与の無効化

includes/enqueue.php のようなスクリプト登録ファイルを開き、str_replace で async を割り込ませている箇所を探す。典型的には以下のようなコードだ。

if ( 'wcmmq-custom-script' === $handle ) {
    return str_replace( ' src', ' async src', $tag );
}

この部分全体をコメントアウトするか、条件分岐を削除して return $tag; だけを残す。これで async 属性の付与が止まり、WordPress が宣言した依存関係通りに jQuery の後で実行されるようになる。

prefetch リンクの除去

次にメインのプラグインファイル（例：plugin-name.php）を開き、wp_head 等にフックして <link rel="prefetch"> を出力している箇所を探す。

echo '<link rel="prefetch" href="' . esc_url(WC_MMQ_BASE_URL . 'assets/js/custom.js') . '">' . "\n";

この行をコメントアウトする。prefetch ヒントがなくなると、ブラウザが該当スクリプトを過度に早期取得しようとする圧力が減り、実行タイミングの競合リスクが下がる。

functions.php で上書きする方法

プラグイン本体を直接触りたくない場合は、テーマの functions.php で該当スクリプトをいったん解除し、async なしで再登録する方法もある。

function fix_custom_js_async() {
    wp_deregister_script('wcmmq-custom-script');
    wp_register_script('wcmmq-custom-script', WC_MMQ_BASE_URL . 'assets/js/custom.js', array('jquery'), $js_version, true);
    wp_enqueue_script('wcmmq-custom-script');
}
add_action('wp_enqueue_scripts', 'fix_custom_js_async', 99);

この方法でも async の強制を回避できるが、prefetch の出力は別途 remove_action で除去する必要がある。確実なのはプラグインの該当コードをコメントアウトする方針だ。

修正後も注意すべきキャッシュと最適化プラグインの影響

コード修正後にサイトを確認してもまだエラーが出る場合、キャッシュや最適化プラグインが古いスクリプトを配信し続けている可能性がある。

使用しているキャッシュプラグイン（W3 Total Cache、WP Super Cache など）のキャッシュを全削除する
最適化・高速化プラグイン（NitroPack、WP Rocket など）のキャッシュもクリアする
サーバー側で CDN を利用している場合は、CDN のキャッシュもパージする
ブラウザのキャッシュをクリアするか、シークレットウィンドウで動作確認する

最適化プラグインの中には、JavaScript の結合や遅延読み込み（defer）を独自に行うものもある。async を外したあとも問題が続くなら、最適化機能の「JavaScript の遅延読み込み」や「スクリプトの結合」を一時的に無効化し、問題のスクリプトが正しく読み込まれるか切り分けを進める。

よくある質問

async と defer の違いは何か

async はスクリプトのダウンロードが完了次第すぐに実行され、他のスクリプトとの実行順序が保証されない。defer は HTML の解析が完了したあとに、書かれた順序で実行される。jQuery 依存スクリプトに async を使うと実行順序が守られないため、今回のようなエラーを引き起こす。

プラグイン本体を修正するとアップデートで上書きされないか

プラグインを直接修正した場合、そのプラグインがアップデートされると修正内容は上書きされて失われる。長期的には、プラグイン開発者にバグ報告を行い、公式の修正版がリリースされるのを待つのが理想だ。それまでの間はアップデートを見送るか、修正を再適用する必要がある。

async を外しても「jQuery is not defined」が消えないのはなぜか

原因が複数存在するケースもある。ほかのプラグインやテーマが jQuery を正しく依存関係に含めずにスクリプトを読み込んでいる可能性や、jQuery そのものが何らかの理由で読み込まれていないケースが考えられる。コンソールで jQuery が本当に未定義かどうかを確認し、ネットワークタブで jQuery 本体の読み込み状況を再調査する。

子テーマで対策する利点は何か

テーマのアップデートに影響されず、修正内容を保持できる点が最大の利点だ。ただし、スクリプトの登録解除と再登録では prefetch の出力まで止められないため、完全な対策にはならないこともある。状況に応じて最適な方法を選ぶ。

この記事のポイント

jQuery 依存スクリプトに async 属性が付くと実行順序が崩れ「jQuery is not defined」が発生する
プラグインの enqueue.php やメインファイルで async 付与・prefetch 出力が強制されていないか確認する
該当コードをコメントアウトし async を外せば、依存関係が守られエラーが解消する
修正後はキャッシュプラグインや CDN のキャッシュをクリアして検証する
プラグイン本体の修正はアップデートで上書きされるため、公式修正を待つか都度再適用が必要

佐々木太陽

JavaScriptエラー, jQuery, WooCommerce, WordPress, トラブル解決, プラグイン

お悩み・トラブル解決

2026年8月11日 0

Rank Math有効時にElementorパネルがフリーズする原因と復旧手順

Elementorのウィジェットパネルが突然操作不能になり、半透明のまま固まってしまう。この症状はRank Math SEOが同時に有効になっている環境で特に発生しやすく、複数のプラグインが読み込むスクリプトの衝突が原因だ。キャッシュのクリアと一部モジュールの無効化、またはバージョン管理で大半は改善する。

なぜRank Mathを有効にするとElementorパネルが固まるのか

この問題の根本には、WordPress管理画面で複数のプラグインがそれぞれJavaScriptやCSSを読み込む「競合」がある。Elementor Editorはページ上のあらゆる要素をドラッグアンドドロップで編集できる高度なインターフェースだが、そのぶん大量のAjax通信とDOM操作を行う。一方Rank Mathは、コンテンツAIやインスタントインデックス、スキーママークアップなど多機能なSEOツールを提供しており、画面内で動作する独自のスクリプトを多数読み込む。

両者が同時にロードされると、メモリ上で予期せぬエラーが発生したり、読み込み順序の不整合からElementorのウィジェットパネルがゾンビ化（グレーアウト状態）することがある。とくに最近のバージョンアップで機能が増えた直後や、サーバー側のPHPメモリ割り当てがギリギリの場合に表面化しやすい。

まずは本当に競合かどうかを確実に特定する

似たような症状は他のプラグインでも起こりうる。まずはRank Mathを含む全プラグインを停止し、Elementorだけの状態で正常に動作するかを確認する手順が切り分けの基本だ。

プラグイン停止モードを使った最小構成テスト

WordPressには「トラブルシューティングモード」を提供するプラグインがあるが、手動で行う方法も確実だ。管理画面の「プラグイン」→「インストール済みプラグイン」から、Rank Mathを除くすべてのプラグインを一時的に無効化する。その後、標準テーマ（Twenty Twenty-Fiveなど）に切り替えたうえで、Elementor Editorを開いてパネルが動くかテストする。

ここで問題が解消すれば、次にRank Mathだけを有効化し、再度パネルの挙動を確認する。Rank Mathを有効化した瞬間にフリーズが再現するなら、このプラグインがトリガーであると断定できる。

ブラウザコンソールでエラーの詳細を確認する

Chromeの場合、F12キーでデベロッパーツールを開き「Console」タブを見る。パネルが固まった直後には、赤字のJavaScriptエラーがいくつか記録されている。とくにUncaught TypeErrorやload-scripts.phpで始まるエントリがあれば、読み込み競合の有力な手がかりになる。エラー文言をメモしておくと、Rank Mathのサポートに問い合わせる際の情報になる。

Elementorパネルを復旧させる現実的な4ステップ

原因が特定できたら、以下に示す順に作業することで元の状態に戻せる。いきなりプラグインの再インストールをする前に、まずはキャッシュとモジュールの調整で解決できる場合が多い。

STEP 1 Rank Mathをいったん無効化してパネルを復旧

↓

STEP 2 WordPress全体のキャッシュとブラウザキャッシュをクリア

↓

STEP 3 Rank Math内の不要なモジュールをオフにする

↓

STEP 4 Rank MathとElementorを最新版に揃えて再び有効化

上記は概念的なフローであり、実際の作業では各ステップ後に必ずEditor画面をリロードして状態をチェックする。

STEP 1 Rank Mathを無効化して即座に確認する

緊急時に最も手早い対処はRank Mathの一時停止だ。「プラグイン」一覧からRank Mathを「無効化」し、Elementor Editorを開き直す。パネルが正常に戻ったら、問題がRank Math由来であることが確定する。この状態で作業は継続できるため、更新が急ぎの場合はSTEP 1だけでその場をしのげる。

STEP 2 キャッシュをあらゆる層で削除する

無効化だけでは根本解決にならない。Rank Mathを再び有効化する前に、キャッシュを丁寧に消す。WordPress側ではキャッシュ系プラグイン（W3 Total CacheやWP Super Cacheなど）を使っているなら管理画面から「全キャッシュ削除」を実行する。サーバー側でNginx FastCGI CacheやVarnishが動いている場合はホスティングの管理パネルからも同様に行う。最後にブラウザのキャッシュとCookieも削除し、シークレットウィンドウでEditorにアクセスすると、より確実に変化を確認できる。

STEP 3 Rank Mathのモジュールを調整する

Rank Mathには多数の拡張モジュールが用意されており、その組み合わせによってはElementorのスクリプトと干渉することがある。Rank Mathの管理メニュー「Rank Math」→「ダッシュボード」→「モジュール」へ進み、以下の機能をひとまずオフにしてみる。

コンテンツAI
インスタントインデックス
SEO分析（管理画面で動作するウィジェット）

これらの機能は編集画面に独自のメタボックスや通知を追加するため、競合の原因になりやすい。変更を保存し、再度Elementor Editorでパネルの挙動をチェックする。症状が消えたら、ひとつずつモジュールをオンにして犯人を特定することもできる。

STEP 4 両プラグインを最新状態に保つ

WordPress本体、Elementor、Rank Mathのすべてが最新版であれば、開発者同士が互換性を確認した上でリリースしている可能性が高い。バージョンに偏りがあると、片方だけが想定する関数が欠落しているケースがある。アップデート後は必ずSTEP 2のキャッシュクリアを再度行う。

再発を防ぐために日頃からできること

大規模な編集を始める前に、Rank Mathのモジュール状態を簡易チェックリストにしておくと、いざという時のダウンタイムを大幅に減らせる。また、PHPのメモリリミットが最低でも256MB以上確保されているかを確認するのも効果的だ。

万一どうしても競合が解消しない場合は、Rank MathをElementor編集時だけ一時的に無効化する運用でも実務上は問題になりにくい。ただし、無効化すると編集中のSEOスコアが変動する可能性があるため、プレビュー公開前に再度有効化してSEO設定を確認する習慣をつけておく。

よくある質問

他のSEOプラグインでも同じことが起きますか

Yoast SEOやAll in One SEO Packでも類似の競合は報告されているが、発生条件や修正パッチはプラグインごとに異なる。まずは同じ手順で特定し、問題が発生したプラグインに合わせた対処を行うとよい。

Rank Mathを無効化するとSEO順位に影響しますか

短時間（数分〜数十分）の無効化であれば、検索順位への直接的な影響はまずない。ただし、その間にクローラーがサイトを訪れると、メタタグが一時的に変化する可能性があるため、公開状態の確認は忘れずに行う。

キャッシュをすべて消さずに直す方法はありますか

管理画面の問題はサーバーレベルのページキャッシュと直接関係しないこともあるが、ブラウザ上に競合する古いスクリプトが残っていると再発しやすい。最低限ブラウザキャッシュだけは削除し、あわせて管理画面用のバックグラウンド処理キャッシュがないか確認する方が確実だ。

プレビュー画面だけ固まる場合はどうすればいいですか

プレビュー表示は管理画面とフロントエンドの両方のスクリプトが混在しやすい。まずはパーマリンク設定を再保存し、.htaccessをリフレッシュする。それでも治らない場合は、テーマのfunctions.phpで読み込みを遅延させるカスタムコードを追加する選択肢もある。

競合が直ったのにしばらくすると再発します

キャッシュ系プラグインやCDNが古いファイルを配信し続けている可能性が高い。Originサーバー上のキャッシュも含めて一掃し、変更後にCDNのパージが自動でかかる設定になっているか見直すことを推奨する。

この記事のポイント

Rank Mathの有効化直後にElementorパネルが固まるのはスクリプト競合が原因
最小構成テストで競合相手を特定するのが最短の道
即効復旧にはRank Mathの一時無効化と全キャッシュ削除が有効
不要なSEOモジュールをオフにすることで競合を回避できる
バージョンの統一と定期的なキャッシュクリアで再発を防げる

佐々木太陽

Elementor, Rank Math, WordPress, トラブル解決, プラグイン競合

お悩み・トラブル解決

2026年8月10日 0

PixelYourSite が Nginx FastCGI キャッシュを無効化する問題の直し方

PixelYourSite を有効にしたとたん Nginx FastCGI キャッシュがまったく効かなくなり、PHP の負荷が急増して 504 Gateway Timeout が頻発するなら、プラグインの「PHP セッションを無効にする」設定をオンにするだけで解決できる。

この問題は、PixelYourSite が訪問者のトラフィック情報を一時保存するために PHP セッションを開始することで発生する。セッション開始時に送信される Cookie（PHPSESSID）とキャッシュを禁止するヘッダー（Cache-Control: no-store など）が Nginx の FastCGI キャッシュを素通りさせ、毎回バックエンドの PHP が起きてしまうのが根本原因だ。

なぜ PixelYourSite が FastCGI キャッシュを無効化するのか

PixelYourSite には、ランディングページの URL やトラフィックソース、UTM パラメータなどをセッション変数に保持する仕組みがある。この処理は includes/class-pys.php 内の controllSessionStart() メソッドで行われ、まだセッションが始まっていなければ session_start() を呼び出す。サーバー側の PHP 設定で session.cache_limiter が nocache に設定されていると、この瞬間に以下の HTTP レスポンスヘッダーが自動的に追加されてしまう。

Set-Cookie: PHPSESSID=...
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache

Nginx FastCGI キャッシュは、これらのヘッダーがついたレスポンスをキャッシュしない。結果として、匿名の一般訪問者に対しても毎回 PHP が実行され、PHP-FPM ワーカーが占有され続ける。アクセスが集中するとすべてのワーカーがビジーになり、レスポンスを返せず 504 エラーに至る。

PixelYourSite 有効時に送られるヘッダー（Before）

 ✗ Set-Cookie: PHPSESSID=abc123…
 ✗ Cache-Control: no-store, no-cache, must-revalidate
 ✗ Pragma: no-cache
 ✗ X-FastCGI-Cache: MISS

↓

セッション無効化後（After）

 ✓ X-FastCGI-Cache: HIT
 ✓ （Set-Cookie やキャッシュ禁止ヘッダーは付かない）

■ セッション有効（キャッシュ殺し）　■ セッション無効（キャッシュ効く）

上記の通り、問題の本質はセッションに伴うキャッシュ抑制ヘッダーにある。幸い PixelYourSite には、この PHP セッション機能をまるごとオフにする設定が用意されている。

設定変更で PHP セッションを無効化する手順

PixelYourSite のグローバル設定画面から 1 か所切り替えるだけで、セッションに依存しない動作に切り替えられる。手順はどこのサーバーでも共通だ。

STEP 1 WordPress 管理画面の「PixelYourSite」メニューを開く

↓

STEP 2 画面上部の「Global Settings」タブをクリック

↓

STEP 3 「Disable PHP Sessions」のチェックボックスをオンにする

↓

STEP 4 「Save Settings」ボタンで保存し、キャッシュを全削除する

「Disable PHP Sessions」の場所と見つけ方

この設定項目は、PixelYourSite のバージョンによっては「PHP Sessions」というセクションに含まれている。「Global Settings」タブを開き、下にスクロールしていくと「Track UTMs」「Track Traffic Source」といった項目の近くに配置されていることが多い。チェックボックスにチェックを入れると、即座に session_start() が呼ばれなくなる。

設定保存後に必ずキャッシュをクリアする

変更を保存したあとは、WordPress のキャッシュプラグイン（WP Rocket など）と Nginx FastCGI キャッシュの両方を必ずクリアする。さもないと、以前のセッション付きレスポンスがキャッシュされたまま残ってしまう。一般的な手順は次のとおりだ。

WP Rocket の「キャッシュをクリア」を実行する
サーバーのシェルから nginx -s reload またはキャッシュディレクトリの削除を行う（環境に応じて）
Cloudflare を利用している場合は、Cloudflare 側のキャッシュもパージする

設定変更後の影響とデータ精度について

PHP セッションを無効にすると、ランディングページ、トラフィックソース、UTM パラメータといった情報の受け渡し方法が、サーバーサイドのセッションからブラウザの Cookie へと切り替わる。プラグインはこれらの値を Cookie に保存し、それを読み取って各ピクセルに渡す形になる。そのため、トラッキング自体は継続して機能する。

精度の面で多少の劣化が生じる可能性はあるものの、PixelYourSite の開発チームは「精度の低下は最小限」としている。実際、セッションに頼らなくても、Cookie を正しく読み取れればデータ取得に大きな支障は出ない。EC サイトで大量のアクセスをさばく場合、キャッシュが効かないことによるサーバーダウンのリスクと比較すれば、この切り替えのデメリットはほとんど無視できるレベルだ。

PHP セッション無効化後も問題が続く場合の追加チェック

設定を変更してもキャッシュが MISS のままだったり、PHP ワーカーの高負荷が解消されない場合は、以下のポイントを順に確認する。

キャッシュ除外設定の見直し

Nginx の設定で、特定の Cookie が存在するとキャッシュをバイパスするルールが書かれていないか確認する。たとえば wp- や wordpress_logged_in といった Cookie は除外対象になるが、PHPSESSID が消えたことで意図しないキャッシュ ON が起きていないかもあわせてチェックする。

他のプラグインがセッションを開始していないか調べる

PixelYourSite だけを無効化したときに問題が消えたとしても、同様にセッションを使う別のプラグインが有効になっていないか切り分ける。WooCommerce のカートなどはログインユーザー向けにセッションを使うが、匿名訪問者にまでセッションを開始するプラグインは稀だ。すべてのプラグインを一時停止し、1 つずつ有効にして原因を特定するとよい。

よくある質問

「Disable PHP Sessions」を有効にしてもトラッキングは引き続き動作するか

動作する。セッションの代わりにブラウザの Cookie を使ってランディングページや UTM パラメータを保持するため、Facebook ピクセルや Google アナリティクスへのデータ送信は継続される。

Nginx FastCGI キャッシュ以外のキャッシュ（Varnish や CDN）でも効果はあるか

非常に効果が高い。Cache-Control: no-store や Set-Cookie ヘッダーは、Varnish をはじめとするほとんどの HTTP キャッシュ層で「キャッシュしてはいけないレスポンス」と判定される。PHP セッションを止めるだけで、あらゆるキャッシュ層が正常に機能し始める。

この設定はサイトの表示速度にどれくらい影響するのか

キャッシュが有効になると、PHP の処理を経由せず Nginx が直接静的 HTML を返すため、TTFB（最初の 1 バイトが届くまでの時間）が劇的に短縮される。同時にサーバーの CPU 使用率も下がるため、アクセス集中時のタイムアウトも防ぎやすくなる。

PixelYourSite を最新版にアップデートしてもセッション問題は解決されないのか

2026 年 8 月時点のバージョンでは、PHP セッションを利用する設計が残っている。今後アップデートで標準動作が変わる可能性はあるが、現状はユーザーが手動で「Disable PHP Sessions」をオンにする必要がある。

この記事のポイント

PixelYourSite が PHP セッションを開始するため、Nginx FastCGI キャッシュが無効化される
「Disable PHP Sessions」をオンにするだけでキャッシュが正常に機能するようになる
設定後は必ず Nginx と WordPress のキャッシュをクリアする
トラッキングは Cookie ベースに切り替わり、精度への影響はごくわずか

佐々木太陽

FastCGI, Nginx, PHPセッション, PixelYourSite, WordPress, キャッシュ, パフォーマンス最適化

お悩み・トラブル解決

2026年8月10日 0

Mail Mintのワンクリック解除リンクでデータベースエラーが出る時の対処

Mail Mint で配信したメールのワンクリック解除リンクをクリックすると、WordPress のデータベースエラー「Column ‘mint_email_id’ cannot be null」がログに出力される問題は、プラグインのバージョンが古いことが主な原因だ。最新版（バージョン 1.30.0 以降）にアップデートすることで、このエラーは発生しなくなる。

なぜワンクリック解除でデータベースエラーが発生するのか

Mail Mint のワンクリック解除機能は、メール内のリンクに埋め込まれたハッシュ値から、どの配信（ブロードキャスト）からの解除なのかを特定する。しかし、古いバージョン（1.24.4 以下など）では、ハッシュ値が無効な場合や、該当する配信が存在しない場合に、ブロードキャスト ID を取得する関数が null を返していた。

その結果、購読解除ステータスの更新自体は正常に行われるものの、その後にブロードキャストごとのメタ情報（is_unsubscribe）を記録する際、データベースの mint_email_id カラムに null が INSERT されようとして、WordPress のデータベースエラーが発生していた。

このエラーは、購読解除の処理自体を妨げるものではなく、あくまでログに記録されるだけだが、大量に発生するとサーバーのエラーログが肥大化するなどの影響が出る。

Mail Mint を最新版にアップデートしてエラーを解消する

開発元はこの問題を認識し、バージョン 1.30.0 で修正をリリースしている。そのため、まずは管理画面からプラグインを最新版に更新しよう。

STEP 1 管理画面の「プラグイン」→「インストール済みプラグイン」を開く

↓

STEP 2 Mail Mint の「更新」リンクが表示されていればクリック

↓

STEP 3 バージョン 1.30.0 以上に更新されていることを確認する

プラグインの自動更新が有効な場合はすでに適用されている可能性もあるが、念のためバージョン表示を確認しておこう。

更新後にエラーが止まったか確認する

更新が完了したら、メールマーケティングのワンクリック解除リンクを実際にテストするか、サーバーのエラーログに同じメッセージが出なくなったことを確認する。WordPress のデバッグモードを有効にしている場合は wp-content/debug.log もチェックする。

Before WordPressデータベースエラー Column ‘mint_email_id’ cannot be null がログに記録される

↓

After エラーは発生せず、静かに購読解除メタが保存される

■ エラー状態　■ 修正後

どうしてもアップデートできない場合の一時的な対処

何らかの理由でプラグインをすぐに更新できない場合、以下のコード修正を適用することでエラーを回避できる。ただし、この修正はプラグインの本体ファイルを直接変更するため、次回のアップデートで上書きされる。あくまで緊急措置として理解しておこう。

修正するファイルは app/Internal/Optin/UnsubscribeConfirmation.php だ。process_one_click_confirmation メソッド内の、$broadcast_email_id を取得した直後の処理を対象にする。

修正前（エラーが発生するコード）

$broadcast_email_id = EmailModel::get_broadcast_email_by_hash( $hash );
// ... 中略 ...
EmailModel::insert_or_update_email_meta( 'is_unsubscribe', 1, $broadcast_email_id );

修正後

$broadcast_email_id = EmailModel::get_broadcast_email_by_hash( $hash );
// ... 中略 ...
if ( ! empty( $broadcast_email_id ) ) {
    EmailModel::insert_or_update_email_meta( 'is_unsubscribe', 1, $broadcast_email_id );
}

このガードを追加することで、ハッシュが無効でブロードキャスト ID が null のままでも、データベースエラーが発生しなくなる。購読解除ステータスの更新は問題なく行われるため、最低限の動作は保たれる。

データベースエラーが解消したか確認する方法

エラーログを監視して、同じメッセージが出力されなくなったかを確認する。WordPress のデバッグモードが有効な場合は、wp-content/debug.log を直接確認するか、管理画面からデバッグログを表示するプラグインを使うと手軽だ。サーバーのエラーログ（エラーログファイルや php-fpm のログ）にも同様のエントリがないかチェックする。

また、テスト用のメールを送信し、そのワンクリック解除リンクを実際にクリックして、エラーログに新たな記録が発生しないことを確かめるのが確実だ。

よくある質問

アップデートしてもエラーが続く場合は？

キャッシュ系プラグインやサーバーキャッシュが古いバージョンのファイルを保持しているケースがある。全キャッシュをクリアし、ブラウザのキャッシュも削除してから再度確認する。また、他のプラグインとの競合も考えられるため、標準テーマに切り替え、Mail Mint 以外のプラグインを一時的に無効化して切り分けを試みる。

一度発生したエラーログは削除したほうがよい？

特に削除する必要はないが、ログが肥大化してディスク容量を圧迫している場合は、ファイルを空にしたり、ログローテーションを設定したりするのが現実的だ。WordPress の debug.log は管理画面から直接内容を確認できるツールを使うのも手だ。

購読解除のメタ情報が記録されないとどんな問題が起きる？

ブロードキャスト単位での解除率や効果測定の集計が正しく取れなくなる可能性がある。ただし、購読解除そのものは正常に処理されているため、配信停止自体は問題なく行われている。レポートの精度を気にする場合は、エラー解消後に過去分のメタ情報を補完することを検討してもよい。

この記事のポイント

Mail Mint のワンクリック解除リンクでデータベースエラーが発生するのはプラグインの古いバグが原因
バージョン 1.30.0 以上への更新で根本的に解決する
更新できない場合は null チェックを追加する一時パッチで回避可能
エラーは購読解除の処理自体を止めるものではないが、ログの肥大化に注意
修正後はテストメールで解除リンクをクリックし、エラーログを確認する

佐々木太陽

Mail Mint, WordPress, データベースエラー, トラブル解決, プラグイン, メール配信, ワンクリック解除

お悩み・トラブル解決

2026年8月10日 0

Redis Object Cache有効時にPHP-FPMがクラッシュして503エラーが頻発する原因と対処法

Redis Object Cacheプラグインのドロップインを有効にしたWordPressサイトで、PHP-FPMのワーカープロセスがSIGSEGV（セグメンテーション違反）を起こし断続的に503エラーが発生する現象は、PHP本体のコア（Zend Engine）領域におけるメモリ破壊が根本原因だ。まずはオブジェクトキャッシュを無効化してサイトを安定させ、PHPのビルドバージョンやRedis拡張の状態を確認するのが最初の一手になる。

なぜRedis Object Cacheを使うとPHP-FPMが落ちるのか

障害の直接的な引き金は、Zend Engine VM の命令ハンドラ内で発生するSIGSEGVシグナルだ。これはPHP本体のコア実行エンジンが、本来アクセスできないメモリ領域に誤って触れたときにOSがプロセスを強制終了させる。エラーが発生する場所は拡張機能のコードではなく、PHP 8.5.9が持つVMの基本命令を処理する部分であるため、PhpRedisのような特定の拡張機能が直接のバグを抱えている可能性は低い。

クラッシュはリクエスト処理の初期には起こらず、PHP-FPM のワーカーが起動してから700～1,600秒以上経過したタイミングで突如発生する。この時間差は、徐々に進行するヒープの破壊（メモリの二重解放、解放後の使用、境界外書き込みなど）を示唆している。リクエストの処理中にどこかでメモリが不正に操作され、その結果として破壊された領域を後続のVM命令が触れたときにSIGSEGVが起こる流れだ。

Redis Object Cacheのドロップインが有効な場合にのみ再現するのは、オブジェクトキャッシュが大量の一時データをPHPのメモリ空間に出し入れすることで、潜在的なメモリ破壊の発生確率を高めているからだと考えられる。また、キャッシュ操作自体の頻度やデータ構造の複雑さが、PHP 8.5.9固有のレアな境界条件を偶然踏み抜いている可能性もある。

クラッシュが発生した場合、PHP-FPM マスタープロセスは該当の子プロセスを再起動するが、その間は該当ワーカーが応答できないため、Webサーバー（nginxやApache）がバックエンドのFPMに接続できず、フロントエンドに503エラーが断続的に現れる。

実際のクラッシュ発生箇所は次のバックトレースで特定されており、coreで発生していることはほぼ間違いない。

0 ZEND_SEND_VAL_EX_SIMPLE_SPEC_CONST_HANDLER (execute_data=…, opline=…)
at Zend/zend_vm_execute.h:6227

クラッシュ発生時

PHP-FPM 子プロセス

ZEND_SEND_VAL_EX_SIMPLE_SPEC_CONST_HANDLER 内

→ 解放済みメモリ領域にアクセス

→ SIGSEGV 発生 → プロセス強制終了

↓

フロントエンド

Webサーバー（nginx / Apache）

バックエンドのFPMに接続不可

→ 503 Service Unavailable を返す

Redis Object Cacheを安全に無効化する手順

サイトの安定が最優先だ。根本原因の調査は時間がかかるため、まずはオブジェクトキャッシュのドロップインを無効化し、クラッシュが起きない状態に戻す。無効化してもフロントエンドの表示が著しく遅くなるわけではないケースが大半だが、ショートコードやDBクエリの多い動的ページでは表示速度が一時的に落ちる可能性があることは把握しておく。

管理画面にログインできる状態なら、以下の手順で無効化する。もし503エラーの影響で管理画面にアクセスできない場合は、FTPやSSH経由で直接ファイルを削除する手順に進む。

STEP 1 「設定」→「Redis」画面の「キャッシュを有効にする」をオフにする

↓

STEP 2 「キャッシュをクリア」ボタンを押下してキャッシュを破棄

↓

STEP 3 プラグイン一覧からRedis Object Cacheを「停止」する

プラグイン自体を停止するとドロップイン（wp-content/object-cache.php）も無効化される。プラグインを停止したあと、念のためFTPやSSHでwp-content/object-cache.phpが削除されていることを確認するほうが確実だ。このファイルが残っていると、プラグインが無効でもキャッシュ機構だけが動き続ける。

管理画面にアクセスできない場合は、以下のいずれかの方法でobject-cache.phpを直接削除する。

FTPクライアントでwp-content/object-cache.phpを削除（または拡張子を.bakに変更）
SSHでrm wp-content/object-cache.phpを実行
wp-cliが使えるならwp redis disableを実行

いずれの操作のあとも、サイトが正常に表示され503が発生しなくなったことを確認する。これで一時的な安定化は完了だ。

PHP 8.5.9でのSIGSEGVを根本的に調査する方法

オブジェクトキャッシュを無効にしてサイトが安定したら、根本原因の調査に移る。クラッシュの位置がZend Engineコアである以上、PHPランタイムそのものの再ビルドや、利用しているPHPビルドの変更が最も確実な対策になる。

PHPのビルドを更新または再コンパイルする

この問題は特定のPleskビルド（plesk-php85-8.5.9-0redhat.9.260731.1229）で確認されている。Plesk環境であれば、PHPのコンポーネント更新を実行し、最新のマイナーパッチが適用されたビルドに差し替える。ビルド番号が異なるだけでZend Engineの挙動が変わる可能性があるからだ。Pleskの「ツールと設定」→「更新とアップグレード」から「PHP 8.5」のコンポーネント更新をチェックする。

ソースから自前でPHPをビルドしている場合は、configureオプションに--enable-debugを付けてビルドしたPHPをまずは検証環境にデプロイし、デバッグシンボル付きでクラッシュ時の詳細なコールスタックを取得する。商用サイトでデバッグビルドを使うとパフォーマンスが落ちるため、あくまでテスト用のステージング環境で行うこと。

PHPのセッションハンドラを確認する

Redis Object Cacheのドロップインが、意図せずセッションハンドラとしても機能しているケースがある。セッションデータがPHPの内部メモリ管理と衝突し、クラッシュを誘発している可能性も考えられるため、php.iniのsession.save_handlerがfilesまたは意図した値になっているかを確認する。redisが指定されていた場合は、セッションとキャッシュの分離を検討する。

Redisサーバー側のチューニングと接続方式を再検討する

今回の環境ではRedisとの接続にUnixソケットが使われている。UnixソケットはTCP接続より高速だが、カーネルのソケットバッファやパーミッションの問題が間接的にPHP-FPMのメモリ状態を不安定にすることもありうる。いったんWP_REDIS_SCHEMEをtcpに切り替えてしばらく様子を見るという切り分けも有効だ。

また、Redis側のmaxmemory-policyがnoevictionだと、メモリ上限に達したときに書き込みエラーが発生する。直接SIGSEGVを起こすわけではないが、エラー処理の過程でPHP内部の状態が破壊される可能性を完全には否定できない。allkeys-lruなど適切な追い出しポリシーを設定し、Redis自体のメモリ使用率にも注意を払う。

代替のオブジェクトキャッシュバックエンドを試す

Redis Object Cacheプラグインをどうしても使い続けたい場合は、PhpRedisとPredisのどちらのクライアントバックエンドを使ってもクラッシュが再現する以上、Redis以外のバックエンドをテストする価値がある。たとえばMemcachedをバックエンドとするObject Cache Proや、ファイルベースのキャッシュに一時的に切り替えて様子を見る。

とはいえ、Zend Engineコアでのクラッシュである以上、バックエンドを変えても根本解決には結びつかない可能性が高い。もしMemcachedやファイルキャッシュに切り替えても同じタイミングでクラッシュするなら、PHPビルドそのものの問題である確度がさらに上がる。

よくある質問

503エラーはRedis Object Cacheをやめれば必ず直るのか

PHP-FPMのワーカークラッシュが原因で起こっている503エラーであれば、ドロップインを無効化してクラッシュが発生しなくなれば解消する。ただしサーバーの同時接続数超過や他のPHP拡張の不具合など、別の原因で503が発生しているケースもあるため、エラーログを必ず確認する。

PHP 8.5系以外でも同じ現象は起こるのか

今回のクラッシュ位置（Zend Engineの特定の命令ハンドラ）がトリガーになっていることから、PHP 8.5の特定ビルドに限定される可能性が高い。ただしPHP 8.4や8.3の一部のビルドでも、メモリ安全性に関する潜在バグが残っていることはありうる。まずは該当のPHPマイナーバージョンにパッチが提供されていないか公式のバグトラッカーを確認する。

PHP-FPMのワーカー数を増やせば503は減るのか

クラッシュが断続的に発生しているだけなら、ワーカー数を一時的に増やすことで503の発生頻度を下げられる場合がある。ただし本質的には問題を隠しているだけであり、クラッシュが多発すると結局は全ワーカーが落ちてサイト全体が応答不能になるリスクは残る。根本対策にはならない点に注意が必要だ。

ドロップインを削除してもRedisは自動起動したままでいいのか

ドロップインを削除しただけではRedisサーバープロセスは稼働し続ける。メモリやCPUリソースをわずかに消費するが、WordPressが接続しなければ実害はほとんどない。必要に応じてRedis自体を停止しても構わないが、他のアプリケーションが同じRedisインスタンスを使っている場合は影響範囲を確認してから停止する。

PHPのバグ報告はどこに出せばいいのか

再現手順が明確で、デバッグシンボル付きのバックトレースが取得できているなら、PHPの公式バグトラッカー（bugs.php.net）に報告する。Plesk環境固有のビルドに問題がありそうな場合は、Pleskサポートにも並行してチケットを発行するとよい。報告時はPHPのビルド番号と再現手順をできるだけ具体的に記載する。

この記事のポイント

PHP 8.5.9の特定ビルドでRedis Object Cacheのドロップインが有効だと、Zend EngineコアでSIGSEGVが発生し503エラーが断続的に起こる
クラッシュはワーカー起動後700秒以上経過してから発生し、PhpRedisとPredisの両方で再現するため拡張機能固有のバグではない
応急処置としてobject-cache.phpを削除しオブジェクトキャッシュを無効化すればサイトは安定する
PHPのビルド更新、セッションハンドラの確認、Redis接続方式の変更などでPHP本体の潜在バグを回避できる可能性がある
根本解決にはPHPのバグ報告またはビルド差し替えが必要で、再発リスクを下げるにはステージング環境での検証が欠かせない

佐々木太陽

503エラー, PHP-FPM, Redis Object Cache, SIGSEGV, WordPress, トラブルシューティング

お悩み・トラブル解決

2026年8月9日 0

Speedixでプロファイリング用カスタムページを追加できない時の対処法

Speedixのプロファイリング設定で3つ目以降のページを追加するには、設定画面上部の検索フィールドに測定したいページのタイトルやスラッグを入力し、表示される候補から選択する。バージョン2.1.7以降ではこの操作が明確化され、追加ボタン代わりに機能する。

なぜ設定画面に「追加」ボタンがないのか

SpeedixはWordPressサイトのパフォーマンスプロファイリングに特化したプラグインで、任意のページ読み込み時間やクエリを詳細に計測できる。設定画面（「ツール」→「Speedix」）を開くと、デフォルトでホームページと1つの主要ページがプロファイリング対象として登録されている。そこへ新たなページを増やしたい場合、画面内に明示的な「追加」ボタンや「新規ページ」リンクは存在しない。このUI設計が混乱を招きやすい。

実際の追加手段は、画面上部にある検索フィールドだ。ここに任意の文字列を打ち込むと、既存の公開ページ・投稿・固定ページの中から、タイトルやURLスラッグに一致するものがオートコンプリートで候補表示される。目的のページをクリックするだけで、即座にプロファイリングリストへ追加される仕組みになっている。

バージョン2.1.6以前はこの検索フィールドの役割が説明されておらず、「どうやって追加するのか」という問い合わせが多発していた。最新バージョンへアップデートすると、入力欄のプレースホルダー文言や補助テキストが改善され、直感的に理解しやすくなっている。

STEP 1 「ツール」→「Speedix」を開き、画面上部の検索フィールドを確認する

↓

STEP 2 測定したいページのタイトルやスラッグの一部を入力する

↓

STEP 3 オートコンプリートの候補一覧から該当ページをクリックする

↓

STEP 4 下のプロファイリングリストに追加されたことを確認する

プロファイリング対象のページを実際に追加する手順

設定画面を開き現在の登録状況を確認する

WordPress管理画面の左メニューから「ツール」を選び、「Speedix」をクリックする。するとプロファイリングの設定ページが表示され、現在登録されているページ一覧が上部にリスト表示される。初期状態ではホームページ（フロントページ）と、直近でアクセスの多いページなどが2件ほど表示されているはずだ。

この画面で、リストのすぐ上に配置されているのが追加用の検索フィールドである。テキスト入力欄と虫眼鏡アイコンが表示されているので、ここが操作の起点となる。

検索フィールドにページ情報を入力する

フィールドに、追加したい固定ページや投稿のタイトルをそのまま入力してみる。たとえば「会社概要」や「キャンペーン特設ページ」といった日本語タイトルで問題ない。スラッグ（URLの最後の部分）がわかっているなら、「about」「campaign」のように英数字で絞り込んでもよい。

何文字か打ち込むと、その文字列を含む公開済みのページ群が検索され、フィールドの下にドロップダウン形式で候補が表示される。このオートコンプリート機能は、投稿タイプ（固定ページ・投稿）を問わず、公開ステータスが「公開」になっているものだけが対象だ。

候補をクリックして追加する

目的のページが候補に出てきたら、その行をクリックする。クリックした瞬間、画面下部のプロファイリングリストに新しい行が追加される。追加と同時にバックグラウンドで最初の計測が走るため、数秒後に読み込み時間やクエリ数などのデータが表示される。

検索候補に出てこない場合は、そのページが本当に公開状態かを確認する。非公開や下書きのページは計測対象にできない。また、カスタム投稿タイプで作成されたページ（例：WooCommerceの商品ページ）も、テーマやプラグインが適切に公開ステータスを返している限りは候補に表示される。

追加したプロファイリングページを管理・削除する

登録したページが不要になったり、計測を停止したい場合は、リスト右端に表示されるゴミ箱アイコンまたは「削除」リンクをクリックする。確認ダイアログは出ないものの、即座にリストから消え、それ以降の計測は行われなくなる。

削除しても過去の計測データはデータベースに蓄積されたままになる。完全に履歴を消去したい場合は、Speedixが提供する「データリセット」機能を使うか、プラグインを一度無効化して再有効化する方法もある。ただし再有効化するとすべてのカスタムページ設定が初期化されるため、必要なページは再度追加し直す必要がある。

よくある質問

検索しても目的のページが候補に出てこないのはなぜか

公開状態でない（下書き・非公開・パスワード保護）ページは候補に表示されない。また、何らかのキャッシュプラグインがREST APIの応答を妨げていると、検索機能自体が動作しない場合がある。その場合はキャッシュを一時的にクリアするか、プラグインの競合を切り分けるために他のプラグインを停止してから試すとよい。

一度に登録できるプロファイリングページ数の上限はあるか

Speedixに明示的な上限は設けられていない。ただし計測対象が増えるほどバックグラウンド処理の負荷が上がり、サイト全体のパフォーマンスに影響を与える可能性がある。数ページから十数ページ程度に絞って運用するのが現実的だ。

追加したページの計測頻度は変更できるか

デフォルトでは1時間に1回程度の間隔で自動計測される。この頻度は設定画面の「計測間隔」項目から変更可能で、最短15分から24時間まで選択できる。ただしあまり短い間隔にするとサーバーリソースを消費するため、必要なページだけ短く設定するといった使い分けが推奨される。

バージョン2.1.6以前の古いSpeedixを使っている場合はどうすればよいか

まずはプラグインを最新版（2.1.7以上）に更新する。検索フィールドの補足説明やプレースホルダーが改善され、操作方法が一目でわかるようになる。更新が何らかの理由でできない場合は、画面上部のテキスト入力欄が追加機能を兼ねていると理解して、前述の手順でページを追加すれば問題ない。

この記事のポイント

Speedixのプロファイリングページ追加は検索フィールドから行う
ページタイトルやスラッグの一部を入力すると候補が表示される
候補をクリックするだけで即座に追加され計測が始まる
公開状態のページのみが検索対象なので下書きなどは追加不可
最新バージョンではUIが改善され操作が直感的になった

佐々木太陽

Speedix, WordPressプラグイン, カスタムページ, トラブル解決, パフォーマンス測定, プロファイリング

お悩み・トラブル解決

2026年8月9日 0

Wordfence 8.2.2 で前台に preg_replace() 非推奨エラーが出た時の対処

Wordfence 8.2.2 を導入した WordPress 7.0.3 のサイトで、前台ページやログイン画面に Deprecated: preg_replace() から始まる非推奨（デプリケーション）エラーが表示される場合、まず WP_DEBUG 設定を確認して本番環境でのエラー表示を抑制し、次に Wordfence 本体を最新版へ更新する のが最短の対策だ。

なぜ本番サイトの前台に非推奨エラーが表示されるのか

非推奨エラー（Deprecated 通知）は、PHP の将来のバージョンで廃止される古い書き方を使っている場合に発生する。Wordfence 8.2.2 内部のルール処理ライブラリ wf-waf が preg_replace() 関数に null を渡しており、PHP 8.1 以降でこの挙動が非推奨となったことが直接の原因だ。

本来このレベルの通知は、本番サイトでは表示されないよう WordPress が抑制する仕組みになっている。しかし 何らかの理由でデバッグモードが有効になっているか、エラー報告レベルが高く設定されている と、前台に生の PHP エラーメッセージが露出してしまう。これが今回のケースの本質的な問題だ。

さらにこのエラーが「headers already sent」という警告を誘発し、ログイン処理や Cookie 設定などの HTTP ヘッダー操作が失敗する二次被害も報告されている。前台の表示崩れや管理画面へログインできないトラブルに発展するため、早期の対応が欠かせない。

すぐに前台からエラー表示を消す応急処置

更新を待つ前に、まずは本番環境でエラーが一般人に見えている状態を解消する。手順は以下の3ステップだ。

STEP 1 wp-config.php で WP_DEBUG を false に設定する

↓

STEP 2 Wordfence プラグインを最新版に更新する

↓

STEP 3 サイトキャッシュとサーバーキャッシュをすべて削除して動作確認する

wp-config.php で WP_DEBUG を確認・修正する

FTP クライアントやサーバーのファイルマネージャーで WordPress をインストールしたルートディレクトリにアクセスし、wp-config.php を開く。WP_DEBUG が true になっていれば、以下のように false へ変更する。

define( 'WP_DEBUG', false );

開発用途でデバッグログだけは残したい場合は、WP_DEBUG_LOG と WP_DEBUG_DISPLAY を併用する。これで前台にはエラーを表示せず、ログファイルにだけ記録できる。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // /wp-content/debug.log に記録
define( 'WP_DEBUG_DISPLAY', false ); // 画面には表示しない

ファイルを上書き保存したら、サイトをリロードして前台からエラーメッセージが消えたか確認する。

Wordfence を最新版に更新する

この preg_replace() の非推奨問題は、Wordfence 開発チームが認識して修正に取り組んでいる可能性が高い。管理画面にアクセスできるなら「プラグイン」→「インストール済みプラグイン」で Wordfence の更新を確認し、最新版がリリースされていれば即座に適用する。

管理画面すらエラーで開けないという報告も多い。その場合は FTP で /wp-content/plugins/wordfence/ ディレクトリを一時的にリネーム（例 wordfence_old）して無効化し、管理画面へアクセスできる状態にする。管理画面に入れたら、改めて Wordfence を最新版に更新して再有効化すればよい。

キャッシュを全削除して状態を確定させる

PHP 設定やプラグインを変更しても、キャッシュが残っていると古いエラー画面が表示され続ける。以下のキャッシュを徹底的にクリアする。

WordPress のキャッシュプラグイン（WP Rocket や W3 Total Cache など）の全キャッシュ削除
サーバー側の OPcache や Nginx FastCGI Cache のクリア
CDN を利用している場合は CDN のキャッシュもパージ

エラー表示あり前台に PHP 非推奨エラーが丸見え

→

修正後前台は通常表示・管理画面にもログイン可能

それでも改善しない場合の追加対応

上記の手順を実行してもエラーが消えない、あるいは管理画面にまったく入れない状況が続くなら、次の手を試す。

Wordfence を手動で最新 ZIP に上書きする

WordPress 管理画面から更新できない場合、WordPress.org の Wordfence 公式ディレクトリから最新の ZIP ファイルをダウンロードし、FTP で展開する。手順は次のとおり。

現在の /wp-content/plugins/wordfence/ をリネームして退避
ダウンロードした ZIP を解凍し、wordfence ディレクトリをアップロード
管理画面から Wordfence を有効化し、WAF の最適化を再実行

PHP のエラー報告レベルを一時的に緩和する

レンタルサーバーのコントロールパネルや php.ini で error_reporting を E_ALL & ~E_DEPRECATED に設定すれば、非推奨通知をまとめて抑制できる。ただしこの方法は問題の先送りになるため、あくまで Wordfence 更新が間に合わない場合の緊急措置と位置づける。

別のセキュリティプラグインへ一時的に切り替える

サイトのセキュリティを完全に落とせない事情があるなら、Wordfence を無効化している間だけ、別の軽量ファイアウォール系プラグインで防御を維持する手もある。ただし切り替えの手間と、切り戻し時に設定がリセットされる可能性は考慮が必要だ。

よくある質問

Wordfence を無効化したまま運用しても大丈夫か

無効化中はファイアウォールとマルウェアスキャンがすべて停止するため、できるだけ数時間以内に最新版へ更新して再開するのが望ましい。どうしても長引く場合は、サーバー側の WAF 機能や .htaccess によるアクセス制限で最低限の防御を維持する。

PHP バージョンを下げればこのエラーは消えるのか

PHP 7.4 など古いバージョンに戻せば preg_replace() の非推奨警告は出なくなるが、PHP 本体のセキュリティサポートが切れているバージョンを使うことは推奨しない。Wordfence の更新で根本対応し、PHP は 8.1 以降のサポート対象バージョンを維持するのが安全な選択だ。

他のプラグインで同様の Deprecated エラーが出た場合の対処は

まず該当プラグインが最新版かを確認する。最新で出るなら、開発元のサポートフォーラムに PHP バージョンとエラー全文を添えて報告する。本番環境では WP_DEBUG_DISPLAY を false にしつつ WP_DEBUG_LOG で記録を取る運用が基本だ。

Wordfence の代わりになる無料プラグインはあるか

無料で総合的な防御を提供する代替としては、Solid Security（旧 iThemes Security）や Sucuri Security が挙げられる。ただし機能や設定項目が異なるため、移行前に必ずテスト環境で動作検証を済ませる必要がある。

この記事のポイント

前台に PHP 非推奨エラーが出る原因は WP_DEBUG 設定とプラグインの対応遅れ
まず wp-config.php で WP_DEBUG を false または WP_DEBUG_DISPLAY false にする
Wordfence を最新版に更新すれば preg_replace() 問題は解消に向かう
管理画面に入れない場合は FTP でプラグインをリネームして緊急アクセスを確保する
PHP のエラー報告レベル操作はあくまで緊急避難であり恒久対応ではない

佐々木太陽

PHP, Wordfence, WordPress, セキュリティ, トラブル解決, 非推奨エラー

お悩み・トラブル解決

2026年8月8日 0

WooCommerce更新後に注文編集ができない場合の権限設定と解決手順

WooCommerce のアップデート後に、注文の編集やステータス変更ができなくなった場合は、該当するユーザーロールに WordPress の基本的な権限である edit_posts を割り当てることで解決する。WooCommerce 9系と HPOS の組み合わせでは、カスタム権限だけでは注文管理画面を表示できなくなる仕様変更が起きている。

WooCommerce アップデート後に注文を編集できなくなった原因

WooCommerce 10.9.4 以降、特に HPOS（高パフォーマンス注文ストレージ）を有効にし、互換性モードを無効化している環境でこの問題が発生しやすい。これまでは edit_shop_order や edit_others_shop_orders といった WooCommerce 固有の権限だけで注文管理ができていた。だが、内部的な権限チェックが強化され、注文画面を表示するために汎用的な edit_posts 権限も必須になった。

この変更は、WordPress のコア機能と WooCommerce の注文データの整合性を高めるためのものだ。「このサイトで重大なエラーが発生しました」といったメッセージではなく、単に「権限がありません」と表示されたり、注文一覧ページ自体が空欄になるといった症状が現れる。PublishPress Capabilities や User Role Editor などのプラグインで、注文管理だけに特化したカスタムロールを作成している場合に特に影響を受ける。

Before エラー状態

割り当て権限
– edit_shop_order
– edit_others_shop_orders
– edit_posts なし

注文編集画面にアクセス不可。「権限がありません」または一覧が表示されない。

↓

After 解決後

割り当て権限
– edit_shop_order
– edit_others_shop_orders
– edit_posts（新たに追加）

注文編集画面にアクセス可能。ステータス変更や内容の更新が正常に行える。

`edit_posts` 権限を追加して問題を解決する具体的な手順

解決策はシンプルだ。注文管理を担当するユーザーロールに edit_posts 権限を付与する。この操作によって、注文以外の「投稿」や「固定ページ」へのアクセス権も与えたくない場合は、後続の「より厳密な権限制御を行うための注意点」のセクションで紹介する追加の調整が必要になる。

STEP 1 PublishPress Capabilities または User Role Editor を開く

↓

STEP 2 注文管理用のカスタムロールを選択する

↓

STEP 3 「投稿を編集する（edit_posts）」にチェックを入れて保存する

現在のユーザーロールの権限を確認する

まず、どのロールに問題が起きているのかを特定する。ユーザーが複数のロールを持っている場合、権限は加算される仕組みだ。管理者権限で問題が起きている場合は、プラグインの競合など別の原因を疑う必要がある。

PublishPress Capabilities の無料版を使っていれば、管理画面の「Capabilities」メニューから各ロールの権限一覧を確認できる。画面上部の「Select Role to View / Edit」ドロップダウンで、問題のロールを選択し、権限の一覧を表示させよう。

`edit_posts` 権限を該当ロールに割り当てる

権限の一覧画面で「Core」タブを開き、「Posts」セクションを探す。その中にある「edit_posts」のチェックボックスにチェックを入れ、画面下部の「変更を保存」ボタンをクリックする。これで、指定したロールに汎用的な投稿編集権限が付与され、WooCommerce の注文画面にもアクセスできるようになる。

User Role Editor を使っている場合も手順はほぼ同じだ。管理画面の「ユーザー」→「User Role Editor」を開き、対象ロールを選択して、権限リストから「posts」をフィルタリングし、「edit_posts」にチェックを入れて保存する。

より厳密な権限制御を行うための注意点

edit_posts を付与すると、デフォルトでは「投稿」と「固定ページ」の編集画面にもアクセスできるようになる。これは、WordPress の権限システムが投稿タイプごとに細かく権限を分けていないことに起因する。注文だけを管理させたいロールには、これは望ましい状態ではないだろう。

投稿や固定ページへのアクセスを制限するには、別の方法で管理画面メニューを非表示にする必要がある。よく使われるのは「Admin Menu Editor」プラグインだ。このプラグインを使えば、特定のユーザーロールに対して不要なメニュー（投稿、固定ページ、コメントなど）を非表示にできる。メニューを隠すだけでは直接URLを入力されるとアクセスできてしまうため、完全にブロックしたい場合は、current_user_can() 関数を使ったカスタムコードを functions.php に追加する方法もある。

よくある質問

管理者権限でも注文を編集できなくなった場合はどうするのか

管理者はデフォルトで edit_posts を含むすべての権限を持っているため、今回の原因とは別の問題だ。まずはすべてのプラグインを停止し、テーマをデフォルトに戻して競合の有無を確認する。HPOS 互換モードを一時的に再有効化して症状が改善するかもテストする価値がある。

`edit_posts` を追加してもアクセスできない場合は他に何を確認すべきか

WooCommerce の注文には、edit_shop_orders や view_admin_dashboard といった権限も必要になる。後者が不足していると、管理画面自体へのアクセスが制限される可能性がある。また、キャッシュ系プラグインやセキュリティプラグインが権限チェックに干渉しているケースもあるため、これらの設定も見直す。

HPOS の互換モードを再有効化すれば解決するのか

一時的な回避策としては機能する可能性が高い。しかし、HPOS の互換モードは将来的に廃止される予定の過渡的な機能だ。根本解決のためには、ここまでに説明した権限の適切な設定を行い、HPOS を有効化した状態で動作させることが推奨される。

コードを使って権限を自動付与する方法はあるか

特定のロールに対してテーマやプラグインの有効化時に権限を追加したい場合、WP_Role クラスの add_cap() メソッドを使う。たとえば、functions.php やカスタムプラグイン内で、get_role('shop_manager')->add_cap('edit_posts') のように記述する。このコードは一度だけ実行すればよいが、権限の変更を明確にするために、プラグインのアクティベーションフックで実行することが望ましい。

この記事のポイント

WooCommerce の更新後、注文の編集ができない原因は edit_posts 権限の不足にある
権限管理プラグインで該当ロールに edit_posts を割り当てるだけで問題は解決する
不要な投稿画面へのアクセスは、Admin Menu Editor などのプラグインで個別に制限する必要がある
管理者権限での同様の症状は、プラグイン競合といった別の原因を疑う
HPOS 互換モードの再有効化は一時しのぎに過ぎず、権限設定による根本解決が推奨される

佐々木太陽

WooCommerce, サイト管理, セキュリティ, トラブル解決, 権限設定

お悩み・トラブル解決

2026年8月8日 0

大規模WordPressサイトでプラグインが途中で止まるエラーの解決法

大規模なWordPressサイトでプラグインの一括処理が「0/」と表示されたまま進まず「error-generation stopped」で停止する現象は、PHPの実行時間やメモリ制限が主な原因だ。設定を調整しバッチサイズを小さくすれば、処理を最後まで走らせられる。

大規模サイトでプラグインが途中で止まる原因

WordPressの管理画面から実行するプラグインの一括処理は、Webサーバーを介したHTTPリクエストのなかで動く。このリクエストにはサーバー側で複数の時間制限がかかっており、処理がそれを超えると強制終了する仕組みだ。

とくに影響が大きいのは以下の3つだ。

PHPの最大実行時間（max_execution_time）
PHPのメモリ制限（memory_limit）
WebサーバーやFastCGIのリクエストタイムアウト

5000件を超える投稿があるような大規模サイトでは、1回のリクエストですべてのデータを処理しようとすると、これらの制限に引っかかる。結果として「0/」のまま進捗が表示されず、しばらくしてエラー停止する。

プラグインのバッチ処理設定を見直す

最初に確認すべきは、そのプラグインがもつ「一度に処理する件数」の設定だ。多くの一括処理系プラグインは、内部的にデータを小分けにして処理するバッチサイズを指定できる。

プラグインの設定画面を開き、「1回あたりの処理件数」や「Records per iteration」といった項目を探す。デフォルトでは無制限に近い値になっていることも多く、これを10件〜50件程度まで下げるだけでエラーが解消するケースは多い。

バッチサイズを小さくすると処理全体の回数は増えるが、1回あたりの負荷が下がるためPHPやサーバーの制限にかかりにくくなる。この調整だけで問題が解決するなら、最も手軽でリスクの低い対処法だ。

Before（エラー発生）

一括処理を開始する

STEP 1 投稿データを読み込み中 (0/、)

⚠ 数秒後に「error-generation stopped」で停止

↓

After（設定調整後）

バッチサイズを小さくして再試行する

STEP 1 少量ずつ確実に処理 (20/134)

✅ 最後まで完了

■ Before　■ After

上の図は、バッチサイズを調整するだけで一括処理が正常に完了する流れを表している。

PHPの最大実行時間とメモリ制限を引き上げる

バッチサイズの調整だけでは改善しない場合、PHP側の制限値が厳しすぎる可能性が高い。とくにレンタルサーバーの共用プランでは、max_execution_time が30秒、memory_limit が128MB程度に設定されていることが多い。

まず wp-config.php に以下の行を追加して制限を緩和する。

set_time_limit(300);
define('WP_MEMORY_LIMIT', '256M');

set_time_limit(300) はPHPの最大実行時間を300秒に延長し、WP_MEMORY_LIMIT はWordPressが利用できるメモリ上限を256MBに引き上げる。必要に応じて値をさらに増やしても構わない。

サーバー環境によっては、php.ini や .user.ini で直接 max_execution_time と memory_limit を指定できる場合もある。どちらの方法が有効かはサーバー仕様に依存するため、変更後は必ず phpinfo() やサイトヘルス画面で反映を確認する。

また、管理画面からの実行に限らず、サーバー負荷の高い処理ではメモリが不足しがちだ。256MBでも足りないようであれば512MBまで引き上げることを検討する。

サーバー側のリクエストタイムアウトを確認する

PHPの実行時間を延ばしてもエラーが続くなら、WebサーバーやFastCGIのリクエストタイムアウトが原因だ。Apacheのmod_fcgidを使っている環境では、FcgidIOTimeout や FcgidBusyTimeout が短く設定されていると、PHPが処理中でも接続を切られてしまう。

この設定はサーバー全体に影響するため、共用サーバーではユーザー側で変更できないケースがほとんどだ。該当しそうな場合はサーバー管理会社のサポートに「管理画面の長時間処理が途中で切れる」と伝え、設定の緩和が可能か問い合わせる。

VPSや専用サーバーを利用しているなら、ApacheやNginxの設定ファイルでタイムアウト値を直接編集できる。変更後はWebサーバーの再起動を忘れずに行う。

WP-CLIでバックグラウンド処理を実行する

サーバーがWP-CLIに対応しているなら、ブラウザからのHTTPリクエストではなくコマンドラインからプラグインの処理を走らせるのが最も確実な回避策だ。CLI実行にはWebサーバーのタイムアウト制限が適用されないため、大規模データでも安全に処理できる。

ただし、すべてのプラグインがWP-CLIコマンドを提供しているわけではない。まずプラグインの公式ドキュメントで「WP-CLI commands」の有無を確認し、該当するコマンドがあればターミナルから実行する。

実行例は以下のような形だ。

wp plugin-command run --batch-size=20

WP-CLIが使えない場合は、処理を手動で分割してブラウザから複数回に分けて実行する方法も有効だ。たとえばカテゴリ別や投稿タイプ別に絞り込み、1回の処理対象を数百件以下に抑える。

STEP 1 バッチサイズを10〜50件に下げる

↓

STEP 2 PHPの実行時間とメモリ制限を引き上げる

↓

STEP 3 サーバーやFastCGIのタイムアウトを緩和する

↓

STEP 4 可能ならWP-CLIで実行する

これらの手順を順に試すことで、多くの大規模サイトで発生するタイムアウトエラーは解決できる。

よくある質問

共有サーバーでもPHPの最大実行時間は変更できるか

wp-config.php での set_time_limit() や .user.ini による上書きが許可されていれば可能だ。ただしサーバー側で一律に上限が決められており、設定値を超えて延長できない場合もある。

バッチサイズを小さくしても途中で止まる場合はどうすればよいか

メモリ制限と最大実行時間の両方を引き上げた上で、さらにバッチサイズを絞る。それでも改善しない場合は、サーバー側のリクエストタイムアウトが原因の可能性が高いため、サポートへの問い合わせやWP-CLIの利用を検討する。

「error-generation stopped」以外のエラーが表示されることはあるか

「このサイトで重大なエラーが発生しました」というWordPressの標準エラー画面や、「504 Gateway Timeout」といったサーバーエラーが表示されることもある。いずれも根本的な原因は処理時間の超過であることが多い。

特定のプラグインでしか発生しない場合はどう対処するか

まずそのプラグインの設定画面でバッチサイズを調整する。設定項目がなければ、開発元に問い合わせてフックやフィルターでバッチサイズを変更できないか確認する。別のプラグインで代替できる機能であれば、乗り換えも選択肢になる。

設定を変えてもまったく改善しない場合はサーバー移転が必要か

すべての設定を試しても解決しないなら、現在のサーバープランが大規模サイトの運用に適していない可能性が高い。VPSや専用サーバーなど、より自由度の高い環境への移行を検討するタイミングだ。

この記事のポイント

大規模サイトの一括処理停止はPHPとサーバーの制限が原因
プラグインのバッチサイズを10〜50件に下げると効果的
max_execution_timeとmemory_limitの引き上げも併用する
共用サーバーではサポートへの問い合わせが必要な場合もある
WP-CLIが使えれば最も確実に回避できる

佐々木太陽

PHP設定, WordPress, タイムアウト, バッチ処理, プラグインエラー, 大規模サイト

お悩み・トラブル解決

次ページへ »

投稿者アーカイブ

エラーメッセージが示す根本的な原因は二つだけ

最初に確認すべきwp-config.phpの設定

データベース名（DB_NAME）の確認

ユーザー名（DB_USER）とパスワード（DB_PASSWORD）の精査

ホスト名（DB_HOST）の指定

データベースサーバーが稼働しているか確認する

サーバー管理画面からの状況確認

phpMyAdminで直接ログインを試みる

それでも解決しない場合の追加確認項目

データベースユーザーの権限を再確認する

データベースの破損をチェックする

wp-content/db.php ファイルの存在を疑う

マルチサイトのwp-config.php設定を見直す

よくある質問

wp-config.phpの修正後にエラーが変わらないのはなぜか

パスワードやユーザー名は合っているのに接続できない

レンタルサーバーのサポートに連絡するタイミングはいつか

ローカル環境で同じエラーが出る場合の対処法は

データベースの修復をしてもすぐにエラーが再発する

この記事のポイント

なぜ商品ページで「jQuery is not defined」が起きるのか

async 読み込みを強制している箇所を特定する手順

プラグインのコードを修正して async を外す方法

async 強制付与の無効化

prefetch リンクの除去

functions.php で上書きする方法

修正後も注意すべきキャッシュと最適化プラグインの影響

よくある質問

async と defer の違いは何か

プラグイン本体を修正するとアップデートで上書きされないか

async を外しても「jQuery is not defined」が消えないのはなぜか

子テーマで対策する利点は何か

この記事のポイント

なぜRank Mathを有効にするとElementorパネルが固まるのか

まずは本当に競合かどうかを確実に特定する

プラグイン停止モードを使った最小構成テスト

ブラウザコンソールでエラーの詳細を確認する

Elementorパネルを復旧させる現実的な4ステップ

STEP 1 Rank Mathを無効化して即座に確認する

STEP 2 キャッシュをあらゆる層で削除する

STEP 3 Rank Mathのモジュールを調整する

STEP 4 両プラグインを最新状態に保つ

再発を防ぐために日頃からできること

よくある質問

他のSEOプラグインでも同じことが起きますか

Rank Mathを無効化するとSEO順位に影響しますか

キャッシュをすべて消さずに直す方法はありますか

プレビュー画面だけ固まる場合はどうすればいいですか

競合が直ったのにしばらくすると再発します

この記事のポイント

なぜ PixelYourSite が FastCGI キャッシュを無効化するのか

設定変更で PHP セッションを無効化する手順

「Disable PHP Sessions」の場所と見つけ方

設定保存後に必ずキャッシュをクリアする

設定変更後の影響とデータ精度について

PHP セッション無効化後も問題が続く場合の追加チェック

キャッシュ除外設定の見直し

他のプラグインがセッションを開始していないか調べる

よくある質問

「Disable PHP Sessions」を有効にしてもトラッキングは引き続き動作するか

Nginx FastCGI キャッシュ以外のキャッシュ（Varnish や CDN）でも効果はあるか

この設定はサイトの表示速度にどれくらい影響するのか

PixelYourSite を最新版にアップデートしてもセッション問題は解決されないのか

この記事のポイント

なぜワンクリック解除でデータベースエラーが発生するのか

Mail Mint を最新版にアップデートしてエラーを解消する

更新後にエラーが止まったか確認する

どうしてもアップデートできない場合の一時的な対処

データベースエラーが解消したか確認する方法

よくある質問

アップデートしてもエラーが続く場合は？

一度発生したエラーログは削除したほうがよい？

購読解除のメタ情報が記録されないとどんな問題が起きる？

この記事のポイント

なぜRedis Object Cacheを使うとPHP-FPMが落ちるのか

Redis Object Cacheを安全に無効化する手順

PHP 8.5.9でのSIGSEGVを根本的に調査する方法

PHPのビルドを更新または再コンパイルする

PHPのセッションハンドラを確認する

`edit_posts` 権限を追加して問題を解決する具体的な手順

`edit_posts` 権限を該当ロールに割り当てる

`edit_posts` を追加してもアクセスできない場合は他に何を確認すべきか