Atualizações WordPress na manutenção do site

Faço as atualizações do WordPress dentro da manutenção do site, com um calendário fixo: primeiro uma cópia de segurança completa, depois a atualização numa cópia de testes do site (staging), testes, comparação de capturas de ecrã de antes e de depois, e só então a publicação na produção, numa janela combinada. Não instalo automaticamente cada versão nova. As correções de segurança críticas passam à frente da fila, mas também por staging.

Esta página descreve com que frequência atualizo cada coisa, como corre uma ronda de atualizações, o que faço quando algo deixa de funcionar depois de atualizar e como são as atualizações numa loja com faturação certificada e meios de pagamento portugueses, num site com page builder e em sistemas fora do WordPress. O serviço completo de manutenção, com cópias e monitorização, está na página manutenção de sites WordPress.

#Atualização do WordPress fora do calendário: correções de segurança

Uma correção de segurança crítica sai fora do ciclo semanal e segue o mesmo caminho das outras: cópia, staging, teste, publicação. A janela para estas correções fica escrita no orçamento, porque depende do tempo de resposta incluído no seu plano.

As vulnerabilidades chegam-me pelas bases de dados públicas, entre elas a Patchstack e a WPScan. Quando aparece uma falha num plugin que o seu site usa, verifico se já existe versão corrigida e se a falha afeta a sua configuração.

A equipa de segurança do WordPress reúne mais de 50 especialistas de confiança, entre programadores principais e investigadores de segurança. Segundo a mesma página, só a versão mais recente do WordPress tem suporte oficial e as correções para versões antigas são levadas por cortesia. Um site parado várias versões atrás pode ficar sem correção.

Um exemplo deste ano: o WP Rocket 3.23.2.2 passou pelo clone antes de eu atualizar o site para o WordPress 7.1. A descrição do erro e da solução está no artigo WP Rocket, erro fatal no WordPress 7.1 e Cloudflare.php.

#Comparação de capturas de ecrã depois da atualização

Um teste funcional confirma que o formulário envia e que o carrinho aceita o produto. Não repara que, depois de atualizar o tema, o cabeçalho tapa o menu no telemóvel ou que o page builder mudou os espaços na secção de preços. Por isso, depois de cada atualização, comparo capturas de ecrã de páginas escolhidas, de antes e de depois. A lista de páginas a comparar é combinada no início da manutenção: página inicial, páginas de serviços principais, formulário e, numa loja, página de produto, carrinho e finalização da encomenda.

Quando a comparação mostra uma diferença, verifico se resulta de uma alteração planeada. Se não resulta, a atualização fica em staging e eu procuro a causa. Para a produção só segue a versão que tem o mesmo aspeto ou que difere de uma forma que o cliente conhece.

#Atualizar a versão de PHP na manutenção

A passagem para uma versão mais recente de PHP faz parte da manutenção, sem orçamento à parte. Planeio-a com antecedência porque depende de três coisas: se o alojamento oferece a versão nova, se todos os plugins e o tema a suportam e se o código próprio do site usa funções que desapareceram no PHP mais recente. Primeiro ponho um clone do site a correr na versão nova, depois passo os testes e a comparação de capturas de ecrã e só então mudo a versão na produção, numa janela combinada.

O WordPress recomenda PHP 8.3 ou mais recente, MariaDB 10.11 ou MySQL 8.0 e suporte para HTTPS. Segundo o serviço de verificação de versões do WordPress.org, a versão mínima de PHP para o WordPress atual é a 7.4. Junto a passagem de PHP com a revisão da lista de plugins, porque um plugin sem atualizações há muito tempo é o primeiro candidato a falhar na versão nova.

#Atualizações numa loja com faturação certificada, Multibanco e MB WAY

Numa loja WooCommerce a atualização não mexe só na loja. O plugin do prestador de pagamentos, o plugin da transportadora, o conector do ERP e o conector do programa de faturação têm os seus próprios autores e o seu ritmo de versões, e cada um fala com um sistema fora do seu servidor. Depois de atualizar um destes conectores, verifico em staging se os dados continuam a circular nos dois sentidos: a encomenda chega ao ERP, o stock volta à loja, a fatura é emitida.

A faturação é o melhor exemplo em Portugal. O WooCommerce não emite faturas, e quem fatura por programa informático tem de usar um programa certificado pela AT, com ATCUD e código QR, que comunica os elementos das faturas até ao dia 5 do mês seguinte, como explico no artigo sobre faturação no WooCommerce em Portugal. Depois de atualizar o conector, emito uma fatura de teste no ambiente de testes do programa certificado. O clone em staging tem de apontar para esse ambiente, ou para o modo de treino do programa, para que a loja de testes não emita faturas reais. A arquitetura das ligações entre a loja e outros sistemas está nos guias integração WooCommerce com ERP e WordPress API-first.

