Como eliminar erros 404 estranhos no wp-admin?

Eu estava tendo problemas durante todo o dia com o que parecia ser 404 misfirings.

de qualquer forma, acabei de conversar com uma pessoa de suporte técnico de dreamhost que me disse que uma conta de usuário com eles estava atingindo limites de recursos de memória de processo (todos os processos) e isso 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 melhor para sair do fim sem glamour.) para uma sub-requisição é o meu melhor palpite). ele gera um erro 500 no log http principal, mas depois de fazer isso, ele realmente dispara a condição de reescrita e a regra que nunca deveria ter sido disparada (usando o arquivo padrão -f e 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 seus 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! apache zumbi! htaccess movendo-se por conta própria! yikes!

Espero que isso ajude você a evitar algumas horas de dor.

    

A única maneira de depurar isso é desabilitar um plug-in por vez, sempre tentando reproduzir o problema antes de desabilitar outro plug-in. 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ê acessou melhor (navegue com o Opera e abra o painel Informações que mostrará os cabeçalhos, navegue com o Firefox e habilite o Firebug com o painel "Net" ativado) e faça uma pesquisa através de todos os seus plugins para ver se eles podem estar servindo 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 "definida" para corrigir todas as questões de uma só vez.

O grande 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 (bom para o servidor, mas o DreamHost não controla o consumo de CPU tão agressivamente quanto controlam 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 consumirão RAM). Quanto mais sofisticado o cache (eu prefiro usar o W3 Total Cache, ou pelo menos o WP Super Cache), mais RAM será consumida também.

Da mesma forma, muitos plug-ins que limitam o número de consultas do MySQL para melhorar o desempenho consomem RAM. Portanto, encontrar um trade-off onde você ainda pode manter seu site respondendo com bom desempenho, evitando consumir preciosas 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 contam com 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 a este artigo , descobri que o FastCGI usa mais memória RAM do que o CGI 'normal'. E como o 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 ou Extra Web Security, contando com W3 Total Cache + Cloudflare para acelere o site. Agora o backoffice é mais lento (mais consumo de CPU!) Mas pelo menos eu 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 um desempenho adequado. Como o @dgw disse, eu também uso muitos plugins - porque eu preciso da sua funcionalidade. Nem todo mundo que hospeda WP com 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 básica do 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 o conjunto de cabeçalhos), poderá pesquisar seus plug-ins e procurar o PHP header() function 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 específica do PHP.

Próximo a isso, mas sem garantia de que ele funcione com sucesso, é escrever um plug-in que conecte a configuração de cabeçalho e, em seguida, rastreie 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 do 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 registros do servidor httpd, particularmente os logs de erros?

5) O que os logs de erro dizem no período de tempo [s] 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 ...)