Atualizar um site, plugin ou tema do WordPress para uma nova versão do PHP é uma tarefa que ocorre regularmente. Mas como fazer isso de forma mais eficiente? Como garantir que você não vai esquecer de nada? Existe um guia para isso?

Neste artigo, abordaremos estas questões (e muito mais) e ver o que está envolvido em uma transição suave para o PHP 8.x em seu site WordPress, plugin ou tema, incluindo um guia completo para isso.

Faremos isso com base em uma entrevista que realizamos com a especialista em PHP, Juliette Reinders Folmer. Ela dedica a maior parte de sua vida diária à programação e tudo relacionado a ela, focando principalmente em projetos de código aberto, incluindo o WordPress.

Você está pronto para fazer a transição de forma tranquila? Curioso sobre o nosso guia passo a passo? Então vamos começar!

PHP 8.x – O que mudou

Para ter uma visão geral das mudanças, recomendamos os artigos abaixo:

Após ler esses artigos, você estará completamente atualizado sobre o que mudou no PHP 8.x e o que precisa fazer para que seus projetos em PHP funcionem sem problemas.

Se você não tem certeza por onde começar, não há problema. Na conversa com Juliette, discutimos isso em detalhes, e neste artigo, explicaremos de forma mais completa possível como você pode fazer a transição para o PHP 8.x.

Também explicaremos em caixas informativas como realizar várias operações no MyKinsta, nosso painel de controle proprietário para todos os seus sites, aplicativos e bancos de dados WordPress.

Migrando para PHP 8.x: Como Começar

Migrar para o PHP 8.x pode parecer simples e, tecnicamente, é. Muitos provedores de hospedagem permitem que você especifique qual versão do PHP deseja usar para o seu site no painel de controle. Na Kinsta, a troca da versão do PHP pode ser feita com um único clique no painel MyKinsta.

Mas antes disso, há algumas coisas de que você precisa ter certeza. Dependendo do seu nível de conhecimento e experiência, recomendamos o seguinte:

  • Se você construiu seu próprio site WordPress com temas e plugins padrão, sem ter muito conhecimento de PHP, contrate um desenvolvedor ou uma agência para investigar se seu site é adequado para rodar no PHP 8.x. Você está procurando por um terceiro que possa ajudá-lo com isso? Então olhe nossa página de Parceiros, onde listamos várias empresas confiáveis que podem ajudar você.
  • Se o seu site WordPress foi construído por uma parte externa, um desenvolvedor ou uma agência, entre em contato com eles para perguntar se o seu site pode funcionar no PHP 8.x.
  • Se você construiu o seu site WordPress — com o seu próprio tema personalizado, por exemplo, ou plugins desenvolvidos por você — temos um guia para você abaixo.

Se o seu site se encaixa em uma das duas primeiras categorias, nós o convidamos a ler o restante do artigo, mas não recomendamos que você comece a testar a compatibilidade do seu site com o PHP 8 por conta própria. Deixe isso para os profissionais.

Seja qual for a sua escolha, aconselhamos a não simplesmente mudar o seu site de produção para o PHP 8 e “ver se funciona”. Se você está curioso para saber como seu site ficará e não pode esperar para vê-lo funcionando com o PHP 8, comece os testes em um ambiente de teste. Um bom provedor de hospedagem de sites permitirá que você configure facilmente um ambiente de teste.

MyKinsta - Criar um novo ambiente
MyKinsta – Criar um novo ambiente

No ambiente de teste, você pode ativar o PHP 8.x e ver se esta atualização funciona bem com o seu site. Também é possível trabalhar com uma cópia local do seu site. Com nossa ferramenta gratuita de desenvolvimento DevKinsta, você pode facilmente importar seu site do painel MyKinsta e, em seguida, você pode mudar a versão do PHP para 8.0 ou 8.1.

No entanto, se você não encontrar problemas no ambiente de teste, isso não garante que não existam problemas reais. O guia abaixo explicará o motivo.

Teste de compatibilidade com o PHP 8.x: O guia

Teste: a palavra-chave para um bom software. Mesmo para sites WordPress e seus componentes, tais como temas, plugins e o núcleo do WordPress, testar é o meio de garantir que não aconteçam coisas que você não queira que aconteçam.