Os meios de pagamento testo-os com o percurso carrinho, dados, entrega e pagamento, sem uma encomenda real. A loja em que este teste tem de correr também entre atualizações acompanho-a no Store Reliability Plan. Nesse plano o ritmo de atualizações depende do nível: atualizações mensais por staging, atualizações quinzenais ou uma janela de atualizações semanal.

#Cenário típico: loja com Multibanco, MB WAY e programa de faturação

Uma loja típica das que me contactam tem o plugin de um prestador de pagamentos com referências Multibanco e MB WAY, um plugin de transportadora, um conector para o programa de faturação certificado e mais uma dúzia de plugins. Na mesma semana podem sair atualizações do WooCommerce e do plugin de pagamentos. Nessa semana atualizo-os em separado: primeiro o WooCommerce, teste ao carrinho e à fatura, depois o plugin de pagamentos, novo teste. Se algo correr mal, sabe-se logo que alteração o causou.

#Atualizações num site com page builder

Os sites feitos em Elementor, Divi ou WPBakery têm uma camada extra para atualizar: o próprio builder, os seus extras e muitas vezes um tema separado. O builder guarda a estrutura da página no seu próprio formato, por isso uma atualização pode mudar o aspeto de muitas páginas de uma vez. As diferenças entre builders estão no artigo Gutenberg, Elementor, Divi e WPBakery.

Um site de empresa típico, com 30 plugins e um page builder, recebe várias atualizações na maioria das semanas. Num site assim, a comparação de capturas de ecrã faz a maior parte do trabalho, porque o teste funcional passa mesmo quando uma secção da página inicial se desalinha.

#Atualizações automáticas do WordPress ou atualizações geridas

O WordPress sabe atualizar-se sozinho. Segundo a documentação para administradores, as instalações existentes recebem por defeito as atualizações menores do núcleo e as instalações novas desde a versão 5.6 recebem as menores e as principais. O comportamento muda com a constante WP_AUTO_UPDATE_CORE no ficheiro wp-config.php: o valor 'minor' deixa só as atualizações menores e o valor true ativa todas.

Os plugins e os temas funcionam de outra forma. Desde o WordPress 5.5, o administrador ativa as atualizações automáticas plugin a plugin e tema a tema. Segundo a mesma página, o WordPress corre-as duas vezes por dia e depende para isso das tarefas do WP-Cron.

A atualização automática instala a versão nova sem cópia e sem teste em staging. Para correções menores do núcleo é um risco aceitável. Para uma loja, para o plugin de pagamentos ou para o conector de faturação é demasiado. Por isso, na manutenção, deixo o automático onde a alteração é pequena e conduzo à mão, por staging, as peças críticas.

#Site sem atualizações há um ano: como o ponho em ordem

Um cenário típico no início da manutenção: um site de empresa que ninguém atualiza há um ano, com dezenas de plugins, uma versão antiga de PHP e uma única cópia de segurança com vários meses. Num site assim não atualizo tudo de uma vez, porque, se algo falhar, não se consegue saber que alteração o causou.

Começo pela auditoria inicial, incluída no primeiro mês: lista de plugins com versões, verificação de quais o autor ainda desenvolve, versão de PHP e se a cópia existente se deixa restaurar. Depois faço uma cópia completa nova e um clone de staging. No clone atualizo por lotes: primeiro o núcleo, depois os plugins, dos mais simples aos que sustentam o formulário ou a loja, e por fim o tema. Depois de cada lote, testes e comparação de capturas de ecrã. Os plugins abandonados recebem um substituto ou saem. A passagem para PHP mais recente fica como passo separado, quando todos os plugins já estão atualizados.

Só quando o clone passa todos os testes levo as alterações para a produção, numa janela combinada. A partir daí o site entra no ritmo semanal normal. Se pelo caminho aparecer um elemento que precisa de código novo, descrevo-o e orçamento-o à parte.

#Atualizações numa rede Multisite

Numa rede WordPress Multisite, os plugins e os temas são instalados uma vez para a rede inteira, por isso a atualização chega a todos os sites ao mesmo tempo. Cada site pode, no entanto, usar o plugin de forma diferente: um tem nele o formulário de encomenda, outro só uma faixa promocional. Por isso, no staging da rede, testo os percursos principais em cada site que usa o plugin, e a comparação de capturas de ecrã cobre páginas de vários sites. Uma rede Multisite é orçamentada caso a caso, conforme o número de sites e os requisitos.

