O PHP completa 31 anos e a Vonage acompanha o PHPVerse

É impressionante pensar que, em junho, o PHP completou 31 anos. Desde suas origens como uma linguagem de script básica destinada a auxiliar um único desenvolvedor até se tornar um gigante do código aberto na web, foi uma jornada e tanto. Se você estiver curioso para saber como está a situação atual do PHP e para onde ele está indo, vai ter uma boa noção lendo este resumo.

No meu dia a dia profissional, no fundo, ainda sou um desenvolvedor PHP. Tudo o que eu crio, desde demos até contribuições para projetos de código aberto, gira em torno do SDK de PHP da Vonage. Isso é algo essencial para o que fazemos; as linguagens individuais e suas comunidades são é importante estar conectado a.

Após minha entrevista com o diretor executivo da Fundação PHP, a JetBrains anunciou mais uma edição anual do PHPVerse, uma conferência de um dia, realizada exclusivamente online, voltada para desenvolvedores de PHP. Este ano, assim como no ano passado, o evento contou com um time de peso de nomes conhecidos do mundo do código aberto para falar sobre diversos temas da comunidade. Neste artigo, vou abordar metade das palestras com comentários para manter seus conhecimentos em PHP atualizados ou, caso você não seja um desenvolvedor PHP, talvez você consiga entender um pouco melhor por que a linguagem continua tão popular. Fique ligado na segunda parte, que será publicada em breve.

Elizabeth Barron: Conhecendo a Fundação PHP

Comecei mencionando a palestra da Vonage com a Elizabeth, então provavelmente faz sentido começar por essa palestra. Desde sua criação, tem sido revigorante contar com uma infraestrutura de governança de código aberto para PHP. A Fundação foi incorporada à The Linux Foundation, recebeu um aumento significativo de financiamento do governo da Alemanha e agora conta com uma equipe de desenvolvedores internos, totalmente remunerados, espalhados pelo mundo.

Essa palestra se concentrou na direção que ela deu à Fundação desde o início, nos planos que estão em andamento e em suas reflexões sobre o futuro. Portanto, vou dividi-las nessas três áreas.

Primeiro: Conclusões

No início, Elizabeth decidiu ouvir as pessoas. Isso envolveu muitas, muitas ligações (cerca de 60, sendo o autor deste artigo uma delas) para coletar as opiniões dos desenvolvedores de PHP sobre a situação atual da linguagem. A conclusão apontou quatro áreas diferentes que merecem atenção:

·      Transparência

·      A percepção do PHP fora da nossa comunidade

·      Falta de novos desenvolvedores para o crescimento

·      Aspetos internos e o processo de votação

Dois: Ações

Como resultado dessas conclusões, foram lançadas as seguintes iniciativas sob o termo genérico “Grupos de Interesse Especial” (SIG):

·      Grupo de Trabalho sobre Segurança do Ecossistema (SIG)

·      Grupo de Interesse Especial (SIG) do Programa de Embaixadores de Divulgação do PHP

·      Grupo de Trabalho sobre Integração

·      Grupo de Interesse Especial em Criptografia

·      Grupo de Interesse Especial (SIG) em Eventos Comunitários

·      Grupo de Interesse Especial em Acessibilidade

Quem estiver interessado em participar desses grupos pode saber como fazer isso no blog da Fundação PHP

Três: O Futuro

O maior problema que o PHP enfrenta é uma percepção , e não um problema técnico. Ela concluiu que a linguagem é estável, a comunidade é grande e engajada; portanto, há motivos para otimismo.

Nils Adermann: Compositor e especialista em segurança da cadeia de suprimentos de embalagens em 2026

Na sequência do anúncio, feito este ano, da criação de uma equipe de Segurança do Ecossistema na Fundação PHP, parece oportuno que Nils tenha vindo falar sobre segurança da cadeia de suprimentos. Vimos vários casos de grande repercussão nos últimos cinco anos, como o comprometimento do XZ Utils, em que um mantenedor mal-intencionado conseguiu inserir secretamente um backdoor nos pacotes de lançamento do XZ Utils — algo utilizado em muitas das principais distribuições Linux. Também houve um aumento nos ataques a máquinas locais, o que não é surpreendente, considerando que ferramentas de IA e IDEs, como o VSCode e o PHPStorm, agora fazem muitas chamadas externas para escrever código. Essas ferramentas também possuem mercados de plug-ins de código aberto, o que faz com que o acesso a repositórios do GitHub seja um dos ataques mais comuns na maioria dos principais gerenciadores de pacotes.

