Mudando para o PHP 8.x em quatro etapas – uma entrevista com Juliette Reinders Folmer

A atualização de um site WordPress, plug-in ou tema para uma nova versão do PHP é uma tarefa que se repete regularmente. Mas como fazer isso da forma mais eficiente possível? Como você sabe que não vai esquecer nada? Existe um roteiro para isso?

Neste artigo, abordaremos essas questões (e mais) e veremos o que está envolvido em uma transição suave para o PHP 8.x para seu site, plug-in ou tema WordPress, incluindo um roteiro.

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 ao seu redor, focando principalmente em projetos de código aberto, incluindo WordPress.

Você está pronto para fazer a troca sem problemas também? Curioso sobre o nosso plano passo a passo? Então vamos mergulhar de cabeça!

PHP 8.x — O que mudou

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

• Notas de lançamento para PHP 8.0 e PHP 8.1
• Guia de migração para PHP 8.0 e PHP 8.1
• WordPress e PHP 8.0 e estado atual
• O que há de novo no PHP 8.0 e PHP 8.1

Depois de ler estes artigos, você ficará completamente atualizado sobre o que mudou no PHP 8.xe o que você precisa fazer para que seus projetos PHP rodem sem problemas.

Se você não tiver certeza de qual é a melhor maneira de começar, não há problema. Na conversa com Juliette, discutimos isso em detalhes e explicaremos a você neste artigo da maneira mais completa possível como você pode mudar 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.

Mudando para o PHP 8.x: como começar

Mudar para o PHP 8.x parece simples e, tecnicamente, é. Muitos hosts permitem que você especifique qual versão do PHP deseja usar para o seu site no painel de administração. Na Kinsta, mudar a versão do PHP pode ser feito com um único clique no painel MyKinsta.

Mas antes de fazer isso, há algumas coisas das quais 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 agência para investigar se seu site é adequado para rodar em PHP 8.x. Você está procurando um terceiro que possa ajudá-lo com isso? Em seguida, consulte nossa página de Parceiros listando várias empresas confiáveis ​​que podem ajudá-lo.
• Se o seu site WordPress foi criado por terceiros, um desenvolvedor ou uma agência, entre em contato com eles para perguntar se o seu site pode ser executado em PHP 8.x.
• Se você construiu seu site WordPress – com seu próprio tema personalizado, por exemplo, ou plugins autodesenvolvidos – temos um roteiro para você abaixo.

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

Seja qual for a sua escolha, nós o aconselhamos a não apenas mudar seu site ao vivo para o PHP 8 e “ver se funciona”. Você está curioso sobre a aparência do seu site e mal pode esperar para vê-lo rodando no PHP 8? Em seguida, comece a testar em um ambiente de preparação. Um bom host permitirá que você configure facilmente um ambiente de teste.

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 importar facilmente seu site do painel MyKinsta, após o qual você pode alterar a versão do PHP para 8.0 ou 8.1.

Se você não encontrar nenhum problema no ambiente de teste, isso não significa necessariamente que não haja nenhum problema. O roteiro abaixo irá dizer-lhe porquê.

Teste de compatibilidade do PHP 8.x: o roteiro

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

Um projeto de desenvolvimento de software consiste em grande parte em testes. Neste artigo, examinamos especificamente os testes que podem ajudá-lo a fazer a transição para o PHP 8.x sem problemas. Em nosso artigo sobre DevOps Tools, você encontrará uma seção com uma coleção de ferramentas que você pode usar.

Os seguintes tipos de testes são discutidos nesta postagem do blog:

Vamos examinar 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 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 de 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.

Ferramentas para Análise Estática

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

• PHPCompatibilidade
• Salmo
• PHPStanGenericName

No momento da escrita, nem todas as verificações do PHP 8.1 são suportadas na versão mais recente do PHPCompatibility. As verificações do PHP 8.1 podem estar na versão de desenvolvimento, portanto, certifique-se de usá-las (por enquanto) ao usar PHPCompatibility para analisar seu projeto e ver quais erros/recomendações existem.

As verificações do PHP 8.1 serão lançadas em breve em uma nova versão principal . Se você deseja se manter atualizado sobre isso e possui uma conta GitHub, abra o repositório GitHub de PHPCompatibility e navegue até Watch -> Custom -> Releases , onde você pode optar por ser notificado quando uma nova versão for lançada.

PHPCompatibility, que apenas testa 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 testVersion — por exemplo, 8.0+ (8.0 e superior) — dentro do PHPCompatibility.

Você deve estar atento a funções obsoletas ou excluídas, valores padrão alterados de parâmetros de função, se deve usar concat sem parênteses, se deve usar match como um nome de função (já que foi reservado desde o PHP 8.0), etc.