#Versão principal do WordPress: como a introduzo

Uma versão principal do núcleo, como o WordPress 7.1, muda mais do que uma versão de correção e revela mais vezes incompatibilidades nos plugins. Segundo o serviço de verificação de versões do WordPress.org, a versão atual é a 7.1.3 (dados de 28 de outubro de 2026). Nunca instalo uma versão principal no dia em que sai. Primeiro verifico em staging se os plugins e o tema funcionam com ela, comparo capturas de ecrã e leio as listas de alterações dos plugins que ainda não declararam compatibilidade. A versão principal chega à produção numa janela combinada, quando o clone passa os testes.

Foi num clone destes que apareceu o erro do WP Rocket 3.23.2.2 com o WordPress 7.1, descrito acima. Quando um plugin bloqueia a versão principal, deixo o site no ramo anterior até o autor publicar uma correção ou eu encontrar uma solução alternativa, e registo-o no relatório.

#O que das atualizações entra no relatório

Cada ronda de atualizações deixa rasto no relatório mensal: o que foi atualizado, que regressões apareceram em staging, que versões retive e porquê, e se alguma alteração foi revertida na produção. Assim, depois de uma avaria, sabe-se o que mudou no site e quando, e, se mudar de prestador de manutenção, tem um histórico que pode entregar a quem vier a seguir.

#Alterações ao código próprio durante as atualizações

Às vezes uma atualização pede uma pequena correção no código próprio do site: no tema filho, num plugin feito para a empresa ou numa função que deixou de funcionar no PHP mais recente. Guardo cada alteração destas num sistema de controlo de versões, por isso fica claro o que mudou, quando e porquê, e é possível desfazê-la. Verifico o código face às WordPress Coding Standards com o PHP_CodeSniffer e as regras WPCS, e a análise estática com PHPStan apanha erros de tipos e chamadas a funções que o PHP mais recente já não tem. Antes de publicar, revejo a minha alteração mais uma vez, separadamente da escrita. Uma reconstrução maior continua fora da manutenção e recebe orçamento próprio.

#Atualizações em Drupal, TYPO3, Laravel e Symfony

O mesmo esquema (cópia, staging, testes, janela, plano de reversão) aplica-se aos sistemas fora do WordPress. Mudam as ferramentas e o ritmo de versões.

O Drupal atualizo-o num processo repetível assente em Composer e em publicações por Drush. O Drupal 7 está sem suporte de segurança desde 5 de janeiro de 2025 e o Drupal 10 perde-o a 9 de dezembro de 2026. O que isto significa para um site em Drupal 10 está no artigo fim de suporte do Drupal 10.

No TYPO3 o que mais pesa são as passagens entre versões LTS. O suporte gratuito do TYPO3 12.4 terminou a 30 de abril de 2026, por isso um site nessa versão precisa de um plano de passagem para a 13 ou a 14 LTS.

Numa aplicação Laravel saem versões de correção até todas as semanas e cada versão principal tem dois anos de correções de segurança. As correções chegam à produção em poucos dias, com a atualização das dependências do Composer e uma passagem de composer audit, sempre primeiro num servidor de testes. No Symfony a versão 6.4 recebe correções de erros até novembro de 2026 e correções de segurança até novembro de 2027, por isso muitos projetos começam por um plano de passagem para a 7.4.

#O que as atualizações na manutenção não incluem

Na manutenção atualizo o núcleo, os plugins, os temas e a versão de PHP. Fica fora refazer um elemento que, depois da atualização, precisa de código novo, as grandes alterações ao tema ou à arquitetura do site, a construção de integrações novas e a passagem para outro sistema, por exemplo a migração para Next.js ou Astro. Esse trabalho recebe orçamento próprio e começa depois de confirmado. Quanto custa a manutenção em si está na página preço da manutenção WordPress.

Se o site já não funciona depois de uma atualização falhada e não tem contrato de manutenção, comece pela reparação WordPress. Se depois de uma atualização apareceram ficheiros estranhos, redirecionamentos ou um aviso do Google, siga para a página remover malware do WordPress.

Próximo passo: envie o endereço do site e a lista dos plugins que considera críticos, incluindo os de pagamentos e de faturação. Respondo com o calendário de atualizações que montaria para eles e com o preço da manutenção.