Um projeto de desenvolvimento de software consiste amplamente em testes. Neste artigo, analisamos especificamente os testes que podem ajudar você a fazer a transição para o PHP 8.x de forma tranquila. Em nosso artigo sobre Ferramentas de DevOps, você encontrará uma seção com uma coleção de ferramentas que você pode usar.

Os seguintes tipos de testes são discutidos neste post do blog:

Vamos analisar mais de perto os diferentes tipos de testes que podemos realizar.

Análise estática (ou teste estático)

O primeiro passo que você pode dar como um desenvolvedor PHP é realizar uma análise estática do seu código com várias ferramentas. A análise estática é o processo de análise de software sem executar o código. Com a análise estática, é possível detectar erros, detectar problemas com a compatibilidade do PHP 8.x, impor padrões de codificação (por exemplo, os Padrões de Codificação do WordPress) e até mesmo modificar e limpar o código é possível.

Ferramentas para análise estática

Você pode realizar uma análise estática com várias ferramentas, como por exemplo:

No momento da escrita, nem todos os testes para o PHP 8.1 são suportados na versão mais recente do PHPCompatibility. Os testes para o PHP 8.1 podem estar presentes na versão de desenvolvimento, portanto, certifique-se de usá-los (por enquanto) ao utilizar o PHPCompatibility para analisar seu projeto e verificar quais erros/recomendações existem.

Os testes para o PHP 8.1 serão em breve lançados em uma nova versão principal. Se você deseja se manter atualizado sobre isso e possui uma conta no GitHub, acesse o repositório GitHub do PHPCompatibility e vá para Watch -> Custom -> Releases, onde você pode escolher ser notificado quando uma nova versão for lançada.

O PHPCompatibility, que testa apenas a compatibilidade para uma versão específica (ou intervalo de versões) do PHP, é fácil de configurar. Você obtém os melhores resultados se executar um teste para uma versão específica (testVersion) – por exemplo, 8.0+ (8.0 em diante) – no PHPCompatibility.

Você deve ficar atento a funções depreciadas ou removidas, valores padrão alterados para parâmetros de função, o uso de concatenação sem parênteses, o uso do termo “match” como nome de função (já que foi reservado desde o PHP 8.0), entre outros.

Tela da página GitHub PHPCompatibility
Tela da página GitHub PHPCompatibility

Psalm e PHPStan são boas adições e podem ajudar você a realizar verificações adicionais relacionadas aos tipos de variáveis. A desvantagem dessas ferramentas é que elas exigem muita configuração para obter relatórios sobre o PHP 8.0 e 8.1. Mesmo que sejam bem-sucedidas, é possível esperar muitos falsos positivos. Falsos positivos são notificações dadas erroneamente, causadas pelas limitações da análise estática.

O conhecimento sólido é necessário para interpretar corretamente os resultados dessas duas ferramentas, mas esse conhecimento pode ajudá-lo a identificar incompatibilidades adicionais que a PHPCompatibility não pode encontrar. Veja a documentação do Psalm e PHPStan se você quiser aprender mais sobre eles.

Resumo:

  • Realize análise estática com PHPCompatibility, Psalm, PHPStan
  • Resolva todos os problemas legítimos
MyKinsta - Visualizando arquivos de registro
MyKinsta – Visualizando arquivos de registro

Teste unitário

O próximo passo no processo é o teste unitário. O teste unitário é um método de testar partes de código individualmente. No teste unitário, testes específicos e direcionados serão desenvolvidos para cada unidade de código. Isso envolverá a execução de diferentes cenários. Preferencialmente, cada cenário é testado separadamente dos outros para os testes serem independentes entre si.

Ter apenas testes unitários, é claro, não é suficiente. Eles também precisam ser executados. Os testes unitários são melhor automatizados usando ferramentas de CI (integração contínua), como Jenkins, GitHub Actions, ou Travis.

Um exemplo das ações do GitHub
Um exemplo das ações do GitHub

Suportando múltiplas versões do PHP

Como um construtor de plugins, se você quiser suportar múltiplas versões do PHP, certifique-se de que os testes no CI sejam executados em todas as versões do PHP que você deseja suportar.

