PHP 8.2: O que isso significa para WordPress, Plugins e Desenvolvedores?

Publicados: 2022-12-14

O PHP 8.2.0 estreou em 8 de dezembro de 2022. Como uma grande atualização, traz melhorias de desempenho, sintaxe mais simples e maior segurança de tipo com null , false e true como tipos autônomos. Uma das maiores mudanças que provavelmente desafiarão os desenvolvedores do WordPress é a introdução de classes somente leitura , que não permitem propriedades dinâmicas.

As propriedades dinâmicas estão obsoletas e produzirão um erro fatal no PHP 9 ou possivelmente no PHP 10. Embora potencialmente doloroso - especialmente para o núcleo do WordPress - a depreciação é um recurso importante e um presente do PHP para os desenvolvedores.

Vamos dar uma olhada na evolução recente do PHP e também como os desenvolvedores do WordPress mantêm a compatibilidade com versões anteriores enquanto aproveitam os novos recursos quando eles beneficiam mais os usuários finais.

Acompanhando o Desenvolvimento PHP no WordPress

Como o núcleo do WordPress mantém uma compatibilidade significativa com versões anteriores sem datas de fim de vida planejadas quando as versões antigas não serão suportadas, cabe aos negócios do WordPress determinar seu próprio ciclo de vida do produto ou serviço e as versões do PHP que eles suportarão.

Ao contrário do WooCommerce, que requer um mínimo de PHP 7.4, o núcleo do WordPress atualmente recomenda apenas PHP 7.4 ou superior. Ele “também funciona com” PHP 5.6.20, que atingiu sua data de fim de vida no final de 2018. O projeto WordPress observa isso e adverte que o uso de versões PHP não suportadas “pode expor seu site a vulnerabilidades de segurança”. (Requisitos do WordPress.org)

Felizmente, apenas 5,1% de todos os sites WordPress atualmente usam PHP 5.6 e apenas 2% usam uma versão ainda mais antiga. 20% estão usando PHP 7.0 a 7.3, e o maior grupo (56,7%) está usando PHP 7.4. (Estatísticas do WordPress.org)

Infelizmente, o PHP 7.4 acabou de atingir sua data de EOL no final de novembro de 2022. O PHP 8.0 tem menos de um ano para seu suporte de segurança oficial durante a maior parte de 2023. A versão atual e ativamente suportada, PHP 8.1, envelhecerá no final de 2024. O PHP 8.2, que acaba de ter sua primeira versão estável, terá suporte de segurança até dezembro de 2025.

Este é um ciclo de lançamento rápido e não é surpresa que o ecossistema do WordPress se esforce para acompanhá-lo. Com mais da metade da web rodando no WordPress, é um grande navio que não pode virar rapidamente. É muito mais um ato de equilíbrio do que uma corrida em direção ao limite sangrento. O salto para o PHP 8 traz muitos benefícios, no entanto, com grandes recursos de aprimoramento de desempenho, como compilação PHP Just-in-Time (JIT) em tempo de execução para execução mais rápida com menos uso de memória.

A troca entre compatibilidade com versões anteriores e estabilidade, visão de futuro e inovação

A troca entre atender ao maior público possível de usuários e manter a moeda corrente com o PHP sempre representou um dilema para desenvolvedores, hosts e empresas de produtos do WordPress. Agências e freelancers com clientes de longo prazo e sites legados enfrentam o mesmo problema: atualizar os requisitos mínimos pode forçar os clientes existentes a fazer alterações significativas em seus sites ou vê-los quebrar.

Por um lado, os benefícios de manter-se atualizado com o PHP são segurança e desempenho aprimorados e os mais recentes conceitos e recursos de programação para desenvolvedores. Por outro lado, o principal benefício de atrasar o PHP mínimo exigido é uma base de clientes feliz (embora complacente) e ampla. É uma situação do tipo “me pague agora ou depois”. Em algum momento, você terá que arrancar o curativo.