Superfície de Risco do Compositor: Publicação

O modelo de publicação do Composer sempre teve uma vantagem estrutural: quando você marca uma versão no GitHub, o Packagist registra uma URL que aponta para a API do GitHub, a qual gera dinamicamente um arquivo zip diretamente a partir do código-fonte.

A desvantagem é que esses arquivos zip gerados dinamicamente não são estáveis. Eles mudam com o tempo, o que significa que não é possível assiná-los com segurança. Embora o arquivo de bloqueio do Composer fixe um commit para uma determinada tag, isso significa que, para fins de auditagem de segurança, os desenvolvedores precisam revisar cuidadosamente os arquivos de bloqueio. Não sei se você já trabalhou em um projeto grande, mas eles podem ficar enormes grandes. A Packagist (a empresa por trás do Composer), no entanto, possui um recurso de revisão de atualizações, portanto, existem ferramentas disponíveis para facilitar um pouco esse processo.

Recursos de segurança integrados

Já foram implementadas várias medidas de segurança para combater ataques à cadeia de suprimentos.

· Imutabilidade da versão estável

· A estrutura de políticas de dependência

· A opção de recorrer ao código-fonte caso o download do arquivo zip falhe agora está desativada por padrão

·      Varreduras automáticas do Aikido Security

·      Registro de transparência pública

Novos recursos em desenvolvimento

·      Controle centralizado de segurança do portfólio de pacotes para projetos maiores, por exemplo, Symfony

·      Tempo de recarga do disparo, para permitir a varredura automática

·      Janelas de preparação para publicação

·      Autenticação multifatorial (MFA) obrigatória

·      Hospedagem de artefatos imutáveis pelo Packagist, para aumentar a confiança no gerenciador de pacotes

Como você pode ajudar

Em primeiro lugar, há várias medidas que você pode tomar agora para reforçar sua segurança. Isso inclui

·      Ativação da autenticação multifatorial (MFA)

·      Utilize ferramentas como o Zizmor para garantir a segurança do pipeline de CI

·      Certifique-se de que está usando o Composer 2.0

·      Utilize a hospedagem do Private Packagist para atender a requisitos de segurança personalizados.

Mais importante ainda, desenvolvedores e organizações podem deixar de lado as estatísticas por trás de algo que é, essencialmente, gratuito. O Packagist recebe 4.800 solicitações por segundo, é de fato o único gerenciador de pacotes PHP e disponibiliza 450.000 pacotes que são instalados cerca de 4 bilhões de vezes por mês. Embora parte do financiamento para novos recursos venha da Fundação PHP, é essencial que o Packagist receba os recursos necessários para manter essa infraestrutura. Um programa formal de patrocínio está sendo lançado este mês; se sua organização depende dessa infraestrutura, é fundamental que ela receba o financiamento necessário.

Jonathan Bossinger: O WordPress está morto, viva o WordPress

Quem me conhece provavelmente já percebeu que estou em uma espécie de cruzada contra uma frase famosa que as pessoas repetem sem parar, mas que não é verdadeira. Se isso se aplica ao PHP, é justo dizer que o WordPress também é alvo exatamente dessas mesmas opiniões infundadas. A questão é que você não conseguiria continuar operando 40% da web se não valesse a pena usá-lo.

Jonathan se concentrou em uma série de mitos a serem desmentidos; por isso, aqui estão dez mitos, organizados de forma prática, sobre os quais ele falou.

Mito 1: Uma base de código OOP legada, que não segue os padrões do PHP

Foi uma grande surpresa para mim descobrir que todas as novas instalações do WordPress usam o PHP 8.3 e agora contam com declarações de tipo, interfaces e namespaces, após um esforço iniciado a partir de 2020 para modernizar a base de código.

Mito 2: Ausência de mecanismo de modelos

Os temas de blocos agora usam Block Markup, que é uma linguagem de modelagem baseada em comentários HTML. As tags PHP do passado (alguém sente saudades das páginas HTML cheias de código PHP misturado?) desapareceram, então sim: agora funciona.

Mito 3: O WordPress é lento

