Como eliminar erros 404 estranhos no wp-admin?

Eu corro um site WordPress com cerca de 70 plugins ativos.

De vez em quando, recebo uma página de erro aleatório ("Não encontrado", embora não tenha verificado os cabeçalhos para ver se é um 404) em uma /wp-admin/página que aparece do nada.

Simplesmente tentar novamente resolve o erro, no entanto, é bastante inconveniente se o erro ocorrer durante uma atualização do plug-in (porque a reativação automática falha). Eu acho que esse mesmo problema é responsável por alguns módulos no meu painel falharem ao carregar às vezes.

Dada a lista de plug-ins que instalei , alguém conhece problemas com ou entre algum deles que possam causar esse problema?

Editar:

Informações sobre hospedagem: DreamHost; Eu acho que o servidor está executando uma compilação Debian personalizada com o Apache httpd

eu estava tendo problemas o dia todo com o que parecia ser 404 erros de digitação.

enfim, acabei de conversar com uma pessoa de suporte técnico da dreamhost que me disse que uma conta de usuário que eu tenho com eles estava atingindo os limites de recursos de memória de processo (todos os processos) e era isso que estava causando problemas estranhos, aparentemente relacionados ao htaccess. Eu estava recebendo erros 404 intermitentes de um arquivo htaccess que não deveria ter sido chamado! era um host dos sonhos com um servidor doméstico assombrado.

aparentemente, o processo de matar o robô que o dreamhost usa matará um processo da Web no meio e, por algum motivo, o (agora zumbi) apache realmente tenta terminar seu trabalho (fazendo o possível para sair de maneira limpa do fim sem glamour de uma sub-solicitação) é o meu melhor palpite). ele lança um erro 500 no log http principal, mas depois disso, na verdade dispara a condição de reescrita e a regra que nunca deveria ter sido disparada (usando o arquivo padrão -f e o diretório -d htaccess acima) - e não escreva uma nova entrada de log! uma nova solicitação (homem invisível) aciona o arquivo de índice na última linha do arquivo htaccess

cuidado com os limites de recursos nas contas básicas do dreamhost! se você ultrapassar os limites deles e tiver acesso a linhas mod_rewrite, verá coisas estranhas que só servem para a noite de halloween - homens invisíveis, 404 assombrados! processos de mortos-vivos! apache zumbi! htaccess movendo-se por conta própria! caramba!

espero que isso ajude a evitar algumas horas de dor.

A única maneira de depurar isso é desabilitar um plug-in de cada vez, sempre tentando reproduzir o problema antes de desabilitar outro plug-in. Comece com os plug-ins que têm algo a ver com a administração do WP e, em seguida, passe para plugins de tema regulares, widgets e outros.

Inspecione a página "Não encontrado" com melhor atendimento (navegue com o Opera e abra o painel Informações, que exibirá os cabeçalhos, alternativamente navegue com Firefox e tenha o Firebug com o painel "Net" ativado) e faça uma pesquisa em todos os seus plugins para ver se eles podem ser veiculados diretamente. Caso contrário, consulte o log do servidor da web para descobrir qual recurso exato ele não pode servir; um plug-in pode estar fazendo algum redirecionamento ou reescrita sofisticada, portanto, não é necessariamente o URL que você vê no navegador que está causando o 404.

Só posso relacionar minha própria experiência e, até agora, não encontrei uma regra "definitiva" para corrigir todos os problemas de uma só vez.

O principal problema com a configuração do DreamHost é que, na eterna luta para manter o consumo de memória no mínimo, isso significa livrar-se do maior número possível de recursos - ou seja, tudo o que reduzirá a largura de banda (boa para os visitantes!) Ou a CPU (boa para o servidor, mas o DreamHost não controla o consumo da CPU de forma tão agressiva quanto a RAM). Por exemplo, isso significa livrar-se do HTML + CSS com gzip (que consumirá CPU + RAM) ou de qualquer um dos vários plug-ins do Minify (que também consumirão RAM). Quanto mais sofisticado o cache (eu gosto de usar o W3 Total Cache, ou pelo menos o WP Super Cache), mais RAM será consumida também.

