Como fazer downgrade ao WordPress (plugin, FTP, WP-CLI)

Este guia cobre três caminhos de downgrade (painel com WP Rollback, WP-CLI e FTP/SFTP) e o caso em que nenhum deles chega: migrações de esquema. A documentação oficial de atualizações está em Updating WordPress. As versões antigas do núcleo estão em Releases.

Antes de qualquer passo: exporta a base de dados e copia wp-content para um sítio seguro. Um rollback sem backup é trocar um incidente por outro.

#Diagnóstico rápido: o que partiu?

Não assumes que foi o núcleo. Em sites portugueses e lojas WooCommerce o padrão mais comum é:

1. Plugin atualizado (formulário, SEO, page builder, gateway Multibanco/MB Way).
2. Tema ou child theme incompatível com a nova API do core.
3. Núcleo WordPress (menos frequente sozinho, mais frequente em combinação com PHP antigo no alojamento).
4. Base de dados já migrada por um upgrade de WooCommerce ou de um membership plugin.

Se o admin ainda abre: Desativar plugins um a um (ou renomear pastas por SFTP) isola o culpado em minutos. Se o admin não abre: renomeia wp-content/plugins para plugins.off, cria pasta plugins vazia, e vê se o site volta. Depois reativas pastas uma a uma.

Ativa temporariamente WP_DEBUG_LOG no wp-config.php (nunca WP_DEBUG_DISPLAY em produção) e lê wp-content/debug.log - o stack trace diz o ficheiro e a linha, não a intuição.

#Método 1: WP Rollback (painel acessível)

Se entras no wp-admin, o caminho mais simples para plugins e temas do repositório é o plugin WP Rollback.

1. Instala e ativa WP Rollback a partir de Plugins → Adicionar novo.
2. Em Plugins (ou Temas), aparece a ligação Rollback junto de cada item suportado.
3. Escolhe a versão anterior conhecida como estável no teu site.
4. Confirma e testa a página crítica (checkout, formulário de contacto, área de membros).

Limitações reais:

• Não substitui um backup da base.
• Versões de plugins premium fora do wordpress.org podem não listar releases.
• Reverter um page builder sem reverter templates gravados na base pode deixar layouts partidos.

Depois do rollback, anota a versão má e bloqueia atualizações automáticas desse plugin até testares em staging.

#Método 2: WP-CLI (SSH)

Com SSH e WP-CLI instalado no alojamento, o rollback é rápido e repetível. Referência: wp core update.

Reverter o núcleo para uma versão concreta:

wp core update --version=6.4.3 --force

Reverter um plugin:

wp plugin update woocommerce --version=8.5.0 --force

Reverter um tema:

wp theme update twentytwentyfour --version=1.0 --force

Boas práticas no servidor:

• Corre os comandos a partir da raiz do WordPress (wp core is-installed deve responder positivamente).
• Faz wp db export backup-antes-rollback.sql imediatamente antes.
• Confirma a versão com wp core version / wp plugin list depois do comando.
• Limpa object cache se existir (wp cache flush) - OPcache e Redis gostam de servir código antigo durante uns minutos.

Se o alojamento partilhado não der SSH, muitos painéis (cPanel Terminal, RunCloud, GridPane, Plesk) expõem WP-CLI na mesma; vale a pena perguntar ao suporte antes de ires para FTP às cegas.

#Método 3: Substituição manual (FTP/SFTP)

Quando o painel está morto e não há WP-CLI, sobes ficheiros do núcleo a partir do pacote oficial.

1. Descarrega a versão desejada em wordpress.org/download/releases.
2. Descompacta no computador.
3. Apaga do pacote a pasta wp-content e o ficheiro wp-config-sample.php. Nunca envies um wp-content limpo por cima do site real - perdes uploads, plugins e temas.
4. Liga por SFTP e envia wp-admin, wp-includes e os ficheiros da raiz (wp-login.php, wp-settings.php, etc.) com overwrite.
5. Não sobrescrevas wp-config.php nem .htaccess personalizado.

Para um único plugin: descarrega o ZIP da versão antiga (página do plugin → Advanced → Previous versions), apaga a pasta do plugin em wp-content/plugins/slug e envia a pasta da versão antiga. Ou renomeia a pasta atual para slug.broken e sobe a antiga ao lado.

