Wp-adminで奇妙な404エラーを取り除く方法は？
私は約70のアクティブプラグインでWordPressサイトを運営しています。
何度も現れる/wp-admin/ページには、頻繁にランダムなエラーページが表示されます（「Not Found」、ヘッダーが404かどうかを確認していません）。
単純にもう一度試すだけでエラーは解決しますが、プラグインのアップグレード中にエラーが発生した場合（自動再アクティブ化が失敗するため）、非常に不便です。私はこれと同じ問題が私のダッシュボード上の特定のモジュールが時々ロードに失敗する原因となっていると思います。
私がインストールしたプラグインのリストを考えれば 、誰かがこの問題を引き起こすかもしれないそれらの間またはその間の問題について知っていますか？
編集する
ホスティング情報：DreamHost。私はサーバーがApache httpdを使ってカスタムDebianビルドを実行していると思います
私は404ミスファイアと思われるもので一日中問題を抱えていました。
とにかく、私は自分が持っているユーザーアカウントがプロセスのメモリリソースの制限（すべてのプロセス）にアクセスしていることを教えてくれたdreamhostのテクニカルサポート担当者とチャットを終えたところです。私はまったく呼び出されるべきではなかったhtaccessファイルから断続的な404エラーを得ていました！それはお化け屋敷サーバーを持つdreamhostでした。
どうやら、dreamhostが使用するプロセスを殺すロボットが途中でWebプロセスを殺してから、何らかの理由で（今はゾンビ）Apacheは実際に仕事を終えようとします私の最善の推測です）。これはメインのhttpログに500エラーを投げますが、そうすると実際には書き換えられないはずの書き換え条件とルールを無効にします（上記の標準ファイル-fとdirectory -d htaccessファイルを使用）。新しいログエントリを書きません。新しい（見えない人の）リクエストは、htaccessファイルの最後の行にあるインデックスファイルを起動します。
dreamhostの基本アカウントのリソース制限に注意してください。あなたが彼らの限界を越えて、あなたがmod_rewriteラインでhtacessを持っているならば、あなたはハロウィーンの夜のためにだけ適当である奇妙なことを見るでしょう - 目に見えない男性、404を幽霊！アンデッドプロセス！ゾンビアパッチ！ htaccessが自力で動きます！いいね！
これが数時間の痛みを避けるのに役立つことを願っています。
これをデバッグする唯一の方法は、一度に1つのプラグインを無効にすることです。そのたびに、別のプラグインを無効にする前に問題を再現しようとします。 WPの管理に関係のあるプラグインから始めて、通常のテーマプラグイン、ウィジェットなどに移動してください。
より良いサービスを提供されている「見つかりません」ページを調べて（Operaで閲覧してヘッダを表示する情報パネルを開くか、Firefoxで閲覧して「Net」パネルを有効にしたFirebugを使って）あなたのプラグインは、彼らが直接それを提供しているかどうかを確かめるために。そうでない場合は、Webサーバーのログを調べて、提供できない正確なリソースを確認してください。プラグインが空想的なリダイレクトや書き換えを行っている可能性があるため、404が表示されているのがブラウザに表示されるURLとは限りません。
私は自分自身の経験だけを関連づけることができます、そして今のところ、私は all issueを一気に修正するための「明確な」規則を見つけませんでした。
DreamHostのセットアップの大きな問題は、メモリ消費を最小限に抑えるための永遠の戦いにおいて、できるだけ多くの機能を取り除くこと、つまり帯域幅を減らすこと（ビジターにとって良いことです）またはCPU（良いこと）ということです。しかし、DreamHostはRAMの制御ほど積極的にCPUの消費を制御しません。例えば、これはgzipされたHTML + CSS（これはCPU + RAMを消費する）やいくつかのMinifyプラグイン（RAMも消費する）を取り除くことを意味します。キャッシュがより洗練されているほど（私はW3 Total Cache、または少なくともWP Super Cacheを使用するのが好きです）、RAMも同様に消費されます。
同様に、パフォーマンスを向上させるためにMySQLクエリの数を制限する多くのプラグインは、代わりにRAMを消費します。そのため、貴重なRAMを消費しないようにしながら、サイトが引き続き高いパフォーマンスで返信し続けるというトレードオフを見つけるのは難しい作業です。
これまでのところ、忙しいサイトでの私の最良の結果は、明らかに大量のRAMを消費し、代わりにW3 Total CacheとCloudflare（無料リバースプロキシサービス）の組み合わせに頼るであろうPage Speed OptimizationとExtra Web Securityのチェックを外すことです。 Cloudflareは「Extra Web Security」モジュールと実質的に同じことを行いますが、DreamHostの外部で実行されるので問題ありません。 W3 Total Cacheは大量のメモリを消費しますが、いったんページがローカルに静的に保存されると、Cloudflareはそれらを非常に効率的にキャッシュします - 投稿の編集中に404/500が表示されます。たとえDreamHostが404や500を出したとしても。
また、 この記事 のおかげで、FastCGIは '通常の' CGIよりもRAMを多く使用していることがわかりました。そしてPHP 5.3はRAM（より積極的なガベージコレクション、少ないメモリリーク）の管理に優れているので、私は実験的にPHP 5.3 CGI（FastCGIではない）に切り替えました）ページスピードの最適化も追加のWebセキュリティもなく、サイトを高速化するためにW3 Total Cache + Cloudflareに依存しています。今やバックオフィスは遅くなりました（より多くのCPUを消費します！）が、少なくとも404/500は表示されません（今のところ！）。
私はまだその組み合わせに不満を抱いているので、RAMの消費をさらに減らし、それでも十分なパフォーマンスを得られるように、DreamHostの設定を微調整し続けます。 @dgwが言ったように、私もたくさんのプラグインを使っています - それらの機能が必要なので。 DreamHostでWPをホストしているすべての人が単純なブログのニーズを持っているわけではありません。サイトが複雑になればなるほど、より多くの機能が必要になるでしょう…そしてそれがWordPressの美しさです、あなたが本当に必要とするプラグインを使用する必要があり、そしてあなたがコアWPインストールをシンプルに保つ必要がありますいくつかのニーズに満足しています。ただし、プラグインは必ずしも「悪い」とか、サイトのそれほど重いものではありません。しかし、RAMを大量に消費するものもあります。
これは大まかな考えです。（ヘッダが設定された状態で）「本当の」404エラーが発生した場合は、プラグインを検索して PHP header()関数 と404番これにより、プラグインの数を70個からわずか数個に減らすことができます。それからあなたはそれらをチェックする必要があるだけです。
これは特定のIDE関数呼び出しの検索を提供するEclipse PDTのようなPHPで簡単に行うことができます。
その横には、しかしそれがうまくいくという保証はありませんが、ヘッダー設定にフックするプラグインを書くこと、そしてあなたがどのコードが実際に潜在的な404を設定しているかをトレースすることです。これは、プラグインがWordPress API関数を使用している場合にのみ機能します。 PHP関数を探す最初の方法は、WP APIに関係なく機能します。
より多くの情報が必要です：
1）どうしてこんなにたくさんのプラグインがあるの？
2）ホスティングプロバイダはどのOSを実行していますか？
3）どんなWebサーバー？
4）httpdサーバーのログ、特にエラーログにアクセスできますか？
5）これらの問題を取り巻く時間枠でエラーログは何を表していますか？
（今、私たちが「WordPressを実行している平均的なJ6Pがこの正確な質問を持っているかもしれないと一般化しているなら、少なくとも上記5つの質問に答えるようにJ6Pに指示することから始めることができます...）