É claro que você também pode optar por suportar apenas as versões mais recentes, a escolha é totalmente sua.

Testar com várias versões do PHP requer o uso de várias versões do PHPUnit, dependendo da versão do PHP. Como o PHPUnit introduziu várias mudanças ao longo dos anos que afetam a maneira como os testes são escritos, essa parte pode ser complicada.

Para contornar isso, você pode usar o PHPUnit Polyfills (escrito por Juliette e patrocinado pela Yoast). Isso permite que você escreva testes que não são oficialmente suportados pelo PHPUnit 9 (e assim podem ser executados no PHP 8.x). Os Polyfills então fazem seus testes funcionarem no PHPUnit 4.x até 9.x e com PHP 5.4 até PHP 8.1 (a partir de agora).[/notice]

Agora que você tem os testes em andamento, o próximo passo é certificar-se de que os problemas encontrados nos testes sejam corrigidos.

Cobertura de código

A execução desses testes é a maneira mais confiável de encontrar incompatibilidades de versão cruzada.

Ao fazer isso, preste atenção na cobertura de código dos seus testes:

  • Suponha que você tenha uma função A e tenha escrito um teste para ela, e a função A chama as funções B, C e D como parte da lógica da função.
  • O teste para a função A é escrito para testar a lógica da função A, mas também chamará as funções B, C e D durante os testes. Para as funções B, C e D, você normalmente só testa o “caminho feliz” – a situação em que tudo corre bem – e, portanto, essas funções também não são totalmente testadas, embora (parte) do código dessas funções seja executado durante o teste da função A.
  • Para cada um de seus testes, indique qual código está sendo testado especificamente. Você faz isso dando a cada teste uma @covers Desta forma, B, C e D não são “contados” no cálculo da cobertura do código, o que permite que você veja qual parte do seu código é coberta pelos testes.

Muitas vezes, os desenvolvedores escrevem e testam – às vezes, até sem saber – para o “caminho feliz”. Nesses casos, também é necessário testar o que acontece quando dados inesperados são passados para uma função. Testar apenas com valores/tipos esperados não é suficiente.

A segunda parte da citação acima é frequentemente esquecida, quando talvez seja ainda mais importante do que a primeira parte. O que acontece se você passar um tipo incorreto? Você recebe uma mensagem de erro? Ou o elenco da variável com a função continua como normal? O que acontece se um valor inesperado for passado para a função?

Certifique-se de testar suas funções com variáveis, tipos e valores inesperados. Somente então você pode confiar em seus testes para encontrar problemas que uma nova versão do PHP pode causar.

O PHP está ficando mais rigoroso

O PHP está se tornando mais preciso (rigoroso) em como ele lida com “tipos” para as próprias funções do PHP, assim como coisas como propriedades dinâmicas. Essas mudanças são geralmente destinadas para ajudar os desenvolvedores a entregar código com menos erros. Mas isso pode apresentar um grande obstáculo para a atualização de código pré-existente escrito com base nos “velhos” princípios do PHP.

Devido à busca por mensagens de erro mais úteis no PHP, atualizar o código existente para ser compatível com novas versões leva cada vez mais tempo. Fazer um código que funcionava no PHP 5.6 ser adequado para o PHP 7.0 levava menos tempo do que atualizá-lo para o PHP 8.1, apesar do PHP 7.0 ser uma versão “maior” e o PHP 8.1 ser uma versão “menor”.

Em muitos casos, os testes ainda são a única maneira confiável de determinar o que precisa ser modificado para suportar uma nova versão.

Os testes unitários são possíveis com várias ferramentas, inclusive:

Muitas dessas ferramentas são construídas com base ou em conjunto com o PHPUnit.

No final das contas, não importa quais ferramentas você usa. O mais importante é que você teste, e ponha os testes em execução em novas versões PHP. Este passo às vezes pode ser muito complicado, mas felizmente, como mencionado anteriormente, existem ferramentas para isso, como o PHPUnit Polyfills.

Teste de integração

O teste de integração é o próximo passo que executaremos, após a análise estática e os testes unitários. Um teste de integração é onde situações da vida real são testadas em um contexto maior do que apenas uma “unidade de código” Estes incluem testes com um banco de dados ativo (teste) ou testes com uma API externa, para dar apenas dois exemplos.

