Ajuda WordPress: o que fazer antes de reportar uma avaria

#Antes de escrever: dez minutos de triagem

Quatro perguntas, por esta ordem. As respostas apontam normalmente a causa mais depressa do que qualquer ferramenta.

O que exatamente não funciona. O site inteiro, uma página, ou só o painel de administração? Abra o endereço numa janela privada e noutra ligação, por exemplo no telemóvel com dados móveis. Se em janela privada o site funciona, o problema está na cache do navegador ou na sua sessão, e não no servidor. Se funciona no telemóvel mas não no escritório, verifique o DNS e a firewall do seu lado antes de alguém começar a mexer no WordPress.

Qual é a mensagem exata. “Não funciona” são cinco avarias diferentes. O ecrã branco é normalmente um erro de PHP com a apresentação de erros desligada. O erro 500 é um erro do servidor, na maioria das vezes um plugin, o tema ou o limite de memória. “Error establishing a database connection” é a base de dados, ou seja, um caminho completamente diferente. Um erro 403 ao iniciar sessão costuma ser uma regra de segurança, não uma avaria. Anote o código e o texto completo, incluindo o número da linha, se existir.

O que mudou mesmo antes. As avarias raramente aparecem sozinhas. Atualização de um plugin, atualização do core, mudança da versão de PHP pelo alojamento, expiração de um certificado, alteração de um registo DNS, fim da validade do domínio, limite do alojamento ultrapassado. A data e a hora da última alteração são, quase sempre, a informação mais valiosa de todo o pedido.

Se tem cópia de segurança. Não a reponha por reflexo, mas confirme que existe e de quando é. Se o alojamento faz cópias noturnas, veja no painel quando foi a última. É esta informação que decide se a reparação é arriscada ou reversível.

#Mensagem de erro, camada, primeira ação

Esta tabela encurta a etapa mais longa de qualquer avaria, que é adivinhar onde procurar.

A coluna do meio é mais importante do que a da direita. A maior parte do tempo perdido nas avarias vem de reparar a camada errada: alguém desativa plugins quando o problema está no DNS, ou muda de alojamento quando a culpa é de um único plugin que consulta uma API externa.

#Onde estão os logs e o que procurar neles

Sem log, o diagnóstico é adivinhação. Há três sítios, por esta ordem de utilidade.

Log de erros do PHP. Na maioria dos alojamentos partilhados fica como error_log na pasta do site, ou no painel, na secção dos logs. Procura as últimas entradas PHP Fatal error da hora da avaria. Uma entrada dessas contém o ficheiro e o número da linha, e isso costuma apontar o plugin culpado logo no primeiro segundo.

Log do WordPress. Se o alojamento não dá o log de PHP, ative o seu. No wp-config.php, acima da linha com o comentário “That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Os erros vão parar a wp-content/debug.log e os visitantes não veem nada. Depois do diagnóstico, desligue isto e apague o ficheiro; um log deixado em produção durante um mês chega a crescer até gigabytes e torna-se ele próprio uma avaria.

Log do servidor web. O Nginx e o Apache registam acessos e erros em separado. O que lhe interessa é o segundo, da hora do incidente. Num alojamento com acesso à shell basta tail -n 100 /caminho/para/logs/error.log. Se só tem painel, descarregue o ficheiro e abra-o num editor de texto, não numa folha de cálculo, porque as linhas longas ficam cortadas.

O que procurar nos três: a marca temporal que coincide com o momento da avaria, a mesma linha a repetir-se (isso costuma ser um ciclo, não coincidência) e o nome da pasta de um plugin no caminho do ficheiro. O que não fazer: não cole no pedido um ficheiro inteiro com dez mil linhas. Vinte linhas à volta da primeira ocorrência do erro valem mais do que o conjunto completo.

#Quatro avarias mais frequentes e primeiros socorros