Psalm e PHPStan são boas adições e podem ajudá-lo realizando verificações adicionais relacionadas a tipos de variáveis. A desvantagem dessas ferramentas é que é preciso muita configuração para obter relatórios sobre o PHP 8.0 e 8.1. Mesmo que sejam bem-sucedidos, você pode esperar muitos falsos positivos. Falsos positivos são notificações dadas de forma errada, causadas pelas limitações da análise estática.

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

Resumo:

• Realize análises estáticas com PHPCompatibility, Psalm, PHPStan
• Resolva todos os problemas legítimos

Teste de unidade

A próxima etapa do processo é o teste de unidade. O teste de unidade é um método de testar pedaços de código individualmente. Nos testes de unidade, testes direcionados específicos serão desenvolvidos para cada unidade. Isso envolverá a execução de diferentes cenários. De preferência, cada cenário é testado separadamente dos demais para que os testes sejam independentes entre si.

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

Suportando Múltiplas Versões do PHP

Como um construtor de plug-in, se você deseja oferecer suporte a várias versões do PHP, certifique-se de que os testes no CI sejam executados em todas as versões do PHP compatíveis.

Claro, você também pode suportar apenas versões mais recentes, a escolha é inteiramente sua.

Testar com várias versões do PHP requer que você use 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 como os testes são escritos, esta parte pode ser complicada.

Para contornar isso, você pode usar o PHPUnit Polyfills (escrito por Juliette e patrocinado por Yoast). Isso permite que você escreva testes que não são oficialmente suportados pelo PHPUnit 9 (e, portanto, podem ser executados no PHP 8.x). Os Polyfills então fazem seus testes funcionarem em 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 execução, o próximo passo é garantir que os problemas encontrados nos testes sejam corrigidos.

Cobertura de código

Executar esses testes é a maneira mais confiável de encontrar incompatibilidades entre versões.

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

• Suponha que você tenha uma função A e tenha escrito um teste para ela, e a função A chame as funções B, C e D como parte da lógica da função.
• O teste para a função A foi escrito para testar a lógica da função A, mas também chamará as funções B, C e D durante o teste. Para as funções B, C e D, você geralmente testa apenas o “caminho feliz” — a situação em que tudo corre bem — e, portanto, essas funções ainda não foram totalmente testadas, embora (parte do) código nessas 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 um @covers Dessa forma, B, C e D não são “contados” no cálculo de cobertura de código, o que permite que você veja qual parte do seu código é coberta por testes.

Freqüentemente, 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 .

''Ao testar, você precisa ter certeza de que uma função faz o que deveria fazer, mas também que uma função não faz o que não deveria.'' - Juliette Reinders Folmer Click to Tweet

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ê recebeu uma mensagem de erro? Ou a variável é convertida com a função continuando normalmente? E se um valor inesperado for passado para a função?

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

PHP está ficando mais rígido

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

Por causa dessa busca por mensagens de erro mais úteis no PHP, você pode ver que tornar o código existente adequado para as novas versões do PHP leva cada vez mais tempo. Tornar o código que funcionou no PHP 5.6 adequado para o PHP 7.0 levou apenas uma fração do tempo na maioria dos casos em comparação com a atualização do código para torná-lo adequado para o PHP 8.1. E isso apesar do fato de que o PHP 7.0 foi um lançamento “principal”, enquanto o PHP 8.1 é um “menor”.

Em muitos casos, o teste ainda é a única maneira confiável de determinar o que precisa ser modificado para dar suporte a uma nova versão.

O teste de unidade é possível com várias ferramentas, incluindo:

• PHPUnitName
• Zombaria
• Behat,
• Narrador

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

Em última análise, não importa quais ferramentas você usa. O mais importante é que você teste e faça os testes rodarem em novas versões do PHP. Esta etapa às vezes pode ser muito complicada, mas felizmente, como mencionado anteriormente, existem ferramentas para isso, como PHPUnit Polyfills.

Teste de integração

O teste de integração é a próxima etapa que executaremos, após a análise estática e o teste de unidade. 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”. Isso inclui testar com um banco de dados ativo (teste) ou testar 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, esses 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. O WP Test Utils fornece ferramentas para escrever testes de integração e unidade, nos quais o WordPress é “simulado” usando Brainmonkey e Mockery, onde as funções comumente usadas do WordPress são “falsificadas” para que você esteja testando seu próprio código e não o código do WordPress.

O teste de integração com o WordPress é uma história mais complicada porque envolve a integração com o WordPress e o conjunto de testes do WordPress. Dependendo de quais versões do WordPress um plugin ou tema suporta, você deve 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, WordPress 5.6 a 5.8 usa PHPUnit 5 a 7 para testar PHP 5.6 a PHP 8.0, mas a partir do WordPress 5.9, o próprio WordPress também usa PHPUnit Polyfills para suporte mais amplo. O WP Test Utils atua como uma ponte para superar todas essas diferenças.

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

Teste manual

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