Bons dados e telemetria sobre ambientes de usuário podem ajudar a determinar o tempo menos perturbador para aumentar um requisito mínimo de versão do PHP. A maioria dos desenvolvedores de plug-ins fica de olho nesses números com suas próprias ferramentas, pois não faz parte dos dados de instalação ativa do repositório de plug-ins do WordPress.org. Inevitavelmente, qualquer alteração potencialmente prejudicial que afete muitas pessoas certamente resultará em uma enxurrada de tíquetes de suporte.

Priorizar a compatibilidade com versões anteriores também envolve um alto trabalho de manutenção. Oferecer suporte a uma base de usuários muito grande e diversificada é ótimo para o usuário final, mas significa que os desenvolvedores precisam manter seu código funcionando em muitos ambientes diferentes. “Adoro oferecer suporte a versões mais antigas do PHP à medida que novos recursos são adicionados”, disse nenhum desenvolvedor, nunca!

Eles não precisam se preocupar apenas com o PHP herdado - também com os bancos de dados legados e dezenas de outras variações na pilha do WordPress. Casos extremos surgem e confundem até mesmo os especialistas quando há um amplo espectro de ambientes de servidor WordPress com elementos obsoletos.

A melhor hora para aumentar seu requisito mínimo de PHP

O lançamento do iThemes Security Pro 7.2 é um bom exemplo de aumento do requisito mínimo de PHP de um produto WordPress para oferecer inovação e estabilidade para clientes existentes.

A partir do lançamento da versão 7.2, o iThemes Security Pro exigiu o PHP 7.3 ou superior e suporta até 8.1. A decisão de atualizar o requisito PHP para o iThemes Security Pro foi tomada para implementar a estrutura WebAuthn. A implementação exigiu bibliotecas que precisam do PHP 7.3+ para gerenciar criptografia e chaves públicas. Os recursos 2FA, senha e login biométrico introduzidos no iThemes Security Pro 7.2 são um resultado direto dessa decisão. Em um momento em que suas senhas claras são quebradas, a equipe iThemes Security trouxe o login sem senha para o WordPress pela primeira vez como a principal experiência de autenticação do usuário.

Teria sido possível construir esses recursos reescrevendo as bibliotecas WebAuthn para compatibilidade com versões mais antigas do PHP. Claro, isso daria muito mais trabalho e criaria código adicional para manter. O caminho mais sábio era acompanhar a comunidade PHP em um ritmo moderado, adotando dependências que requerem PHP 7.3 ou superior. A maioria de seus usuários já estava lá. É por isso que a equipe de desenvolvimento do iThemes Security decidiu aumentar o requisito mínimo de PHP para usuários novos e existentes.

Para produtos WordPress que investem fortemente no editor de blocos Gutenberg, como o GiveWP, gerenciar mudanças pode ser ainda mais desafiador. A estabilidade e a baixa taxa de mudança no núcleo do WordPress podem ser frustrantes para os desenvolvedores de PHP de back-end, mas estão permitindo que os desenvolvedores de JavaScript/React de front-end impulsionem a plataforma.

Jason Adams, gerente de desenvolvimento da GiveWP, observa que eles não precisam ser compatíveis com versões anteriores porque podem migrar usuários entre versões à medida que o editor do site evolui. No entanto, “não existe migração para PHP”, comentou. Eventualmente, eles terão que se adaptar à arquitetura do PHP 9 e se afastar dos novos recursos obsoletos do PHP 8.2.

Não há um único “momento certo” para cada produto em todo o ecossistema WordPress atualizar os requisitos mínimos do PHP. “Não é um problema que você possa resolver filosoficamente”, disse-me Adams. Realmente depende de um julgamento baseado em quantos usuários serão afetados negativamente pela mudança. Se 90% ou mais estiverem no PHP 7.2 ou 7.4, é viável aumentar o requisito mínimo para esse nível.