Então, quando você testa o código de um plugin ou tema no contexto do WordPress e usa uma versão real, estes são, por definição, testes de integração.

WP Test Utils (novamente escrito por Juliette e patrocinado pela Yoast) é uma excelente ferramenta para testes de integração. WP Test Utils fornece ferramentas para escrever integração e testes unitários, nos quais o WordPress é “ridicularizado” usando Brainmonkey e Mockery, onde as funções comumente usadas no WordPress são “falsas” para que você esteja testando seu próprio código e não o código do WordPress.

WP Test Utilities no GitHub
WP Test Utilities no GitHub

O teste de integração com o WordPress é uma história mais complicada porque envolve a integração com o WordPress e a suíte de testes do WordPress. Dependendo de quais versões do WordPress um plugin ou tema suporta, você tem que considerar quais versões do PHPUnit são suportadas pelo próprio WordPress para executar os testes em diferentes versões do PHP.

Por exemplo, o WordPress 5.6 até 5.8 usa PHPUnit 5 até 7 para testar PHP 5.6 até PHP 8.0, mas a partir do WordPress 5.9, o próprio WordPress também usa PHPUnit Polyfills para um suporte mais amplo. WP Test Utils atua como uma ponte para superar todas essas diferenças.

Quer saber mais sobre como executar testes de integração contra várias versões diferentes do WordPress, incluindo WordPress 5.9 e versões anteriores? Então leia sobre isso no site do WordPress.

Testes manuais

Agora que você passou pelos testes unitários e testes de integração e corrigiu todos os problemas encontrados, é hora de fazer o teste manual. Seu site está funcionando, e seu próprio código está em ordem, mas você também está usando os plugins A, B e C. Você sabe se esses plugins são compatíveis?

Por exemplo, verifique isso com os autores dos plugins e veja se eles indicam que são compatíveis com o PHP 8.x. A questão, é claro, é como o plugin foi testado. Geralmente, a resposta é: de forma isolada. As funções do plugin foram normalmente testadas em conjunto apenas com o WordPress, sem outros plugins ativos. E mesmo que outros plugins tenham sido usados nos testes, é provável que nem todos os plugins usados por você sejam parte dos testes, portanto, leve tal declaração de compatibilidade com cautela.

Por exemplo, um site WordPress com 3 plugins (A, B, e C). É possível que o plugin B, por exemplo, retorne um tipo de variável incorreta através de um filtro, com o qual o plugin C, usando o mesmo filtro, quer trabalhar. Isso pode então causar um erro fatal porque o tipo não é mais o que se espera. O plugin C é então visto como o culpado pela mensagem de erro, mesmo que o plugin B seja o verdadeiro infrator.

Incompatibilidades de interoperabilidade de plugins são impossíveis de descobrir quando testadas de forma isolada. Quanto mais plugins ativos, maior a probabilidade de algo dar errado. Por exemplo, seria muito útil encaminhar as solicitações de página de um site de produção para um ambiente de teste (com registro de erros ativado) para descobrir o que está dando realmente errado.

Com este tipo de problema, geralmente o proprietário do site só verá uma mensagem de que houve um erro com o último código executado (neste caso, do plugin C), embora o plugin C não seja necessariamente a causa do problema.

Geralmente, há uma grande quantidade de trabalho manual humano envolvido, e é necessária uma boa dose de esforço para detectar e corrigir esses problemas. Isso poderia ser automatizado usando testes de ponta a ponta, mas não vemos isso acontecendo muito no WordPress.

Teste de disponibilidade para plugins utilizados

Para desenvolvedores e equipes de desenvolvimento: Aceite o código somente quando os testes estiverem disponíveis. Dessa forma, você garante que menos testes manuais serão necessários, economizando muito tempo.

Questione a estratégia de teste ao considerar a compra de um plugin ou tema comercial. Dessa forma, criamos coletivamente conscientização entre os desenvolvedores/equipes de desenvolvimento na comunidade WordPress para priorizar os testes, e todos nos beneficiamos.