Os passos seguintes são seguros, reversíveis e não exigem um programador. Se algum ultrapassar o seu conforto, pare e escreva; uma reparação interrompida é mais fácil de terminar do que uma reparação aprofundada.

Ecrã branco ou erro 500 depois de uma atualização. Comece por desativar o plugin atualizado mais recentemente. Se não tem acesso ao painel, mude o nome da pasta dele em wp-content/plugins/ através do gestor de ficheiros do alojamento ou por FTP; o WordPress desativa-o nesse momento. Se não resolver, mude o nome da pasta plugins inteira para plugins-off, veja o site e reponha o nome. Isto resolve num minuto se a culpa é do plugin ou do tema. Com acesso à linha de comandos, wp plugin deactivate --all faz o mesmo de forma mais limpa e permite reativar os plugins um a um.

Site subitamente lento. Verifique se o que está lento é o carregamento do site ou o painel. Painel lento com front rápido é normalmente a base de dados ou uma API externa, por exemplo um plugin que consulta o servidor de licenças a cada visita. Front lento com painel rápido é normalmente a cache, as imagens ou o alojamento. Meça antes de otimizar: o PageSpeed Insights mostra ao mesmo tempo o resultado laboratorial e os dados de utilizadores reais do CrUX, e estes últimos contam mais, porque descrevem o que as pessoas vivem e não uma simulação. À parte, verifique o tempo de resposta do próprio servidor, por exemplo curl -o /dev/null -s -w "%{time_starttransfer}\n" https://oseudominio.pt/. Um resultado acima de um segundo aponta para um problema do lado do servidor, e não nas imagens ou nos scripts.

Não consigo iniciar sessão. Antes de considerar isto uma avaria, verifique três coisas: se o endereço de login não foi alterado por um plugin de segurança, se o seu IP não ficou bloqueado após tentativas falhadas e se o relógio do servidor não está desacertado, porque isso estraga as sessões. A reposição da palavra-passe pelo formulário exige correio a funcionar, portanto se os emails não saem, não resulta. Saída de emergência: wp user update admin --user_pass=NovaPalavraPasse a partir da linha de comandos, ou mudar a palavra-passe diretamente na base de dados com a função MD5, que o WordPress aceita no primeiro início de sessão e substitui logo pelo seu próprio hash.

Suspeita de infeção. Sintomas: redirecionamentos para um domínio estranho apenas a partir dos resultados de pesquisa, novos administradores que não criou, um aviso na Search Console, spam no conteúdo visível apenas para o Googlebot. Verifique a lista de utilizadores com o papel de administrador e as datas de modificação dos ficheiros, por exemplo find . -type f -mtime -7 -name "*.php", para ver o que mudou na última semana. Não apague ficheiros nem reponha cópias enquanto não determinar a data da primeira entrada; uma cópia de há uma semana já contém normalmente a mesma falha. Mude as palavras-passe, incluindo as da base de dados e do FTP, e escreva-nos com a nota de que há infeção.

#Uma avaria numa loja WooCommerce tem outra ordem

Numa loja, o reflexo de “desativar todos os plugins” sai caro, porque junto com o diagnóstico desliga pagamentos, envios e integrações de stock. A ordem é a inversa da de um site de apresentação.

Comece por determinar se entram encomendas. A lista de encomendas da última hora responde a isso mais depressa do que qualquer log. Se entram e os clientes reportam problemas, a avaria está nas notificações ou no pagamento, e não na loja em si. Se não entra nenhuma, verifique a página do carrinho e a de finalização da encomenda numa janela privada, porque ambas estão excluídas da cache e falham de forma diferente do resto do site.

As notificações por email são uma avaria à parte, muito frequente, que se parece com uma avaria da loja. Verifique se o correio sai de todo e se não vai parar ao spam do destinatário. Três registos DNS decidem isto quase por completo: SPF, DKIM e DMARC. Se a loja envia emails diretamente do servidor de alojamento sem esses registos, parte das mensagens não chega e nenhuma alteração no plugin resolve isso.