Esses números podem variar muito, dependendo da base de usuários específica de um produto, diz Adams. Um produto usado por clientes mais aptos tecnicamente tenderá a estar mais próximo das versões do PHP atualmente suportadas. Um produto como o GiveWP, com muitas organizações sem fins lucrativos que o utilizam, precisará colocar mais peso na compatibilidade com versões anteriores. Outro caminho a seguir é permitir que o código legado e seus usuários se ramifiquem em uma versão de longo prazo que terá suporte, mas não terá novos recursos adicionados. Quando os usuários estiverem prontos para fazer a atualização, eles podem migrar para uma nova versão principal criada para compatibilidade futura com PHP.

Avisos de depreciação impulsionam o desenvolvimento

O WordPress.com acaba de lançar o PHP 8.2 como uma opção para seus planos de negócios e comércio eletrônico com recursos de hospedagem ativados e, no ecossistema do WordPress.org, é improvável que um código antigo razoavelmente bem projetado seja quebrado ou se torne inseguro com a próxima versão principal do PHP. liberar. Embora a base de código principal do WordPress.org ofereça oficialmente apenas suporte “beta” para PHP 8.0, ela geralmente funciona muito bem com as versões mais recentes do PHP, assim como os plug-ins com suporte adequado. Eles não lançarão erros fatais ou de análise. Você nem deve ver muitos avisos com a depuração ativada. Você pode ver muitos avisos de funções obsoletas, que não são erros - ainda.

As frustrações de um rápido ciclo de lançamento do PHP têm muito a ver com os desenvolvedores ficarem atolados na refatoração de seu código e brincando com aspectos obsoletos do PHP. Esse trabalho crítico pode deixá-los com menos tempo para explorar e inovar com novos conceitos e recursos que a versão mais recente do PHP traz.

Há outra maneira de olhar para esta situação. Lidar com recursos obsoletos do PHP é realmente voltado para o futuro e obriga os desenvolvedores a se tornarem fluentes nas próximas iterações de uma linguagem em evolução. Sem esse exercício um tanto forçado, o conhecimento existente se acomodaria mais facilmente em velhos hábitos que se tornarão ruins quando se tornarem obsoletos.

Os avisos de descontinuação estão apontando coisas que funcionam agora, mas serão interrompidas em versões futuras do PHP. Isso é bom para você se você for um desenvolvedor, como explica Brent Roose. Se os desenvolvedores prestarem atenção a esses avisos, eles terão muito tempo para verificar qualquer código obsoleto. E não deve ser um bloqueador de atualizações de versão menores.

Timothy Jacobs, desenvolvedor líder de segurança iThemes e WordPress Core Committer, diz que é bom ter avisos de descontinuação. Eles impulsionam os desenvolvedores a adotar códigos “mais corretos” e “menos frágeis” que serão cada vez mais seguros, com desempenho, à prova de erros e mais capazes de lidar com casos extremos. Nessa visão, os avisos E_DEPRECATED preenchendo seu log de erros são “como um sistema de alerta antecipado de que as coisas vão quebrar no futuro, mas não estão quebradas agora”.

Fazendo sem propriedades dinâmicas após o PHP 8.2

A justificativa de Nikita Popov para a eliminação gradual das propriedades dinâmicas no PHP 9 é um bom exemplo do impulso evolutivo do PHP em direção a códigos e convenções de programação mais resilientes:

A motivação para essa mudança é dupla: evitar erros (devido a erros de digitação ou renomeações) no caso comum e tornar explícitos os usos intencionais. O problema principal é que a leitura de uma propriedade inexistente emite um diagnóstico que torna o problema imediatamente aparente, enquanto a gravação em uma propriedade inexistente é totalmente silenciosa. O PHP não dá nenhuma indicação de que o programador cometeu um erro.

O vídeo de dois minutos de Brent Roose sobre a evolução do PHP 5.6 para o 8.2 é uma ilustração visual brilhante e simples de quão longe o PHP chegou de 2014 até o presente. Usando o exemplo de um simples objeto de transferência de dados, Roose mostra como o código PHP 5.6 encolhe dramaticamente para um bloco de código muito mais simples, enxuto e elegante no caminho para o PHP 8.2.