#Quando só o backup da base de dados resolve

Algumas atualizações correm migradores SQL. Exemplos típicos:

• WooCommerce major (novas tabelas HPOS / encomendas)
• Plugins de membership ou LMS que alteram meta e custom tables
• Certos builders que reescrevem post meta em massa

Aí o código antigo não sabe ler o esquema novo. Sintomas: erros SQL no log, produtos em falta, checkout a falhar, ecrã branco só em URLs de loja.

Procedimento:

1. Põe o site em manutenção ou desliga o tráfego pago.
2. Restaura o dump SQL de antes da atualização (phpMyAdmin, wp db import, painel do alojamento).
3. Restaura os ficheiros (núcleo + plugins) para o mesmo ponto no tempo - idealmente o mesmo backup.
4. Só depois investigas em staging porque a atualização partiu e preparas um upgrade limpo.

Se o backup da base for de há três semanas e já houver encomendas novas, precisas de estratégia de merge (encomendas exportadas, restauro parcial) - isso já é trabalho de recuperação, não um rollback de cinco minutos. Em lojas PT com Multibanco, anota também webhooks e referências de pagamento pendentes antes de tocares na base.

#Plugins premium e alojamentos portugueses

Muitos sites em Portugal misturam plugins do wordpress.org com licenças Elegant Themes, WPML, Gravity Forms ou gateways locais. O WP Rollback não lista releases privados. Para esses:

1. Guarda o ZIP da versão em produção num repositório interno ou no disco do projeto (versionado fora do webroot).
2. Antes de atualizar no painel, descarrega o ZIP novo mas mantém o antigo comprimido com o número da versão no nome (gravityforms-2.8.0.zip).
3. Se o upgrade falhar, apaga a pasta nova em wp-content/plugins/ e extrai o ZIP antigo.

No alojamento partilhado PT (cPanel clássico, planos “WordPress gerido” de ISPs nacionais), confirma se tens:

• acesso SFTP com chave (não só palavra-passe no FileZilla do portátil)
• phpMyAdmin ou wp db export para dumps
• versão PHP alinhada com os requisitos do núcleo que vais restaurar

Um downgrade para um núcleo que exige PHP 8.1 num servidor ainda em 7.4 não recupera o site - só muda o fatal error. Lê os requisitos da versão em Releases antes de escolheres o número.

#Staging e como evitar o próximo ecrã branco

O downgrade é plano B. O plano A:

• Cópia staging com os mesmos plugins e a mesma versão de PHP do alojamento de produção (em PT muitos hosts ainda misturam 8.0/8.1/8.2 entre planos).
• Atualizas primeiro no staging, testes checkout e formulários, só depois produção.
• Backups automáticos diários testados (restauro de verdade uma vez por trimestre, não só o ficheiro .sql a ocupar disco).
• Atualizações automáticas só para minor/patch do núcleo, se confias no host; majors e WooCommerce ficam manuais.

Se usas Git e CI, o rollback de código é um revert de commit - mas a base continua a precisar do mesmo cuidado descrito acima.

#Checklist de emergência (ordem sugerida)

1. Backup fresco (ficheiros + DB), mesmo que o site já esteja em baixo.
2. Isolar plugin/tema (renomear pastas).
3. Rollback do culpado (WP Rollback ou WP-CLI ou ZIP antigo).
4. Se falhar: restauro completo do backup pré-atualização.
5. Abrir staging, reproduzir o upgrade, corrigir conflito, planear janela de manutenção.

#Resumo

Downgrade no WordPress é rotina de sobrevivência, não vergonha. Painel com WP Rollback para plugins, WP-CLI quando tens SSH, FTP só no núcleo sem tocar em wp-content, e backup completo quando a base já migrou. O objetivo não é viver eternamente numa versão velha - é recuperar o site e voltar a atualizar com staging e backups que já provaste restaurar.

Se precisas de alguém a montar esse fluxo de staging e restauro antes da próxima atualização partir a loja, contacta-nos - trabalhamos em WordPress e WooCommerce com este tipo de recuperação no dia a dia.