Por exemplo, verifique isso com os autores do plugin e veja se eles indicam que é compatível com PHP 8.x. A questão, claro, é como o plugin foi testado. Muitas vezes, a resposta aqui é: isoladamente. As funções do plug-in geralmente foram testadas em conjunto com o WordPress sozinho, sem outros plug-ins ativos. E mesmo que outros plug-ins tenham sido usados ​​nesses testes, é provável que nem todos os plug-ins usados ​​por você tenham feito parte do teste, portanto, aceite essa declaração de compatibilidade com cautela.

Por exemplo, um site WordPress com 3 plugins (A, B e C). É possível que o plug-in B, por exemplo, retorne um tipo de variável incorreto por meio de um filtro, com o qual o plug-in C, usando o mesmo filtro, deseja trabalhar. Isso pode causar um erro fatal porque o tipo não é mais o esperado. O plug-in C é então visto como o culpado pela mensagem de erro, mesmo que o plug-in B seja o verdadeiro infrator.

As incompatibilidades de interoperabilidade de plug-in são impossíveis de descobrir ao testar isoladamente. Quanto mais plugins ativos, maior a probabilidade de algo dar errado. Por exemplo, seria muito benéfico passar as solicitações de página de um site ativo para um ambiente de preparação (com registro de erros ativado) para descobrir o que realmente está errado.

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

Na maioria dos casos, muito trabalho manual e humano está envolvido, e uma quantidade saudável de graxa de cotovelo é necessária para detectar e corrigir esses problemas. Isso pode ser automatizado usando testes de ponta a ponta, mas não vemos isso acontecendo muito no WordPress.

Disponibilidade de teste para plug-ins 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 sejam necessários, o que economiza muito tempo.

Questione sua estratégia de teste se quiser comprar um plugin ou tema comercial. Dessa forma, criamos coletivamente conscientização entre os desenvolvedores/equipes de desenvolvimento na comunidade WordPress para obter testes mais altos na agenda e todos nós nos beneficiamos.

O teste é frequentemente visto – injustamente – como um custo quando, na realidade, economiza dinheiro. O investimento extra necessário para escrever testes compensa na forma de significativamente menos relatórios de bugs e menos tempo gasto corrigindo bugs. Além disso, com o teste de software automatizado, extensões e modificações podem ser feitas mais rapidamente porque os testes podem confirmar rapidamente se a funcionalidade existente continua funcionando.

''Seja gentil com seu futuro eu, por favor ;-)'' - Juliette Reinders Folmer Click to Tweet

O papel dos hosts WordPress e PHP 8.x

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

• Documentação e atualizações para clientes de que o WordPress Core, plug-ins e/ou temas não são (em alguns casos) compatíveis com versões cruzadas do PHP
• Opções para teste (como trabalhar com um ambiente de preparação)
• Métodos para relatar erros e entrar em contato com o suporte

Isso também beneficia um host da Web, pois os proprietários do site geralmente entram em contato com o host para obter ajuda quando surgem problemas. No caso de uma mudança para PHP 8.0 ou 8.1, o proprietário do site é responsável por possíveis problemas, e quanto mais informações o proprietário tiver para se preparar adequadamente para a mudança, melhor.

Disponibilizar o PHP 8.0 ou 8.1 para os clientes como um host da Web é uma coisa, mas, ao fazê-lo, eles devem certificar-se de conscientizar os clientes de que podem surgir problemas. Recomenda-se testar seu site em um ambiente de preparação com uma versão diferente da versão ativa. (A seleção de versões do PHP está disponível por padrão em Kinsta.)

Versão mínima do PHP para WordPress

Mais de 15% de todos os sites atualmente usam PHP versão 7.0 ou inferior. Isso pode ser visto nas estatísticas oficiais do WordPress. Cerca de 83% de todos os sites WordPress atualmente usam PHP versão 7.4 ou inferior. Observe que qualquer versão inferior ou igual à versão 7.4 não é mais suportada pelo PHP. O uso de versões de fim de vida útil do PHP pode resultar em problemas porque 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 do PHP que permitirá que seu site funcione com segurança. De sua parte, os proprietários do site podem modificar a versão do PHP por conta própria (possível em Kinsta para todos os pacotes) ou solicitar ao host que atualize o site para uma versão mais recente do PHP. Em casos extremos, você pode alternar para um host compatível com essas versões mais recentes.

Como o WordPress requer apenas uma versão mínima de 7.4, não há motivação suficiente para muitos hosts e proprietários de sites atualizarem seus sites. E isso apesar do fato de que o PHP 7.4 atingiu seu fim de vida 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 a ser lançadas para essas versões desatualizadas por algum tempo.

Resumo

Para mudar para PHP 8.0 ou superior em seu site, há várias etapas que você ou seu desenvolvedor devem executar. Passos importantes incluem:

• Análise estática
• Teste de unidade
• Teste de integração
• teste manual

Ao mudar para o PHP 8.x, certifique-se de que tudo foi devidamente testado. Essa é a única maneira de garantir que seu site funcione de maneira adequada, rápida e segura em uma versão mais recente do PHP.

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.