Como Roose observa em suas dicas para lidar com propriedades dinâmicas (que estão obsoletas no PHP 8.2), os desenvolvedores devem ter bastante espaço para atualizar seu código existente antes que os avisos de obsolescência se transformem em erros fatais. Essa pista diminuirá rapidamente, no entanto, e o WordPress é um caso especial. Tonya Mork tem uma proposta aceita no Trac para lidar com depreciações de propriedades dinâmicas desconhecidas no núcleo do WordPress. Ela e Juliette Reinders Folmer estão preocupadas com o fato de os desenvolvedores do WordPress não terem tempo suficiente para refatorar seu código, sem mencionar os desafios especiais de manter a compatibilidade futura para um projeto de vinte anos. Mork, Reinders Folmer e Sergey Biryukov foram os heróis amplamente desconhecidos dessa tarefa assustadora.

Em sua discussão sobre Propriedades Dinâmicas e Métodos Mágicos no PHP 8.2, Mork e Reinders Folmer apontam que as raízes do WordPress no PHP 3 e 4 o mantêm em um universo de programação processual sólido, enquanto o PHP continua avançando como uma linguagem orientada a objetos. Os principais desenvolvedores precisam descobrir uma maneira de manter o comportamento do código legado no PHP de hoje sem quebrar a compatibilidade com versões anteriores “e ainda tornar o código melhor e mais seguro e mitigar a depreciação das propriedades dinâmicas do PHP 8.2”, como Reinders Folmer coloca. “Na verdade, estamos tornando nossas próprias vidas muito difíceis com a regra de não quebrar [compatibilidade com versões anteriores] do [núcleo do WordPress]”, ela observa no vídeo.

“Há uma boa razão para isso”, responde Mork — “é para os usuários. Os usuários têm confiança de que podem apertar esse botão e atualizar, e que pensamos na compatibilidade com versões anteriores, que a priorizamos. É uma pedra angular para nós … para que os usuários possam ter confiança para atualizar.”

Todo Desenvolvimento é Manutenção...

É um desafio único tentar fazer o backport do PHP “moderno” para funcionar com as duas principais versões anteriores do PHP para manter a compatibilidade com versões anteriores no núcleo do WordPress. Os desenvolvedores de plug-ins têm uma tarefa muito mais fácil de atualizar seu código de maneiras que possam aproveitar os novos recursos, como as classes somente leitura do PHP 8.2 e a depreciação das propriedades dinâmicas. Grande parte desse trabalho também é em grande parte uma forma de manutenção.

Arquiteturalmente, as mudanças que o PHP 8+ está trazendo para o foco em conceitos de programação como imutabilidade. Estruturas de dados imutáveis ​​“não corrigem inerentemente problemas de segurança”, mas ajudam o código dos desenvolvedores a ser menos propenso a erros e mais correto, de acordo com Jacobs:

Eu não diria que uma estrutura de dados imutável é naturalmente segura e uma estrutura de dados mutável é insegura. Em vez disso, estruturas de dados imutáveis ​​podem ajudar a eliminar erros de programação que podem levar a problemas de segurança. Ao reduzir o número de estados diferentes em que nosso código pode existir, podemos reduzir a complexidade de nosso código e, portanto, reduzir as chances de cometer erros.

A melhor razão para manter o código no padrão das versões PHP ativamente suportadas é a redução do risco de segurança. O PHP 8.2 traz conveniências úteis e “guarda-corpos” na visão de Adams, mas pouco que irá entusiasmar os programadores ou ser visto como um divisor de águas. Algo como o atributo #[\SensitiveParameter] pode ser mais significativo na prática, pois permite que dados confidenciais sejam filtrados de rastreamentos de pilha que geralmente vão para serviços de terceiros. Introduzidos no PHP 8, os atributos são a escolha de Adams para a última inovação que chamou sua atenção por permitir algo que você não poderia fazer anteriormente: “descrever algo [como classes, variáveis, métodos, etc.] de uma meta-perspectiva”.