Da mesma forma, muitos plugins que limitam o número de consultas MySQL para melhorar o desempenho consumirão RAM. Portanto, encontrar uma troca em que você ainda possa manter o site respondendo com bom desempenho e evitar consumir RAM preciosa é uma tarefa difícil!

Até o momento, meus melhores resultados em sites ocupados são desmarcar a Otimização da velocidade da página e a segurança extra na Web, que aparentemente consomem muita RAM e, em vez disso, dependem de uma combinação com o W3 Total Cache e o Cloudflare (serviço de proxy reverso gratuito). O Cloudflare efetivamente fará a mesma coisa que o módulo "Extra Web Security", mas como é executado fora do DreamHost, tudo bem. O W3 Total Cache consome muita memória, mas quando as páginas são armazenadas estaticamente localmente, o Cloudflare armazenará em cache de maneira muito eficiente - para que você possa obter 404/500 enquanto edita postagens, pelo menos os visitantes não as experimentam (o Cloudflare também pode servir páginas estáticas mesmo que o DreamHost dê 404 ou 500).

Além disso, graças a este artigo , descobri que o FastCGI usa mais RAM que o CGI 'normal'. E como o PHP 5.3 é melhor no gerenciamento de RAM (coleta de lixo mais agressiva, menos vazamento de memória), eu mudei experimentalmente para o PHP 5.3 CGI (não FastCGI) sem Otimização de Velocidade de Página nem Segurança Extra na Web, contando com o W3 Total Cache + Cloudflare para acelerar o site. Agora, o backoffice está mais lento (mais consumo de CPU!), Mas pelo menos não vejo 404/500 (até agora!).

Ainda estou insatisfeito com a combinação, então certamente continuarei a ajustar as configurações do DreamHost na esperança de reduzir ainda mais o consumo de RAM e ainda obter desempenho adequado. Como o @dgw disse, eu também uso muitos plugins - porque eu preciso da funcionalidade deles. Nem todo mundo que hospeda o WP com o DreamHost tem necessidades simples de blog; quanto mais complexo o site, mais funcionalidade será necessária ... e essa é a beleza do WordPress, você só precisa usar os plug-ins que realmente precisa e manter a instalação do WP principal simples se estiver satisfeito com poucas necessidades. Os plugins, no entanto, não são necessariamente "ruins" ou pesados ​​no site; mas é verdade que alguns podem consumir muita memória RAM ...

Esta é apenas uma idéia aproximada: se você receber um erro 404 "real" (com os cabeçalhos definidos), poderá procurar nos plugins e procurar a função PHPheader() e o número 404. Isso poderia detalhar o número de plugins de 70 para apenas alguns. Então você só precisa verificar isso.

Isso pode ser feito facilmente com um IDE como o Eclipse PDT, que oferece busca por uma chamada de função PHP específica.

Além disso, mas sem garantia de que ele funcione com êxito, é necessário escrever um plug-in que se encaixe na configuração do cabeçalho e, em seguida, rastrear qual código está realmente configurando um potencial 404 (backtrace). Isso funcionaria apenas se o plug-in estiver usando a função API do WordPress. O primeiro método para procurar a função PHP funcionará independentemente da API do WP.

Mais informações necessárias:

1) Por que tantos plugins?

2) Qual sistema operacional seu provedor de hospedagem está executando?

3) Qual servidor da web?

4) Você tem acesso aos logs do servidor httpd, principalmente aos logs de erro?

5) O que dizem os logs de erros no (s) período (s) em torno desses problemas?

(Agora, verdade seja dita, se estamos generalizando para "o J6P médio executando o WordPress pode ter essa pergunta exata, poderíamos começar direcionando o J6P para responder pelo menos as 5 perguntas acima ...)