Por que a fuga do WordPress para novos CMS muitas vezes ignora a evolução da plataforma

Recentemente, acompanhei uma discussão de um profissional no linkedin que decidiu dizer um “Adeus definitivo” ao WordPress para um de seus sites. O motivo? A busca por ferramentas mais modernas (como o Payload CMS), linguagens tipadas e a facilidade de integração com Inteligência Artificial — o famoso “Vibe Coding”.

É perfeitamente compreensível o fascínio por novas stacks e frameworks baseados em javascript, Next ou Node. No entanto, usar a evolução do mercado como justificativa para cravar que o WordPress ou o PHP “pararam no tempo” é um diagnóstico precipitado e, tecnicamente, equivocado.

A fuga para novos CMS muitas vezes ignora a real evolução da plataforma. Vamos aos fatos.

O mito da tipagem e a verdade sobre o PHP

Um dos argumentos mais comuns de quem abandona o ecossistema é que “na era da IA, precisamos de linguagens tipadas para as LLMs entenderem melhor”, assumindo que o PHP falha de forma drástica nesse quesito.

Isso é um reflexo claro de um preconceito histórico, enraizado na lembrança do PHP 5.x. A realidade de quem desenvolve em PHP moderno é completamente diferente. Desde o PHP 7, a linguagem introduziu declarações de tipos escalares e de retorno. Nas versões 8.x, isso atingiu um nível de maturidade altíssimo:

• Tipagem Estrita Opcional: Basta usar declare(strict_types=1) e o PHP passa a validar os tipos rigorosamente.
• Evolução da Sintaxe: Hoje utilizamos propriedades tipadas em classes (PHP 7.4), Union Types (PHP 8.0), Intersection Types (PHP 8.1) e até tipos DNF (PHP 8.2).
• Ecossistema e LLMs: Ferramentas de análise estática como PHPStan forçam um padrão de tipagem robusto. As IAs de Vibe Coding leem esse código fortemente tipado do PHP com extrema facilidade e precisão.

Dizer que o gargalo é a falta de tipagem da linguagem não é um reflexo da realidade técnica atual. O problema não é o PHP, mas pode ser como o código está sendo escrito em plugins e temas.

WordPress, React e IA: O “Vibe Coding” já está aqui

Achar que desenvolver para WordPress é ficar preso exclusivamente ao PHP legado é um erro.

Se você está a sentir essa limitação, provavelmente ainda está usando o formato antigo de temas e não os blocos, que marcam uma nova fase na arquitetura do WordPress.

A realidade moderna do CMS é outra:

• O back-end do WordPress usa React: o editor de blocos (também chamado de Gutenberg por esse ser o nome do projeto que o iniciou) usa React há anos. É perfeitamente possível (e recomendável) criar blocos dinâmicos com ferramentas modernas.
• A arquitetura Headless: O WP continua a ser uma ferramenta incrível como CMS Headless, permitindo que você consuma a API e construa o front-end com a tecnologia que preferir.
• Integração com IA: A própria equipe do WordPress já disponibiliza skills oficiais (através do repositório agent-skills no GitHub) para uso em IDEs baseadas em IA, como o Cursor, o Antigravity, o Windsurf e o VS Code. Além disso, a Automattic lançou o Telex, uma IA que lhe permite criar seus próprios blocos e temas para WordPress. Ou seja, o ecossistema está ativamente preparado para o desenvolvimento assistido por IA.

Vale lembrar que ferramentas de análise estática, como PHPStan e Psalm, já forçam um padrão de tipagem robusto em projetos profissionais há anos. E adivinhe? As IAs e IDEs de Vibe Coding leem com extrema facilidade e precisão esse código fortemente tipado e os docblocks do PHP, sobretudo se você lembrar de fornecer as skills com as instruções para tal.

A dor de ser grande: Retrocompatibilidade

É inegável que o core do WordPress possui código legado, muitas vezes apelidado de “macarrônico” por programadores mais puristas. Mas isso não é fruto de incompetência, desleixo ou preguiça, e sim da necessidade de retrocompatibilidade.

O WordPress alimenta uma fatia gigantesca da internet mundial. Segundo dados da W3Techs, a plataforma é usada por 42,7% de todos os websites, o que representa 59,9% do mercado dos sistemas de gestão de conteúdos (CMS).