Aproveitar os novos recursos do PHP 8.0 a 8.2 e versões futuras é onde a criatividade dos desenvolvedores pode brilhar, mas simplesmente oferecer suporte a essas versões, para que os plug-ins e o núcleo do WordPress não quebrem, é prático e vital.

…E toda manutenção é arte

Jeff Atwood tem uma postagem de blog antiga, mas excelente, intitulada “A nobre arte da programação de manutenção” que li recentemente, graças ao Boletim de hackers de Kale Davis. “A programação de manutenção é amplamente vista como trabalho de zeladoria”, escreve Atwood. Isso me lembrou da artista Mirele Laderman Ukeles, cujo “Maintenance Art Manifesto” sempre me pareceu muito relevante para programação e desenvolvimento web:

Dois sistemas básicos: Desenvolvimento e Manutenção. A bola azeda de toda revolução: depois da revolução, quem vai recolher o lixo na segunda-feira de manhã? […] Os sistemas de desenvolvimento são sistemas de feedback parcial com grande espaço para mudanças. Os sistemas de manutenção são sistemas de feedback direto com pouco espaço para alterações.

Laderman Ukeles era uma jovem artista e mãe recente em 1969, quando escreveu o manifesto e declarou Manutenção é Arte. Ela estava frustrada com a forma como as obras de arte de ponta e o trabalho de alto status são separados do trabalho que os torna possíveis: criação de filhos, ensino de habilidades e tradições artísticas ou apenas apresentação de uma mostra de arte. Ela fez uma exposição memorável baseada em si mesma como zeladora de museu. Em seguida, ela passou a maior parte de sua carreira (em andamento) como artista residente do Departamento de Saneamento da cidade de Nova York. Seu primeiro projeto nessa função foi agradecer pessoalmente a todos os 8.500 trabalhadores do saneamento “por manterem Nova York viva”.

Atwood tem uma visão semelhante da programação. Ele cita várias figuras importantes da engenharia de software que dizem que denegrir o trabalho de manutenção está totalmente errado. Robert L. Glass sentiu que “a manutenção é um desafio intelectual significativo, bem como uma solução e não um problema”, portanto deve ser considerada uma tarefa importante para as pessoas mais qualificadas. Joel Spolsky escreveu há muito tempo que os desenvolvedores são preguiçosos, e a razão pela qual eles “sempre querem jogar fora o código e começar de novo” é que “é mais difícil ler o código do que escrevê-lo”.

Em uma conversa com Andy Hunt, Dave Thomas argumentou: “Toda programação é programação de manutenção porque você raramente escreve código original. …. Você passa a maior parte do tempo no modo de manutenção. Portanto, você também pode morder a bala e dizer: "Estou mantendo desde o primeiro dia". As disciplinas que se aplicam à manutenção devem ser aplicadas globalmente.” Hunt concordou: “É apenas nos primeiros 10 minutos que o código é original quando você o digita pela primeira vez. É isso."

Em última análise, Atwood se inclina para esse ponto de vista, mas ecoa a perspectiva comum do desenvolvedor WordPress que ouvi de Jason Adams e Timothy Jacobs. A arte especial do desenvolvimento/manutenção do WordPress?

“É um ato de equilíbrio.”

O melhor plugin de segurança do WordPress para proteger e proteger o WordPress agora com 35% de desconto!

Atualmente, o WordPress é responsável por mais de 40% de todos os sites, tornando-se um alvo fácil para hackers com intenções maliciosas. O plug-in iThemes Security Pro elimina as suposições sobre a segurança do WordPress para facilitar a segurança e a proteção do seu site WordPress. É como ter um especialista em segurança em tempo integral na equipe que constantemente monitora e protege seu site WordPress para você.

Economize 35% agora!