Se a avaria afeta um único método de pagamento, verifique no painel do operador se não expirou a chave de API ou o certificado da integração. É a situação em que o site funciona bem, os logs estão limpos e as vendas estão paradas, portanto sem verificar do lado do operador é possível passar horas à procura no código próprio.

#Quando isto nem sequer é uma avaria do site

Quatro casos em que o WordPress é inocente e o diagnóstico do lado dele só faz perder tempo.

Domínio expirado. Sintoma: em vez do site vê a oferta do registrar ou o vazio. Verifica-o na base whois, com uma consulta, e vê a data de expiração. A renovação costuma resultar em poucos minutos, embora em casos extremos o domínio entre em período de resgate e custe várias vezes mais do que uma renovação normal.

Alteração de DNS ainda não propagada. Sintoma: umas pessoas veem o site novo, outras o antigo. dig oseudominio.pt +short mostra para que endereço aponta o domínio a partir da sua perspetiva. As alterações propagam-se conforme o valor de TTL, portanto se alguém o definiu em 24 horas, é isso que vai demorar e não há como acelerar do lado do site.

Certificado expirado. Sintoma: aviso do navegador sobre ligação não fidedigna. A data de validade lê-se com o comando openssl s_client -connect oseudominio.pt:443 2>/dev/null | openssl x509 -noout -dates. A renovação automática pode falhar quando entretanto mudou o DNS ou foi acrescentado um redirecionamento que bloqueia a verificação.

O alojamento suspendeu a conta. Sintoma: uma mensagem do alojamento em vez do site, por vezes depois de ultrapassar o limite de tráfego ou de uma fatura por pagar. Aqui não há nada a reparar no código, há apenas uma conversa com o alojamento, mas vale a pena verificar depois o que gerou o tráfego, porque com a mesma frequência é um bot e não clientes.

#O que enviar no pedido

Quanto mais desta lista indicar de imediato, menos rondas de perguntas e mais depressa recebe uma resposta com substância, em vez de um pedido de completar dados.

O que não enviar na primeira mensagem: palavras-passe. O acesso define-se depois do âmbito e de preferência como conta de administrador separada, que apaga no fim dos trabalhos. Se o assunto é urgente, diga-o diretamente e explique o que urgente significa em concreto: uma loja que não aceita encomendas é outra coisa que um formulário de contacto que envia duas vezes.

#O que acontece do nosso lado

O pedido chega a uma pessoa, não a uma fila de primeira linha, por isso não explica o caso duas vezes. A primeira resposta traz o que foi possível apurar a partir da sua descrição e pergunta apenas o que realmente falta.

Depois vem o diagnóstico. É uma etapa separada e fechada, com preço próprio, para saber ao que está a aceder antes de alguém tocar no site. O resultado é a causa, o âmbito da reparação e o custo, por escrito. Os trabalhos arrancam após a confirmação do âmbito, não com um “avancem” dito de viva voz. Se pelo caminho surgir algo fora do âmbito, paramos e orçamentamos à parte, em vez de o acrescentar à conta depois do facto.

A reparação é feita numa cópia ou em ambiente de testes sempre que possível, e as alterações em produção entram numa única implementação com possibilidade de reverter. No fim recebe a descrição do que foi a causa e do que fazer para não voltar. Esta última parte costuma valer mais do que a própria reparação, porque uma avaria que volta daqui a três meses custa uma segunda vez.

#O que não fazemos

Não fazemos design gráfico. O layout e a disposição dos elementos na vista, ou seja, o wireframe, são fornecidos pelo cliente; nós implementamos a partir dele a interface responsiva, as integrações e a camada de desempenho. Para recolher a estrutura temos um modelo de folha pronto, que enviamos no arranque.

Não temos turno noturno nem de fim de semana e não vendemos tempos de resposta que não conseguimos cumprir. Se a sua loja precisa de uma janela de resposta garantida, isso é um contrato de acompanhamento à parte, não uma nota acrescentada a um pedido de avaria.