Não é possível simplesmente elevar o requisito mínimo do PHP da noite para o dia e quebrar milhões de sites, porque os servidores e as empresas de hospedagem demoram a atualizar suas infraestruturas, e os plugins e temas devem ser testados em novas versões do PHP, e como muitos clientes desenvolvem suas próprias soluções (e não usam apenas plugins 100% atualizados de forma precisa), isso geraria grandes problemas. O código legado e a grande possibilidade de personalização da plataforma (criação de temas e plugins) é uma parte da “dor de ser grande”.

As atualizações são graduais por uma questão de responsabilidade.

Para ter uma ideia de como isso funciona na prática, na versão 6.9 atual, o WordPress ainda dá suporte ao PHP 7.2. No entanto, a equipa do core tem subido a régua constantemente e abandonado versões antigas com segurança:

• A versão 6.3 abandonou o PHP 5.6 e adicionou suporte à versão 8.2;
• A versão 6.4 adicionou suporte ao PHP 8.3
• A versão 6.6 removeu o suporte ao 7.0 e 7.1, e ofereceu suporte ao PHP 8.4;
• A versão mais atual hoje, a 6.9 já introduz o suporte beta ao PHP 8.5.

O sistema evolui, mas sem deixar para trás a base gigantesca que construiu a web como a conhecemos.

O Paradoxo da performance e os “300 Plugins”

Quando um site em WP apresenta baixa performance, a culpa raramente é do PHP ou do CMS em si. Na esmagadora maioria das vezes, o problema está nas decisões de quem criou o site.

Ferramenta nenhuma compensa falta de conhecimento técnico. A lentidão geralmente vem de temas excessivamente pesados, arquitetura de nuvem mal dimensionada e a clássica instalação de dezenas de plugins de terceiros mal codificados. Precisamos de separar o que é responsabilidade do core do sistema e o que são as “nossas escolhas”.

Se instalar muitos plugins ruins, o vilão não é o WordPress, mas sim a terceirização da responsabilidade pela qualidade geral a desenvolvedores terceiros, sem avaliar se suas soluções são realmente bem feitas.

Reclamar vs. colaborar

Todo o sistema tem problemas, mas a mentalidade de trocar de CMS toda a vez que algo não é 100% do nosso agrado gera um ciclo de retrabalho infinito. Começar do zero numa ferramenta nova muitas vezes significa perder funcionalidades maduras que o WP já oferece nativamente ou através de plugins bem conceituados no mercado.

Além disso, o WordPress é open source (código aberto). Em vez de apenas reclamar, por que não colaborar?

Quando comecei a usar o WP, ele ainda mal estava traduzido para o português. Em vez de abandonar a plataforma, comecei a colaborar nas traduções para o português do Brasil, tanto de plugins e temas quanto do WordPress em si. Hoje, sou um dos brasileiros que gerem os acessos para tradução de temas e plugins no repositório oficial. Nas empresas que trabalhei, como Automattic e Liquid Web, por diversas vezes ajudei a resolver bugs nos plugins criados pela empresa, e muitas vezes alguns dos profissionais da empresa também ajudavam na correção de erros no core do WordPress.

O tempo é um recurso escasso e a equipa do core precisa de priorizar tarefas. Se é um programador que domina PHP ou React e vê pontos de melhoria, a comunidade está de portas abertas. Já temos integrações MCP a caminho e um futuro promissor desenhado por quem coloca a mão na massa.

Em vez de dizer “adeus”, que tal dizermos “como posso ajudar a melhorar”?

Conclusão

Obviamente, tem zero problemas você decidir utilizar outras plataformas por preferências pessoais ou maior adequação ao projeto que você tiver em mente, mas é possível mudar de plataforma sem sair atirando e apontando problemas que não existem na plataforma que você deixou.

Eu mesmo estou estudando React e criando outro projeto do zero, sem utilizar o WordPress, por entender que algo feito sob medida para o que preciso será mais adequado do que um CMS que oferece seções que não serão úteis num sistema com foco diferente, que não é apenas um site de conteúdo a ser gerenciado por um CMS.