wp-adminで奇妙な404エラーを取り除く方法は？

約70のアクティブなプラグインを使用してWordPressサイトを実行しています。

/wp-admin/どこからともなくポップアップするページに、ランダムなエラーページ（「Not Found」ですが、ヘッダーをチェックして404かどうかは確認していません）が頻繁に表示されます。

単に再試行するだけでエラーは解決しますが、プラグインのアップグレード中にエラーが発生すると、非常に不便です（自動再アクティブ化が失敗するため）。この同じ問題は、ダッシュボードの特定のモジュールが時々ロードに失敗する原因であると思います。

私がインストールしたプラグインのリストを考えると、誰かがこの問題を引き起こす可能性のあるそれらのプラグインの問題を知っていますか？

編集：

ホスティング情報：DreamHost; サーバーはApache httpdを使用してカスタムDebianビルドを実行していると思います

404ミスファイアと思われる問題で1日中問題を抱えていました。

とにかく、私はDreamhostのテクニカルサポート担当者とのチャットを終えたところです。彼らが持っているユーザーアカウントがプロセスのメモリリソースの制限（すべてのプロセス）に達しており、それがhtaccess関連の問題のように見えました。まったく呼び出されるべきではないhtaccessファイルから断続的な404エラーが発生しました！それはお化け屋敷サーバーを備えたドリームホストでした。

どうやら、ドリームホストが使用するプロセスキルロボットは、途中でWebプロセスをキルし、何らかの理由で（今はゾンビ）Apacheが実際にジョブを完了しようとします（サブリクエストの魅力的な終わりからきれいに終了するために最善を尽くしています）私の推測です）。メインのhttpログに500エラーをスローしますが、その後、実際には実行されるべきではなかった書き換え条件とルールを実際に実行します（上記の標準ファイル-fとディレクトリ-d htaccessファイルを使用）。新しいログエントリを書き込まないでください！新しい（見えない人）リクエストは、htaccessファイルの最後の行でインデックスファイルをトリガーします

dreamhostベーシックアカウントのリソース制限に注意してください。それらの制限を超えて、mod_rewrite行にhtacessがあると、ハロウィーンの夜にしか当てはまらない奇妙なものが表示されます-目に見えない男性、幽霊404が！アンデッドプロセス！ゾンビアパッチ！htaccessはそれ自体で動きます！うわぁ！

これが数時間の痛みを避けるのに役立つことを願っています。

これをデバッグする唯一の方法は、別のプラグインを無効にする前に問題を再現しようとするたびに、一度に1つのプラグインを無効にすることです。WPの管理に関係するプラグインから始めて、通常のテーマプラグイン、ウィジェットなどに移ります。

「Not Found」ページがより適切に提供されていることを確認し（Operaでブラウジングし、ヘッダーを表示するInfoパネルを開くか、Firefoxで参照し、Firebugで「Net」パネルを有効にして）、すべてを検索します。プラグインで直接提供されているかどうかを確認します。そうでない場合は、Webサーバーのログを調べて、提供できない正確なリソースを見つけます。プラグインが何らかのリダイレクトまたは書き換えを行っている可能性があるため、404の原因となっているのは、ブラウザに表示されているURLとは限りません。

私は自分の経験だけを関連付けることができます。これまでのところ、すべての問題を一気に修正するための「明確な」ルールを見つけていません。

DreamHostの設定の主な問題は、メモリ消費量を最小限に抑えるという永遠の戦いで、可能な限り多くの機能、つまり帯域幅（訪問者にとっては良い！）またはCPU（良いサーバーの場合、DreamHostはRAMを制御するほどの積極的なCPU消費を制御しません）。たとえば、これはgzipされたHTML + CSS（CPU + RAMを消費します）またはいくつかのMinifyプラグイン（RAMも消費します）のいずれかを取り除くことを意味します。より洗練されたキャッシュ（私はW3 Total Cache、または少なくともWP Super Cacheを使用するのが好きです）、より多くのRAMも消費されます。

同様に、パフォーマンスを向上させるためにMySQLクエリの数を制限する多くのプラグインは、代わりにRAMを消費します。したがって、貴重なRAMの消費を回避しながら、サイトを良好なパフォーマンスで返信し続けることができるトレードオフを見つけることは困難な作業です。

これまでのところ、多忙なサイトでの私の最高の結果は、明らかにRAMを大量に消費するPage Speed OptimizationとExtra Web Securityのチェックを外し、代わりにW3 Total CacheとCloudflare（無料のリバースプロキシサービス）の組み合わせに依存することです。Cloudflareは「Extra Web Security」モジュールと実質的に同じことを行いますが、DreamHostの外部で実行されるため、問題ありません。W3 Total Cacheは大量のメモリを消費しますが、ページがローカルに静的に保存されると、Cloudflareはそれらを非常に効率的にキャッシュします。そのため、投稿の編集中に404/500を取得する可能性があります。 DreamHostが404または500を指定した場合でも）。

また、この記事のおかげで、FastCGIは「通常の」CGIよりも多くのRAMを使用することがわかりました。また、PHP 5.3はRAMの管理に優れているため（ガベージコレクションのアグレッシブが高く、メモリリークが少ない）、ページスピードの最適化も追加のWebセキュリティも使用せずに、実験的にPHP 5.3 CGI（FastCGIではない）に切り替え、W3 Total Cache + Cloudflareに依存しています。サイトを加速します。現在、バックオフィスは低速ですが（CPUの消費が多い！）、少なくとも404/500は表示されていません（これまでのところ！）。

私はまだその組み合わせに不満があるので、RAMの消費をさらに減らし、適切なパフォーマンスを得られるように、DreamHostの設定を調整し続けます。@dgwが言ったように、私も多くのプラグインを使用します—私はそれらの機能が必要だからです。DreamHostでWPをホストしているすべての人がブログのニーズを単純に持っているわけではありません。サイトが複雑になるほど、必要な機能も増えます...それがWordPressの優れた点です。本当に必要なプラグインを使用するだけでよく、ニーズがほとんどない場合は、コアWPのインストールをシンプルに保ちます。ただし、プラグインは必ずしも「悪い」ものではなく、サイトでそれほど重いものでもありません。しかし、一部のユーザーが大量のRAMを消費する可能性があるのは事実です...

これは大まかな考えです。「ヘッダーが設定されている」「実際の」404エラーが発生した場合は、プラグインを検索してPHP header()関数と404番号を探すことができます。これにより、プラグインの数を70からいくつかにドリルダウンできます。次に、それらを確認するだけです。

これは、特定のPHP関数呼び出しの検索を提供するEclipse PDTのようなIDEで簡単に実行できます。

その次に、それが正常に機能する保証はありませんが、ヘッダー設定にフックするプラグインを記述し、どのコードが実際に潜在的な404（バックトレース）を設定しているかをトレースすることができます。これは、プラグインがWordPress API関数を使用している場合にのみ機能します。PHP関数を探す最初の方法は、WP APIに関係なく機能します。

必要な詳細情報：

1）なぜそれほど多くのプラグインがあるのですか？

2）ホスティングプロバイダーはどのOSを実行していますか？

3）どのWebサーバー？

4）httpdサーバーログ、特にエラーログにアクセスできますか？

5）これらの問題を取り巻く期間内のエラーログには何が示されていますか？

（さて、正直に言うと、「WordPressを実行している平均的なJ6Pにこの正確な質問があるかもしれない場合、少なくとも上記の5つの質問に答えるようにJ6Pに指示することから始めることができます...）