Não fazemos coisas “já agora”. Cada assunto novo que surja pelo caminho tem o seu próprio orçamento. Soa rígido, mas na prática poupa aos dois lados uma conta que ninguém esperava.

Também não vendemos uma reconstrução como resposta a uma avaria. Se o site se consegue reparar em poucas horas, dizemo-lo, mesmo que uma proposta de migração fosse mais vantajosa para nós. A migração faz sentido quando o custo de manter a solução atual ultrapassa o custo da mudança, e isso calcula-se, não se pressente.

#Quando o site voltou sozinho, o caso não está fechado

Uma avaria que passou sem intervenção é pior do que uma que continua, porque desaparece junto com as provas e volta num momento pior. As três causas mais frequentes de avarias intermitentes parecem idênticas vistas de fora.

A primeira é o limite de recursos. O alojamento partilhado atribui ao site um número definido de processos PHP em simultâneo e, ultrapassado esse número, rejeita os pedidos seguintes, normalmente com um erro 503 ou 508. Basta um bot percorrer a loja com filtros e durante três minutos o site não responde a ninguém. No log de acessos vê então uma série de pedidos do mesmo endereço no mesmo segundo.

A segunda é uma tarefa agendada. O WordPress executa o seu próprio agendador ao sabor das visitas, por isso uma tarefa pesada, por exemplo gerar um relatório ou sincronizar com o stock, calha a um utilizador aleatório e bloqueia-lhe o site. Sintoma: avarias a horas regulares ou sempre a seguir à mesma ação no painel.

A terceira é uma API externa sem limite de tempo. O plugin consulta o servidor do fornecedor, o fornecedor tem uma avaria, e o seu site espera pela resposta o tempo que a configuração do PHP permitir. Nesse caso o site não está estragado, está à espera, e volta sozinho quando aquele servidor se levantar.

O que fazer para apanhar isto da próxima vez: ative o registo de erros em ficheiro antes que volte, anote as horas exatas das ocorrências dos últimos dias e veja se formam um padrão. Três marcas temporais e um log são o conjunto com que se consegue trabalhar. Sem isso resta esperar pela próxima vez.

#Onde seguir a partir daqui

Se já sabe do que precisa, vá diretamente à página certa em vez de escrever um pedido genérico.

• Avaria, erro, algo deixou de funcionar: reparação, serviço e apoio técnico
• Acompanhamento contínuo, atualizações, cópias e monitorização: manutenção de sites WordPress
• Suspeita de invasão ou auditoria antes de uma implementação: auditoria de segurança WordPress
• O site funciona, mas está lento: acelerar um site WordPress
• Novo projeto ou remodelação: página de contacto

#Duas coisas a fazer hoje, antes que algo se parta

Verifique se a sua cópia de segurança se consegue repor. Não se existe, mas se funciona. Um backup que nunca ninguém repôs é um pressuposto, não uma proteção, e o momento da avaria é a pior altura para o descobrir. O procedimento leva meia hora: monte um ambiente de testes no mesmo alojamento, reponha nele a última cópia, inicie sessão no painel, abra três páginas ao acaso e verifique se o número de artigos e de encomendas bate certo com a produção. Anote quanto tempo demorou, porque esse é o seu tempo real de regresso depois de uma avaria e é melhor conhecê-lo por ensaio do que por avaria.

A segunda coisa leva um minuto: aponte onde está o domínio, onde está o alojamento, quem tem acesso a ambos e quando expiram. Surpreendentemente muitas vezes a avaria não é avaria, é um domínio ou um certificado expirado, e responder à pergunta “onde é que isto está” leva meio dia, porque a pessoa que tratou disso já não trabalha na empresa há muito. Na mesma folha acrescente quem é administrador no WordPress e se cada uma dessas contas ainda é necessária. As contas de antigos colaboradores são a porta de entrada mais frequente que ninguém vigia.