Site WordPress deixou de funcionar após uma atualização: como reverter

O que foi atualizado?

Há quatro elementos que se atualizam num site WordPress, e cada um reverte-se de maneira diferente: o núcleo do WordPress, os plugins, o tema e a versão do PHP do servidor, que o fornecedor de alojamento faz evoluir do seu lado. Para saber qual mudou:

• Os emails do WordPress: depois de uma atualização automática, o WordPress escreve para o endereço de administração do site, com um assunto como «[Nome do site] Alguns plugins foram actualizados automaticamente», e a lista do que mudou.
• O ecrã dos plugins: a coluna «Actualizações automáticas» mostra os que se atualizam sozinhos, e cada linha indica a versão instalada.
• Ferramentas > Diagnóstico do site > Informações: a secção Servidor dá a versão do PHP, e as secções dos plugins e dos temas a versão de cada componente.
• As datas das pastas: uma pasta de plugin reescrita por uma atualização tem a data dessa atualização.

wp plugin list
ls -lt wp-content/plugins | head

O primeiro comando lista os plugins com a versão e o estado; o segundo, as pastas de plugins da modificada mais recentemente à mais antiga. Cruze com a hora a que o site mudou.

Limpar as caches antes de concluir

Depois de uma atualização, os ficheiros CSS e JavaScript mudam de conteúdo, e uma cache pode continuar a servir os antigos. O resultado parece uma avaria: aspeto desconfigurado, menus que já não abrem. Limpe, por esta ordem, a cache do plugin de cache ou de otimização, a cache do fornecedor de alojamento, se a tiver, e depois a do navegador, e recarregue a página. Se o site voltar ao normal, a atualização não estava em causa.

O site fica bloqueado em manutenção

Durante uma atualização, o WordPress cria um ficheiro .maintenance na raiz do site e mostra «De momento indisponível para uma breve manutenção agendada. Volte dentro de uns minutos.». Quando a atualização é interrompida, o ficheiro fica no lugar. O WordPress ignora-o dez minutos depois da hora que ele contém; para não esperar, ou se a mensagem persistir, elimine-o por SFTP ou pelo gestor de ficheiros do fornecedor de alojamento. Como o nome começa por um ponto, ative a apresentação dos ficheiros ocultos para o ver.

Volte depois a Painel > Actualizações: o elemento cuja atualização foi interrompida tem de ser atualizado de novo, ou reinstalado na versão anterior.

Repor a versão anterior de um plugin

Reinstalar a versão anterior substitui os ficheiros do plugin e mantém as definições dele, que vivem na base de dados.

wp plugin install nome-do-plugin --version=2.4.1 --force

• Plugin do diretório do WordPress.org: na página pública do plugin, a ligação «Visualização avançada» leva à lista «Versões anteriores». Transfira o arquivo pretendido e, no ecrã «Adicionar plugins», clique em «Carregar plugin»: o WordPress reconhece o plugin já instalado e propõe «Substituir actual pelo carregado».
• Plugin comprado a um editor: as versões anteriores transferem-se em geral a partir da sua área de cliente junto dele.
• A seguir: clique em «Desactivar actualizações automáticas» ao lado desse plugin, até o editor publicar uma correção.

O WordPress já sabe voltar atrás em dois casos. Desde a versão 6.3, quando a atualização de um plugin ou de um tema falha a meio, a versão antiga é reposta. Desde a versão 6.6, quando a atualização automática de um plugin ativo provoca um erro fatal, o WordPress reinstala a versão anterior. Uma atualização que chega ao fim e estraga uma função sem erro fatal tem de ser revertida à mão.

O tema: a versão anterior, e as alterações perdidas

wp theme install nome-do-tema --version=3.1.0 --force

Uma atualização de tema substitui todos os ficheiros dele. As alterações feitas diretamente nos ficheiros do tema, por exemplo no functions.php ou numa folha de estilos, desaparecem por isso a cada atualização. A cópia de segurança feita antes da atualização permite recuperá-las; para as manter de forma duradoura, colocam-se num tema-filho, que as atualizações do tema-pai deixam intacto.

O núcleo do WordPress

O WP-CLI reinstala uma versão precisa do núcleo:

wp core update --version=7.0 --force

Uma atualização principal do núcleo pode também fazer evoluir a estrutura da base de dados, que este comando deixa tal como está. O mais seguro é muitas vezes manter o núcleo atualizado e reverter o plugin ou o tema incompatível. Se o regresso do núcleo for indispensável, faz-se a partir de uma cópia de segurança completa feita antes da atualização.

A versão do PHP, alterada pelo fornecedor de alojamento

Os fornecedores de alojamento fazem evoluir a versão do PHP à medida que as antigas deixam de receber correções de segurança. Um plugin ou um tema antigo pode então parar com um erro fatal. O painel do fornecedor de alojamento permite em geral escolher a versão do PHP do site:

1. Anote a versão instalada e volte à anterior.
2. Verifique que o site volta a funcionar.
3. Atualize ou substitua o componente em causa, identificado pelo registo de depuração.
4. Volte à versão recente.

Este regresso é uma etapa de resolução de problemas: uma versão do PHP sem correções de segurança expõe o site. Segundo o calendário oficial publicado em php.net, o PHP 8.1 deixou de receber correções de segurança a 31 de dezembro de 2025, o PHP 8.2 recebe-as até 31 de dezembro de 2026 e o PHP 8.3 até 31 de dezembro de 2027. O WordPress recomenda o PHP 8.3 ou mais recente.

Restaurar uma cópia de segurança completa, em último recurso

Uma restauração repõe os ficheiros e a base de dados no estado da cópia de segurança. Tudo o que o site recebeu desde então desaparece: encomendas, mensagens de formulário, comentários, inscrições, artigos publicados.

1. Exporte primeiro o que chegou desde a cópia de segurança: encomendas, entradas de formulários, novas contas.
2. Restaure ficheiros e base de dados do mesmo momento, a partir da ferramenta do fornecedor de alojamento ou do seu plugin de cópias de segurança. Ficheiros de um dia e uma base de dados de outro produzem erros difíceis de ler.
3. Volte a importar os dados exportados.
4. Volte a aplicar as atualizações uma a uma, verificando o site entre cada uma: a última aplicada antes da avaria é a que a provoca.

Para a próxima atualização

• Uma cópia de teste: muitos fornecedores de alojamento propõem um ambiente de testes (staging) que copia o site num clique. As atualizações aplicam-se primeiro lá.
• Uma cópia de segurança imediatamente antes, ficheiros e base de dados em conjunto.
• Uma atualização de cada vez, verificando as páginas principais entre cada uma: página inicial, formulário de contacto, carrinho.
• O registo de alterações do plugin ou do tema, lido antes de uma atualização principal.