Os testes são frequentemente vistos – de forma injusta – como um custo, quando na realidade eles economizam dinheiro. O investimento adicional necessário para escrever testes compensa na forma de significativamente menos relatórios de bugs e menos tempo gasto corrigindo-os. Além disso, com testes automatizados de software, as extensões e modificações podem ser feitas mais rapidamente, pois os testes podem confirmar rapidamente se a funcionalidade existente continua funcionando.

O papel dos servidores WordPress e o PHP 8.x

Para o proprietário médio de um site, a orientação do seu servidor é altamente desejável. Considere o seguinte:

  • Documentação e atualizações para informar aos clientes que o WordPress Core, plugins e/ou temas podem não ser totalmente compatíveis com todas as versões do PHP.
  • Opções para testes (tais como trabalhar com um ambiente de teste)
  • Métodos para relatório de erros e contato com o suporte

Isso também beneficia o servidor web, pois os proprietários de sites geralmente entram em contato com o suporte do servidor em busca de ajuda quando surgem problemas. No caso de uma mudança para o PHP 8.0, 8.1 ou 8.2, o proprietário do site é responsável por eventuais problemas, e quanto mais informações o proprietário tiver para se preparar adequadamente para a mudança, melhor.

Disponibilizar o PHP 8.1 ou 8.2 para os clientes como um servidor web é uma coisa, mas ao fazer isso, eles devem se certificar de criar consciência entre os clientes para que estejam cientes de que podem surgir problemas. É recomendável testar o site em um ambiente de teste com uma versão diferente da que está em produção (ambiente “live”). (A seleção de versões do PHP está disponível por padrão na Kinsta, por exemplo.)

Tornar o PHP 8.1 ou 8.2 disponível para os clientes como um provedor de hospedagem é uma coisa, mas ao fazer isso, eles devem certificar-se de criar consciência entre os clientes para que eles estejam cientes de que os problemas podem vir à tona. É recomendado testar seu site em um ambiente de teste com uma versão diferente da produção. (A seleção de versões PHP está disponível por padrão na Kinsta)

Versão mínima do PHP para WordPress

Atualmente, mais de 15% de todos os sites utilizam a versão 7.0 ou anterior do PHP. Isso pode ser verificado nas estatísticas oficiais do WordPress. Cerca de 83% de todos os sites WordPress usam a versão 7.4 ou anterior. É importante observar que qualquer versão igual ou inferior à 8.0 não é mais suportada pelo PHP. Utilizar versões obsoletas do PHP pode resultar em problemas, pois as atualizações de segurança não são mais lançadas.

Para evitar problemas, é importante que os proprietários de sites WordPress estejam cientes e informados sobre a versão mínima em PHP que permitirá que seu site funcione com segurança. Por sua vez, os proprietários do site podem modificar a versão PHP eles mesmos (possível na Kinsta para todos os pacotes) ou pedir ao seu provedor de hospedagem para atualizar o site para uma versão mais recente do PHP. Em casos extremos, você pode mudar para um provedor de hospedagem de sites que suporte estas versões mais recentes.

Como o WordPress exige apenas a versão mínima de 7.4, muitos servidores e proprietários de sites não têm motivação suficiente para atualizar seus sites. Isso acontece apesar do fato de que o PHP 7.4 alcançou o fim da sua vida útil em novembro de 2022.

Se o WordPress aumentar a versão mínima do PHP, isso pode significar que muitos sites não serão mais compatíveis com uma atualização para a versão mais recente do WordPress. No entanto, as atualizações de segurança continuarão sendo lançadas para essas versões obsoletas por um bom tempo.

Resumo

Para atualizar seu site para PHP 8.0 ou superior, há várias etapas que você ou seu desenvolvedor devem seguir. Etapas importantes incluem:

  • Análise estática
  • Testes unitários
  • Teste de integração
  • Testes manuais

Ao mudar para o PHP 8.x, certifique-se de que tudo tenha sido devidamente testado. Esta é a única maneira de garantir que seu site irá funcionar corretamente, de forma rápida e segura, na versão mais recente do PHP.

Nós agradecemos imensamente a Juliette por participar deste artigo e por todo o seu trabalho nas ferramentas mencionadas!

Foto de Juliette, tirada por Jip Moors e usada com permissão.

Marcel Bootsman Kinsta

Business Development Manager Dutch and DACH Markets