Outra crítica que já foi feita ao PHP em geral, no passado. O WordPress agora conta com o plugin Performance Lab, que realiza testes de desempenho e otimiza a velocidade. O carregamento especulativo foi integrado ao núcleo do WordPress 6.8, proporcionando um aumento de desempenho de 98,2%.

Mito 4: O “Global State” é tudo

Os blocos agora possuem escopos independentes, o que permite separar os escopos do front-end e do back-end. O uso antigo de the_post() e outros horrores do tipo, dos quais me lembro de muitos e muitos anos atrás no WordPress

Mito 5: Os campos personalizados exigem plugins de terceiros

Com a introdução da API Block Bindings, já não é mais necessário que os campos personalizados dependam, quase sempre, de uma série de plug-ins de terceiros para funcionarem.

Mito 6: É preciso aprender React

Matt Mullenweg talvez tenha dado um pequeno tiro no próprio pé com essa declaração quando o projeto Gutenberg começou a ser lançado. Depois de comentar que os desenvolvedores precisariam aprender JavaScript como uma habilidade essencial, talvez alguns desenvolvedores de PHP tenham ficado preocupados. Quer dizer, eu ficaria, já que tenho um ódio bastante irracional pelo React. Os desenvolvedores que não querem mexer no front-end podem usar a API de Interatividade para conseguir isso, de modo que a interação ocorra com blocos dinâmicos.

Mito 7: O WordPress não é seguro

Outro caso comum: já foram tomadas várias medidas para garantir que os desenvolvedores tenham à disposição as ferramentas necessárias para que isso não aconteça. Atualizações automáticas para plugins e temas, proteção contra reversão e hash de senha bcrypt já foram implementados, e o próprio WordPress não apresenta vulnerabilidades críticas sem correção.

Mito 8: Ausência de gerenciamento de dependências

Embora seja verdade que o WordPress não venha com suporte ao Composer por padrão, o projeto Roots Bedrock torna isso possível. A mesma equipe lançou recentemente o WP Packages, que é um repositório do Composer para todos os plugins e temas gratuitos do wordpress.org

Mito 9: Documentação desatualizada

A equipe de tem estado bastante ocupada, como fica evidente pela dedicação que tem dedicado ao blog para desenvolvedores, publicando tutoriais e a série de Videos “Learn WordPress”. O portal para desenvolvedores passou por uma reformulação completa, de modo que agora temas, plugins, o editor de blocos e a API REST são abordados de forma abrangente.

Mito 10: Não é possível usar exceções nativas do PHP moderno

É verdade que, no passado, o WordPress tinha seu próprio objeto Exception, WP_Error. Essa restrição já foi removida, de modo que os desenvolvedores têm liberdade para criar seu próprio tratamento personalizado de exceções. A própria equipe do núcleo está discutindo atualmente a possibilidade de remover o WP_Error do código.

Conclusão

Assim como os desenvolvedores que podem julgar o PHP com base na experiência de 20 anos atrás, vale a pena considerar revisitar o assunto. O fato é que os desenvolvedores modernos do WordPress estão usando ferramentas como PHPStan, PHPUnit, Composer etc., mas a comunidade em geral simplesmente não está ciente disso. Desse ponto de vista, Jonathan lança um desafio aos desenvolvedores do WordPress para que escrevam sobre o desenvolvimento moderno na plataforma e aos desenvolvedores que não trabalham com o WordPress para que deem outra chance a ela.

Fabien Potencier: Symfony em grande escala

O Symfony foi o primeiro framework de PHP que usei. Na verdade, quando eu fazia treinamentos pontuais, me especializei no Symfony 2. Desde aquela época, o projeto cresceu enormemente. Fabien está no comando há mais de 20 anos.

Que tipo de manutenção Fabien precisa realizar? Bem, há mais de trezentos repositórios, com 5.000 versões marcadas por ano. 25% de todos os downloads do Composer Packagist vêm do Symfony (embora Fabien se apresse em observar que os downloads tendem a ser uma métrica um tanto superficial, devido aos downloads do pipeline).

Um aspecto que considero realmente interessante no Symfony é a forma como o framework está estruturado: ele é, ao mesmo tempo, um framework completo e uma série de componentes independentes. Devido a esse design, ele é utilizado como motor para outros grandes projetos, como o Joomla! e o Drupal, mas também como componentes utilizados por projetos como o Laravel e o Magento, todos mencionados por Fabien.

