Como eliminar erros 404 estranhos no wp-admin?
Eu corro um site WordPress com cerca de 70 plugins ativos.
De vez em quando, eu recebo uma página de erro aleatória ("Not Found", embora eu não tenha verificado os cabeçalhos para ver se é um 404) em uma página /wp-admin/ que aparece do nada.
Simplesmente tentar novamente resolve o erro, no entanto, é bastante inconveniente se o erro ocorrer durante uma atualização do plugin (porque a reativação automática falha). Acho que esse mesmo problema é responsável por alguns módulos do meu Painel não serem carregados às vezes.
Dada a lista de plugins que eu instalei , alguém sabe de problemas com ou entre qualquer um deles que possam causar este problema?
Editar:
Informações de hospedagem: DreamHost; Eu acho que o servidor está executando uma compilação personalizada do Debian com o httpd Apache
eu estava tendo problemas durante todo o dia com o que parecia ser 404 misfirings.
de qualquer forma, eu acabei de conversar com uma pessoa de suporte técnico de dreamhost que me disse que uma conta de usuário que eu tenho com eles estava atingindo limites de recursos de memória de processo (todos os processos) e que estava causando problemas estranhos, aparentemente relacionados a htaccess. Eu estava recebendo erros 404 intermitentes de um arquivo de htaccess que não deveria ter sido chamado em tudo! foi dreamhost com um servidor da casa assombrada.
aparentemente, o processo matando o robô que o dreamhost usa matará um processo da web no meio e, por algum motivo, o Apache (agora zumbi) realmente tenta terminar seu trabalho (fazendo o seu melhor para sair do fim sem glamour para uma subsequest é meu melhor palpite). ele gera 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 é possível escrever uma nova entrada de log! um novo pedido (homem invisível), em seguida, 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, e tiver dificuldade com as linhas do mod_rewrite, verá coisas estranhas que só servem para a noite de halloween - homens invisíveis, 404s assombrados! processos mortos-vivos! zumbi Apache! htaccess movendo-se por conta própria! yikes!
espero que isso ajude a evitar algumas horas de dor.
A única maneira de depurar isso é desabilitar um plugin de cada vez, sempre tentando reproduzir o problema antes de desabilitar outro plugin. Comece com os plugins que têm alguma coisa a ver com a administração do WP, depois vá para os plugins de temas regulares, widgets e outros.
Inspecione a página "Não encontrado" que você está servindo melhor (navegue com o Opera e abra o painel Informações que mostrará os cabeçalhos, navegue alternadamente com o Firefox e tenha o Firebug com o painel "Net" ativado) e faça uma pesquisa em todos seus plugins para ver se eles podem ser veiculados diretamente. Caso contrário, dê uma olhada no log do servidor da Web para descobrir qual recurso exato ele não pode atender; um plugin pode estar fazendo algum tipo de redirecionamento ou reescrita, então não é necessariamente o URL que você vê no seu navegador que está causando o erro 404.
Eu só posso relacionar minha própria experiência, e até agora, não encontrei uma regra "definitiva" para corrigir all issues de uma só vez.
O principal problema com a configuração do DreamHost é que, na luta eterna para manter o consumo de memória no mínimo, isso significa livrar-se de tantos recursos quanto possível - tudo o que reduzirá a largura de banda (bom para os visitantes!) Ou CPU para o servidor, mas o DreamHost não controla o consumo de CPU tão agressivamente quanto controla a RAM). Por exemplo, isso significa eliminar HTML + CSS gzip'ed (que consumirá CPU + RAM) ou qualquer um dos vários plugins Minify (que também consomem RAM). Quanto mais sofisticado o cache (eu gosto de usar o W3 Total Cache, ou pelo menos o WP Super Cache), mais RAM será consumido também.
Da mesma forma, muitos plug-ins que limitam o número de consultas do MySQL para melhorar o desempenho consumirão RAM. Assim, encontrar um trade-off onde você ainda pode manter o seu site respondendo com bom desempenho, evitando consumir preciosos RAM é uma tarefa difícil!
Até agora, meus melhores resultados em sites movimentados é desmarcar o Page Speed Optimization e o Extra Web Security, que aparentemente consomem muita memória RAM, e dependem de uma combinação com W3 Total Cache e Cloudflare (serviço de proxy reverso gratuito). O Cloudflare efetivamente fará o mesmo que o módulo "Extra Web Security", mas como ele é executado fora do DreamHost, tudo bem. W3 Total Cache consome muita memória, mas quando as páginas são estaticamente armazenadas localmente, o Cloudflare as armazena de forma muito eficiente - assim você pode receber 404/500 ao editar postagens, pelo menos seus visitantes não as experimentarão (Cloudflare também pode servir páginas estáticas mesmo se o DreamHost der um 404 ou um 500).
Além disso, graças ao este artigo , descobri que o FastCGI usa mais RAM do que o CGI 'normal'. E como PHP 5.3 é melhor em gerenciar RAM (coleta de lixo mais agressiva, menos vazamentos de memória), eu mudei experimentalmente para PHP 5.3 CGI (não FastCGI) sem Page Speed Optimization nem Extra Web Security, contando com o W3 Total Cache + Cloudflare para acelerar o site. Agora o backoffice é mais lento (mais consumo de CPU!) Mas pelo menos eu não vejo 404/500 (até agora!).
Eu ainda estou insatisfeito com a combinação, então eu certamente continuarei a ajustar as configurações do DreamHost na esperança de reduzir ainda mais o consumo de RAM e ainda obter um desempenho adequado. Como o @dgw disse, eu também uso muitos plugins - porque eu preciso da funcionalidade deles. Nem todo mundo que hospeda WP com o DreamHost tem necessidades simples de blogs; quanto mais complexo for o site, mais funcionalidades ele exigirá ... e essa é a beleza do WordPress, você só precisa usar os plugins que realmente precisa, e manter a instalação do núcleo WP simples se estiver satisfeito com poucas necessidades. 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 cabeçalhos definidos), poderá pesquisar seus plug-ins e procurar a função PHP header() 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 específica de função PHP.
Ao lado disso, mas sem garantia de que ele funcione com sucesso, é escrever um plug-in que conecte-se à configuração de cabeçalho e, em seguida, indique qual código está realmente configurando um potencial 404 (backtrace). Isso só funcionaria se o plug-in estivesse usando a função API do WordPress. O primeiro método para procurar a função PHP funcionará independentemente da API WP.
Mais informações necessárias:
1) Por que tantos plugins?
2) Qual sistema operacional o seu provedor de hospedagem está executando?
3) Qual servidor web?
4) Você tem acesso aos logs do servidor httpd, particularmente os logs de erro?
5) O que os logs de erro dizem no período de tempo em torno desses problemas?
(Agora, verdade seja dita, se estamos generalizando para que "o J6P comum executando o WordPress possa ter essa pergunta exata, poderíamos começar direcionando o J6P para responder pelo menos as 5 perguntas acima ...)