Durante muitos anos, no início da minha carreira, o debate entre “microsserviços” e “monorepo” foi acirrado. Curiosamente, Fabien nos conta sobre sua decisão consciente, logo no início do Symfony 2, de que tudo ficaria no mesmo repositório, sob symfony/symfony. Uma ferramenta criada por ele, chamada Splitsh, cuida da instalação; ela monitora os webhooks do GitHub, que então baixam quaisquer outros pacotes solicitados durante a instalação sob o namespace symfony, incluindo Symfony AI, Twig, Symfony UX e Symfony Console, para citar alguns. Esses são chamados de “sub-splits”.

Como o Symfony conseguiu fazer isso?

Fabien destaca quatro áreas principais que levaram o Symfony ao ponto em que se encontra hoje.

Em primeiro lugar, estabilidade dentro da equipe principal. Fabien no comando, 30 desenvolvedores principais, muitos deles com longa trajetória.

A seguir, uma estrutura de trabalho . Sou um grande, grandíssimo fã dessa abordagem, porque, quando preciso trabalhar no mundo do Node, fico constantemente confuso com as muitas, muitas opções disponíveis na hora de programar. Existe um estilo de código consistente (“à maneira do Symfony ”) e padrões abertos (PSR).

Para seus clientes que dependem da estrutura, a consistência é fundamental. O Symfony está programado para duas versões secundárias por ano e uma versão LTS a cada dois anos.

Por fim, um assunto que me é muito caro devido à manutenção que precisamos realizar no SDK PHP da Vonage: versão semântica. Não consigo entender como lançávamos software antes sem usar o versionamento semântico.

Automação e IA

Um aspecto complicado da manutenção de um projeto de código aberto desse porte é que você precisará dos processos certos e, portanto, das ferramentas certas para ajudá-lo a alcançar esse objetivo. Durante a maior parte da história do Symfony, muitas etapas eram realizadas manualmente. A IA, no entanto, mudou isso.

Fabien criou agentes personalizados para lidar com a maior parte das tarefas em massa e repetitivas. Isso inclui o trabalho de investigação por trás de conflitos de mesclagem complexos, especialmente porque o Symfony precisa, atualmente, manter seis ramificações marcadas.

O próprio processo de lançamento agora é executado por um agente PHP escrito pelo próprio Fabien. Esse agente recebe o comando de lançamento, pergunta de que tipo de lançamento se trata, responde com um plano de lançamento que deve ser revisado e, em seguida, pode ser executado quando a confirmação for dada. Ele conta até com um recurso adicional que permite gerar rascunhos de posts de blog para os lançamentos.

Vantagens e desvantagens da IA: Segurança

Talvez seja por causa da velocidade com que estamos avançando na era da IA, mas as desvantagens nem sempre são discutidas tão abertamente. Fabien nos conta que costumavam passar por um Audit de segurança uma vez por mês. Agora, fazem uma por dia. Recentemente, lançaram uma versão do Symfony que corrigiu 50 vulnerabilidades comuns (CVEs).

Esse enorme volume de atividades em ritmo acelerado está sendo impulsionado por um único fator: os LLMs. A razão pela qual afirmo que, na minha opinião, há vantagens e desvantagens é que a equipe do Symfony agora está, essencialmente, obrigada a usar LLMs para corrigir essa quantidade de código, pois, se a equipe do Symfony não o fizer, alguém mais encontrará uma vulnerabilidade (CVE) por meio de um LLM. A outra desvantagem é ter que verificar as respostas em busca de falsos positivos, mas, no geral, há um avanço positivo no fato de que Fabien pretende usar essas ferramentas para lançar versões mais seguras, em vez de corrigi-las posteriormente.

Conclusão

Essencialmente, o Symfony vem se fortalecendo cada vez mais, e Fabien e a equipe principal têm utilizado todas as ferramentas à sua disposição para se manterem à frente de um framework PHP que realiza algumas das tarefas mais pesadas de todo o setor. Pessoalmente, presenciei muitas mudanças (acho que o lançamento do Symfony Flex foi mais ou menos na época em que mudei para outros frameworks) e, ao voltar, me deparei com uma variedade impressionante de recursos, acompanhada de uma documentação excelente.

Na próxima vez…

Foram oito palestras no total, então fiquem ligados na segunda rodada, na qual abordarei IA com Ashley Hindle e Jeffrey Way, Drupal com Mike Merchel e RFCs do PHP com Larry Garfield.