É 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.

Este artigo foi originalmente publicado em Por que a fuga do WordPress para novos CMS muitas vezes ignora a evolução da plataforma

Recentemente, a equipe do WordPress anunciou uma mudança importante: o fim do suporte oficial para as versões 7.2 e 7.3 do PHP a partir do WordPress 7.0, previsto para abril de 2026.

Esta notícia não deve ser vista como um problema, mas sim como um passo necessário para a modernização do ecossistema. Abaixo, analisamos o que isso significa na prática e como as estatísticas de uso estão determinando o futuro do CMS.

O critério dos 5%: por que o suporte será encerrado agora?

A equipe do WordPress segue uma regra histórica clara: uma versão do PHP só é considerada para “aposentadoria” quando a sua base de utilização cai abaixo dos 5%. Atualmente, a soma das versões 7.2 e 7.3 representa menos de 4% das instalações monitoradas.

Com o lançamento do WordPress 7.0, a versão mínima suportada passará a ser o PHP 7.4.0. No entanto, é importante não focar apenas no mínimo; a recomendação oficial continua sendo o uso do PHP 8.3, que oferece o melhor equilíbrio entre segurança e funcionalidades modernas.

O panorama atual: quais são as versões mais usadas?

De acordo com os dados mais recentes compartilhados pela equipe do Core, a comunidade está progredindo, mas ainda existe uma fragmentação relevante. Estas são as versões de PHP mais utilizadas hoje:

• PHP 8.3 (16,74%): A versão recomendada, em crescimento constante.
• PHP 8.2 (27,29%): Atualmente a versão mais popular, demonstrando uma adoção sólida de tecnologias recentes.
• PHP 8.1 (15,39%): Uma versão estável e muito presente em servidores gerenciados.
• PHP 7.4 (22,20%): Esta ainda é a segunda versão mais usada e será a nova “régua” mínima oficial.

As versões que perderão o suporte (7.2 e 7.3) somam pouco mais de 3.8%, o que justifica a decisão de não gastar mais tempo em retrocompatibilidade pensando nelas e focar em otimizar o tempo para o WordPress evoluir de forma mais ágil.

E se você está ainda usando o PHP 7.4… já passou da hora de começar a se preocupar com isso, a têndencia no uso dessa versão antiga é de queda a cada ano.

O impacto técnico para desenvolvedores

Esta mudança é extremamente positiva do ponto de vista técnico. Menos suporte a versões obsoletas significa que o código do WordPress pode, gradualmente, começar a adotar funcionalidades mais limpas do PHP moderno.o o PHP 7.4… já passou da hora de começar a se preocupar com isso; a tendê

Para quem desenvolve plugins ou temas, o planejamento deve começar agora. O plugin Gutenberg também subirá a exigência mínima para o PHP 7.4. Isso permite o uso de recursos como typed properties ou arrow functions com maior segurança, embora a recomendação seja sempre mirar no PHP 8.x.

E vale lembrar que o WordPress já oferece uma função para checar versão do PHP, como wp_check_php_version e is_php_version_compatible.

O que acontece com sites em versões antigas?

Não há motivo para pânico imediato, afinal, dificilmente esse será o seu caso. Sites que rodam em PHP 7.2 ou 7.3 continuarão funcionando, mas ficarão “presos” na versão 6.9 do WordPress.

A recomendação é entrar em contato com o serviço de hospedagem o quanto antes. A maioria dos provedores modernos permite a troca da versão do PHP com poucos cliques através do painel de controle (cPanel, Plesk ou painéis próprios), mas é claro que o ideal é criar uma versão de testes do seu site antes de trocar a versão do PHP, e assim testar tudo em um ambiente controlado, e não “com o carro andando” (seu site no ar).

Conclusão

A evolução do PHP é fundamental para a segurança e longevidade do WordPress. Ao se libertar do peso de versões lançadas há quase uma década, o projeto ganha fôlego para implementar melhorias em IA, ferramentas de automação e infraestrutura de testes.

Este artigo foi originalmente publicado em WordPress 7.0: fim do suporte para PHP 7.2 e 7.3

Agora, em dezembro de 2025, estamos diante da próxima grande fronteira. Em um novo post no Make WordPress Core blog, o Jason Adams, um dos colaboradores do time de IA do WordPress (nova equipe formada este ano), publicou uma visão ousada e necessária: a Inteligência Artificial não deve ser apenas uma funcionalidade ou um plugin, mas um fundamento da plataforma.

Mas o que isso significa na prática para nós, desenvolvedores e proprietários de sites? Vamos mergulhar nessa análise técnica e estratégica.

O conceito de IA como infraestrutura

Até hoje, se você quiser alguma IA no seu site, o caminho é um só: instalar um plugin que conecte à API de alguma IA, como a OpenAI ou a Anthropic, ao seu site. O problema dessa abordagem descentralizada é a fragmentação. Cada plugin cria sua própria interface, conexão de API e regras de UX.

A proposta do artigo “AI as a WordPress Fundamental” é mudar isso. A ideia é tratar a IA da mesma forma que o WordPress trata o banco de dados ou a API HTTP: uma camada de abstração padronizada.

Isso significa que o WordPress Core forneceria as “trilhas” e a interface padrão, permitindo que plugins e temas utilizem recursos de IA sem precisar reinventar a roda a cada nova instalação.

Os 4 pilares da IA nativa

A visão apresentada divide a integração da IA em quatro áreas principais onde ela pode atuar como um copiloto nativo:

1. Criação de Conteúdo: Ferramentas de escrita assistida, tradução e reformulação de texto diretamente no editor.
2. Geração de Mídia: Criação e edição de imagens ou otimização de ativos visuais.
3. Construção de Site (Site Building): Auxílio na geração de layouts, padrões (patterns) e estruturação de páginas.
4. Administração e Código: Talvez o ponto mais interessante para desenvolvedores — IA ajudando a depurar erros, sugerir correções de código ou gerenciar configurações complexas do painel.

A arquitetura: “Bring Your Own LLM”

Para a comunidade de desenvolvimento, este é o ponto crucial. O WordPress, sendo um software Open Source e agnóstico, não pode (e não deve) se casar com um único fornecedor, como a OpenAI ou o Google Gemini, por exemplo.

A arquitetura proposta sugere um modelo de “Bring Your Own LLM” (Traga seu próprio modelo).

Como isso deve funcionar tecnicamente?

Imagine que o WordPress Core introduza uma API de IA abstrata, um adaptador MCP (Model Context Protocol) para conectar o WordPress a IA que você desejar. Em vez de você escrever código cURL para bater na API do ChatGPT, você usaria funções nativas do WordPress.

Embora o código final ainda não tenha sido lançado, a lógica arquitetural esperada seria algo semelhante a como usamos o sistema de arquivos (WP_Filesystem).

// CONCEITUAL: Como poderia ser uma chamada nativa de IA no futuro
// Em vez de configurar endpoints e chaves em cada plugin, o Core gerencia a conexão.

$ai_response = wp_ai_generate_text( [
    'prompt'  => 'Escreva um resumo otimizado para SEO deste post.',
    'context' => get_the_content(),
    'model'   => 'user_default_preference', // O usuário define o modelo nas configurações globais no próprio WordPress
] );

if ( ! is_wp_error( $ai_response ) ) {
    update_post_meta( $post_id, '_ai_summary', $ai_response );
}

Isso resolve dois grandes problemas:

1. Padronização de UI: O usuário não terá 10 botões de “Gerar com IA” diferentes na tela de edição.
2. Segurança e Chaves: As credenciais da API ficam em um único lugar seguro no Core, e não espalhadas por 15 plugins diferentes.

O desafio da privacidade e do Open Source

A comunidade do WordPress sempre valorizou a propriedade dos dados. A grande questão levantada nas discussões do Make WordPress é: como integrar IA nativa sem enviar dados dos usuários a servidores de terceiros sem consentimento?

A visão atual parece caminhar para uma abordagem onde:

• O WordPress fornece a interface e a conexão.
• O usuário escolhe o provedor (pode ser uma API paga externa ou até um modelo local rodando no servidor, como Llama, se a infraestrutura permitir).
• Nada é ativado por padrão sem a ação explícita do administrador (“Opt-in”).

Por que isso é bom para todos?

Minha experiência diz que a padronização sempre traz eficiência. Se o WordPress em si assumir a responsabilidade de criar a interface de chat/prompt e a conexão com a API, nós, desenvolvedores e usuários, podemos focar no que realmente importa, o uso: o contexto e a aplicação.

Não precisaremos mais aguardar desenvolvedores (ou nós mesmos) criarem interfaces de chat/prompts em React no editor de blocks. Poderemos simplesmente conectar diretamente a interface nativa de IA com a API de uma IA de nossa preferência e injetar nossos contextos específicos (seja para um plugin de SEO, de e-commerce ou de formulários, ou até mesmo o conteúdo em si, descrições de imagens, etc).

Conclusão

A transformação da IA em um fundamento do WordPress é um passo ambicioso, mas necessário para manter a relevância do CMS na próxima década. Isso move o WordPress de um simples gerenciador de conteúdo para um sistema operacional web mais inteligente.

Ainda estamos na fase de proposta e visão, mas o recado é claro: a IA no WordPress deixará de ser um “puxadinho” via plugin para se tornar parte do alicerce da casa.

O que você acha?

Você prefere ter o controle total da IA via plugins específicos ou acredita que o Core deve padronizar essa camada para evitar o caos? Deixe sua opinião nos comentários.

Este artigo foi originalmente publicado em IA como fundamento do WordPress: a visão do Core para o futuro da plataforma

Recentemente, foi publicado o State of Enterprise WP 2025, uma pesquisa anual conduzida por grandes agências do ecossistema (como Big Bite e Human Made) que mapeia como organizações de nível empresarial. Estamos falando aqui de empresas na lista da Fortune 500, grandes editoras e multinacionais que utilizam o CMS.

Li o relatório completo e cruzei com as análises do The Repository para trazer os insights que realmente importam para nós, profissionais da área. E adianto: os números são surpreendentes até para mim.

O que é o “State of Enterprise”?

Antes de mergulharmos nos dados, é importante contextualizar. Este relatório não pesquisa o usuário comum de hospedagem compartilhada. Ele foca em CTOs, CMOs e gerentes de produto de empresas que investem pesado em tecnologia.

O objetivo é entender como o WordPress se comporta como parte de uma “Digital Experience Platform” (DXP) integrada, e não apenas como um ferramenta isolada.

O dado mais importante: 95% de compromisso a longo prazo

O ponto alto do relatório deste ano, destacado também pelo The Repository, é a confiança. 95% dos entrevistados afirmam que veem o WordPress como uma solução estratégica de longo prazo para suas organizações.

Isso é um salto significativo em relação aos anos anteriores. O que isso nos diz?

1. Estabilidade: Grandes empresas não trocam de tecnologia baseadas em “hype”. Se elas estão ficando, é porque a plataforma amadureceu.
2. Ecossistema: A disponibilidade de plugins enterprise, segurança aprimorada e agências especializadas criou uma rede de segurança robusta.

Minha visão: Para nós, desenvolvedores, gerentes de produtos, etc, isso significa que ainda vale a pena investir numa carreira nessa área. A demanda por especialistas capazes de lidar com escala, desempenho e integrações complexas só tende a crescer.

Aprofundamento no uso: WordPress não roda sozinho

Um ponto técnico interessante do relatório é como o uso do WordPress se aprofundou. Ele deixou de ser apenas o “site institucional” ou o “blog da empresa” para assumir papéis centrais.

As empresas estão integrando o WP em stacks complexas. Não estamos falando apenas de instalar plugins, mas de conectar o WordPress a:

• CRMs (Salesforce, HubSpot);
• Sistemas de DAM (Digital Asset Management);
• Ferramentas de teste A/B;
• Ferramentas de automação de Marketing proprietárias.

A arquitetura enterprise

O relatório sugere que a arquitetura desacoplada (Headless WordPress) continua sendo uma escolha forte para quem precisa de front-ends em React/Next.js, mas o “Classic/Hybrid” (usando Gutenberg) recuperou força devido à facilidade de edição.

Para quem gosta de código, isso reforça a importância de dominar a REST API e o WP-GraphQL.

Orçamento e valorização do profissional

Outro dado crucial: os orçamentos estão aumentando ou se mantendo estáveis. Diferente de outras áreas da tecnologia que sofreram cortes drásticos em 2024/2025, o investimento em CMS e gestão de conteúdo continua prioritário.

As empresas entenderam que o WordPress Open Source não significa “custo zero”. Significa “liberdade de código”. Elas estão dispostas a pagar por:

• Hospedagem de alta performance (WordPress VIP, WPEngine Enterprise, Kinsta);
• Auditorias de segurança;
• Desenvolvimento de blocos Gutenberg customizados.

Desafios que geram oportunidades

Nem tudo são flores. O relatório aponta dores latentes das grandes empresas, e é aqui que você pode vender seus serviços:

1. Segurança e Governança: O medo de plugins vulneráveis ainda existe. Oferecer serviços de curadoria e code review é um diferencial enorme.
2. Performance em escala: Manter o Core Web Vitals verde com milhões de acessos exige otimização de banco de dados e estratégias de cache avançadas (Redis, Varnish).
3. Treinamento de Equipe: Com a evolução do Full Site Editing (FSE), as equipes de marketing precisam de treinamento.

Conclusão: O WordPress segue forte na guerra corporativa

O State of Enterprise 2025 deixa claro que o debate “WordPress serve para empresas grandes?” acabou (ou já devia ter acabado). A resposta é um “sim” retumbante.

O mercado está migrando de “construir sites” para “construir experiências digitais”. Se você é um desenvolvedor, o caminho para 2025 é focar em integrações, segurança e desenvolvimento moderno de blocos. O dinheiro e a estabilidade estão aí.

O WordPress não é apenas o CMS mais popular do mundo; hoje, é o sistema operacional da web corporativa… e em breve, com MCP nativo e integração com IA diretamente no core do WordPress, teremos ainda mais a crescer nesse lado.

Este artigo foi originalmente publicado em State of Enterprise WP 2025: Por que grandes empresas seguem apostando no WordPress

Com mais de 9 milhões de downloads na primeira semana, a equipe já identificou cenários específicos em que o site pode quebrar visualmente ou apresentar falhas funcionais. Se você atualizou seu site recentemente e notou comportamentos estranhos — especialmente com temas clássicos ou envio de e-mails, este artigo é para você.

Vamos mergulhar nos detalhes técnicos e práticos das correções (hotfixes) anunciadas em 12 de dezembro, explicando o porquê, o como e o que fazer para manter seu site estável até a chegada da versão de manutenção (6.9.1).

O cenário pós-lançamento do WordPress 6.9

Antes de entrarmos no código, é importante contextualizar. O WordPress 6.9 trouxe avanços significativos, como a Abilities API e melhorias na performance de carregamento (especialmente com a Interactivity API).

No entanto, a equipe de desenvolvimento (Make WordPress Core) confirmou que um pequeno subconjunto de sites está enfrentando problemas críticos. A filosofia aqui é transparência: embora a maioria dos sites esteja voando baixo, configurações específicas de servidor e temas antigos (Classic Themes) foram impactados.

Aqui estão os dois principais problemas confirmados e como resolvê-los.

1. Quebra de estilos em temas clássicos

Este é, sem dúvida, o problema mais visual e perceptível.

O problema

O WordPress 6.9 introduziu uma nova lógica para carregar estilos de blocos “sob demanda” (on demand) em temas clássicos. A intenção era nobre: melhorar a performance carregando apenas o CSS dos blocos que estão realmente na página.

Porém, essa otimização causou um efeito colateral na cascata do CSS (CSS Cascade). Em alguns casos, a folha de estilos padrão wp-block-library é omitida indevidamente, ou a ordem de carregamento muda, fazendo com que estilos do seu tema não consigam sobrescrever os padrões do core (ou vice-versa). O resultado? Blocos desajeitados, espaçamentos incorretos e layouts quebrados.

A solução técnica

A equipe do Core está rastreando isso no ticket #64354. Enquanto o patch definitivo não sai no WordPress 6.9.1, a recomendação oficial é utilizar um plugin de correção temporária ou desativar essa otimização específica.

O Core Committer Weston Ruter disponibilizou uma solução rápida. Se você é desenvolvedor e precisa resolver isso via código (“the hard way” ou para incluir no functions.php do seu tema filho), a lógica é forçar o carregamento dos assets combinados.

Você pode tentar reverter o comportamento usando filtros que controlam o carregamento de assets, mas a solução mais segura recomendada no momento é garantir que os assets do bloco sejam enfileirados globalmente até que a lógica de detecção seja corrigida.

O plugin Load Combined Core Block Assets, criado por Weston, foi criado especificamente para “estancar esse sangramento” sem que você precise editar arquivos PHP.

2. Falhas no envio de e-mails

Este problema é mais silencioso e, por isso, mais perigoso.

O problema

Para melhorar a confiabilidade do envio de e-mails, o WordPress 6.9 atualizou bibliotecas subjacentes e a forma como se comunica com serviços de correio eletrônico. Ironicamente, isso expôs bugs em configurações específicas de servidores e de bibliotecas PHP.

O resultado é que sites que enviavam e-mails perfeitamente na versão 6.8 (formulários de contato, redefinição de senha, notificações de WooCommerce) pararam de enviar e-mails após a atualização.

Como diagnosticar e corrigir

O problema está sendo tratado no ticket #64368. Diferente do problema de CSS, a solução aqui varia muito de acordo com a sua hospedagem.

Um outro Hotfix plugin, mantido por múltiplos desenvolvedores do Core do WordPress, foi atualizado incluindo uma correção temporária para isso.

Quando sai a versão 6.9.1?

Geralmente, quando bugs críticos são descobertos após um lançamento, esperamos uma versão de manutenção (como a x.x.1) em questão de dias. Desta vez, a estratégia mudou.

Após analisar os dados, a equipe de liderança do WordPress decidiu que a versão 6.9.1 só será lançada em Janeiro de 2026, na melhor das hipóteses. O motivo é prudente: lançar correções apressadas durante as festas de fim de ano (período crítico para e-commerces e tráfego) pode introduzir novos bugs e causar mais danos do que benefícios.

O que isso significa para você? Se o seu site foi afetado pelos bugs da versão 6.9, a ajuda via atualização automática não virá nas próximas semanas. Você precisará aplicar as correções listadas acima para garantir que seu site funcione corretamente durante o Natal e o Ano Novo.

Atualizar ou esperar?

Com a confirmação de que a versão 6.9.1 só chega em janeiro, minha recomendação estratégica é clara:

1. Se você AINDA NÃO atualizou: Segure a mão. Permaneça na versão 6.8. Não vale a pena arriscar a estabilidade do seu site nas semanas mais movimentadas do ano se você pode pular direto para a versão corrigida mês que vem.
2. Se você JÁ atualizou: Verifique seu site agora. Abra páginas em aba anônima para checar o layout e teste seus formulários de contato. Se encontrar erros, aplique os hotfixes acima imediatamente. Não espere pela atualização automática.

O WordPress 6.9 é um passo incrível para o futuro do CMS, mas neste momento, a prioridade deve ser a estabilidade da sua operação.

Este artigo foi originalmente publicado em Melhorias no WordPress para versão 6.9.1

Com base nas recentes discussões no canal Make WordPress Core e nas análises do The Repository, podemos ver que o planejamento para a versão 7.0 não é apenas uma atualização incremental. Estamos falando de mudanças estruturais que prometem redefinir como colaboramos e gerenciamos conteúdo na web.

Neste artigo, vou dissecar os principais pilares discutidos até agora: a tão aguardada Colaboração em Tempo Real e a necessária Renovação do Admin, além de tocar nos aspectos técnicos que nós, desenvolvedores e usuários do WP, precisamos monitorar.

1. Colaboração em tempo real: A “Fase 3” chega com tudo

Há anos ouvimos falar sobre as quatro fases do projeto Gutenberg. O WordPress 7.0 parece ser o marco definitivo para a consolidação da Fase 3: Colaboração.

Imagine a experiência de editar um documento no Google Docs, mas no editor de blocos do WordPress. A proposta é permitir que múltiplos usuários editem o mesmo post ou página simultaneamente, vendo as alterações uns dos outros em tempo real… mas se você leu meu artigo sobre a Fase 3, já sabia disso, né?

O desafio técnico

Para desenvolvedores, isso levanta questões interessantes sobre a arquitetura de dados. O WordPress precisará lidar com a concorrência de dados de forma muito mais agressiva.

Embora o código final ainda esteja longe, a lógica por trás disso provavelmente envolverá uma evolução significativa na REST API e o uso intensivo da Interactivity API para gerenciar estados via WebSockets ou tecnologias similares (como Yjs, que já foi testado de forma experimental e relatado neste post).

2. O “Admin Refresh”: finalmente um painel mais moderno

Sejamos honestos: o design do painel do WordPress (wp-admin) tem a mesma estrutura básica desde a versão 3.8, lançada em 2013. Ele é funcional, mas em um mundo de interfaces React ultrarrápidas e designs minimalistas, ele começou a revelar a idade.

O planejamento para o WordPress 7.0 inclui um tópico chamado Admin Refresh. Não se trata apenas de uma nova camada de tinta (CSS), mas de repensar a usabilidade.

O que está na mesa:

• Modo Escuro Nativo: Finalmente, sem a necessidade de plugins.
• Navegação Otimizada: Redução da desordem causada por dezenas de plugins adicionando menus de nível superior.
• Acessibilidade: Um foco renovado para garantir que o painel seja utilizável por todos, seguindo padrões WCAG mais rígidos.

Para quem desenvolve temas e plugins, isso significa que precisaremos estar atentos às novas diretrizes de UI (user interfaces) para garantir que as telas de configuração não pareçam “alienígenas” no novo painel.

3. Contínua evolução dos blocos

Em termos de blocos e editores, os paops no make descrevem uma longa lista de recursos novos e em desenvolvimento. Entre eles, novos blocos como Abas, Breadcrumbs, Lista de Reprodução, Slider, Dialogs, Ícone e Sumário, além do trabalho contínuo para estabilizar o bloco Grids e adicionar suporte à lightbox ao bloco de Galerias.

Outros recursos potenciais focam na melhoria do fluxo de escrita e das interações de arrastar e soltar (drag n drop), no gerenciamento da navegação e em fluxos de trabalho mais ricos para a edição de padrões e modelos.

4. Sob o capô: PHP e banco de dados

Uma versão Major (x.0, como por exemplo 6.0 ou 7.0) é a oportunidade perfeita para quebrar a retrocompatibilidade em favor da performance e segurança. No WordPress 7.0, a infraestrutura será um foco central.

Requisitos de PHP

É quase certo que o WordPress 7.0 aumentará o requisito mínimo da versão do PHP. Com o PHP 8.0 e 8.1 chegando ao fim da vida útil (End Of Life) em termos de segurança, é provável que o WP 7.0 exija PHP 8.2 ou superior.

Isso é excelente para nós, desenvolvedores, pois permite escrever código mais limpo, tipado e performático.

Se você ainda mantém sites em servidores com PHP 7.4, considere este o seu aviso final para atualizar.

Abstração de banco de dados (SQLite e o “Performance Lab”)

Outro tópico quente é a integração oficial do suporte ao SQLite. E isso não é apenas especulação: a equipe de Core Performance já validou essa arquitetura exaustivamente.

recurso começou como um teste dentro do plugin oficial de testes de performance, o Performance Lab, onde foi submetido a cenários reais de uso. O sucesso foi tanto que a funcionalidade evoluiu para um plugin de testes próprio (SQLite Database Integration), provando que o WordPress já consegue operar de forma estável sem o MySQL.

O que isso muda para o 7.0? A expectativa é que essa abstração se torne nativa. O ganho prático é imenso: sites menores, ambientes de teste e aplicações simples poderão rodar com apenas um arquivo (.sqlite), eliminando a necessidade e o custo de configurar um servidor MySQL/MariaDB complexo.

4. Performance e mídia

O compromisso com a performance continua. O WordPress 7.0 deve trazer o suporte a formatos de imagem modernos (como AVIF e HEIC), além de aprimorar o Lazy Loading nativo para iframes e imagens.

A Interactivity API, introduzida no 6.5, deve amadurecer completamente no 7.0, permitindo interações complexas no front-end (como “favoritar” um post ou adicionar ao carrinho) sem o peso de carregar bibliotecas jQuery inteiras ou React pesado no front-end.

Conclusão

O planejamento do WordPress 7.0 indica que a plataforma não está acomodada. A introdução de colaboração em tempo real coloca o WP em competição direta com ferramentas de produtividade SaaS, enquanto a renovação do admin garante que a experiência do usuário não fique presa no passado.

Lembre que ainda estamos na fase de planejamento (Kick-off) da nova versão, e muita coisa vai mudar até o lançamento oficial. Mas, como especialistas, nosso trabalho é antecipar os movimentos e compartilhar com vocês aqui o que está por vir.

Minha recomendação agora?

1. Garanta desde já que seus ambientes de desenvolvimento estejam rodando as versões mais recentes do PHP (veja as versões suportadas aqui).
2. Comece a estudar a Interactivity API se você desenvolve blocos personalizados.

Este artigo foi originalmente publicado em WordPress 7.0: O que esperar da próxima versão?

Resumindo, o problema de usar texto lorem ipsum em designs de UI / UX é que ele revela muito pouco sobre a conexão entre o design e o conteúdo.

Neste artigo, vamos falar sobre as armadilhas de usar o texto lorem ipsum em seus projetos de design e explicar por que usar conteúdo real é melhor. Também veremos como você pode começar a projetar sem lorem ipsum.

As armadilhas de usar lorem ipsum em seus projetos

A maioria dos designers de UI/UX provavelmente já usou o lorem ipsum em seus protótipos. É uma maneira fácil de representar onde o conteúdo aparecerá na interface enquanto apresenta um design esteticamente agradável.

Nos estágios iniciais do processo de design, usar lorem ipsum em vez de conteúdo realista pode ajudá-lo a experimentar diferentes conceitos de design rapidamente. No entanto, embora não haja problema em usar o texto lorem ipsum em protótipos de baixa fidelidade, onde você está simplesmente se concentrando em obter feedback sobre o layout da interface e a fonte, isso proíbe você de adotar uma abordagem de conteúdo em primeiro lugar com seus designs.

“O uso de conteúdo fictício ou informações falsas no processo de web design pode resultar em produtos com suposições irreais e falhas de design potencialmente graves.”

Luke Wroblewski, em Morte ao Lorem Ipsum

Claro, usar o lorem ipsum como texto de espaço reservado em seus designs pode ser conveniente, mas você provavelmente terá que executar várias iterações de design para obter feedback valioso de clientes e usuários.

Vamos analisar algumas das principais razões pelas quais você não deve usar tal texto em latim em seus designs de interface do usuário:

• Não adequado para protótipos de alta fidelidade: O texto Lorem ipsum não é ideal para protótipos de alta fidelidade que podem ser apresentados a clientes, partes interessadas ou usuários finais para revisão e feedback.
• Você não consegue se concentrar no layout: Os designers costumam argumentar que o uso de lorem ipsum permite que eles se concentrem no layout. Essa abordagem é contra-intuitiva porque você provavelmente terminará com um design irreal. É melhor construir seu layout em torno do seu conteúdo, e não o contrário.
• Problemas nos espaçamentos: Muitas vezes, você acabará com layouts de design que não conseguem abrigar o conteúdo real da mesma maneira. Você provavelmente terá que fazer muitos redesenhos e reestruturações no futuro.
• Dificulta os testes de usabilidade: É quase impossível executar testes de usabilidade bem-sucedidos que fornecerão resultados úteis se você estiver usando o texto lorem ipsum em seus protótipos.

Usar conteúdo realista em seus designs de UI/UX sem dúvida exigirá mais esforço no início, mas valerá a pena melhor do que usar lorem ipsum.

Por que o conteúdo real é melhor

Ao usar conteúdo realista em seus designs de UI/UX desde o início, você poderá fornecer designs melhores em um número ideal de iterações de design.

Então, em vez de projetar com o conteúdo com texto fictício primeiro para obter feedback sobre o layout e depois ter que alterar esse layout porque não combinava com conteúdo real, você pode começar com conteúdo real.

Adote uma abordagem que priorize o conteúdo.

Adotar uma abordagem que prioriza o conteúdo ajudará você a criar designs utilizáveis mais rapidamente. Por quê? Porque o conteúdo realista fornece contexto e permite que você construa um design coeso.

O conteúdo evoca emoção que leva a um bom design. Mas ao usar o texto lorem ipsum, você terá um design que parecerá desconectado quando substituir o conteúdo de preenchimento por conteúdo real.

Adotar uma abordagem que prioriza o conteúdo não significa que você deva finalizar o conteúdo antes de começar o design. Significa simplesmente que você deve ter o conteúdo pensado – a abordagem de conteúdo em primeiro lugar é um processo evolutivo. Um primeiro rascunho dará à sua equipe de design uma ideia da mensagem que eles precisam comunicar.

Obtenha feedback valioso de clientes e partes interessadas.

Obter feedback valioso de clientes e usuários finais ajuda você a criar produtos utilizáveis ​​e a entender como oferecer melhores experiências ao usuário.

Com texto lorem ipsum, os clientes e usuários finais não conseguirão ver muito além do layout do design. Lembre-se de que a experiência que seus clientes terão ao ver um protótipo com texto lorem ipsum será, na maioria dos casos, significativamente diferente da experiência ao ver um protótipo com conteúdo real.

Protótipos e maquetes baseados em lorem ipsum geralmente são menos propensos a alterações do que aqueles que apresentam conteúdo real. Isso ocorre porque, como mencionamos anteriormente, o conteúdo evoca emoções que o lorem ipsum simplesmente não consegue.

Melhores resultados nos testes de usabilidade.

Os testes de usabilidade são essenciais para o desenvolvimento de produtos centrados no usuário. Utilizar conteúdo real em seus designs de UI/UX e cenários de tarefas ajuda a obter feedback valioso dos participantes dos testes.

Interfaces de usuário com layouts simples e conteúdo realista fornecerão resultados mais úteis em estudos de usabilidade do que layouts bem elaborados com texto genérico (lorem ipsum).

Projetando sem lorem ipsum

Embora projetar sem lorem ipsum certamente leve mais tempo e exija mais esforço tanto da sua parte quanto da do seu cliente, definitivamente vale a pena a longo prazo. Veja como você pode eliminar efetivamente a necessidade de usar lorem ipsum no seu processo de design:

Passo 1: Obtenha conteúdo e exemplos reais.

Antes de começar a projetar, peça aos clientes o conteúdo que você precisará adicionar à interface do projeto. Isso ajudará você a ter uma ideia do tipo de conteúdo que o cliente gostaria de ver no aplicativo e permitirá que você adote uma abordagem de design que priorize o conteúdo.

Por exemplo, se você estiver projetando um aplicativo de pedidos de comida, poderá pedir ao seu cliente que forneça alguns exemplos de nomes de restaurantes, textos, chamadas para ação, endereços, mensagens de erro, etc.

Dessa forma, você garante que não precisará redesenhar ou reestruturar drasticamente o layout da interface ao passar das maquetes para os protótipos e, finalmente, para o produto final. Além disso, você terá a certeza de que os dados que seu cliente deseja visualizar se encaixarão perfeitamente no layout da interface, sem sobreposições.

Ferramentas como o Content Snare  facilitam aos designers solicitar conteúdo aos clientes, criando pedidos  e especificando prazos.

Passo 2: Mantenha a consistência nos fluxos de usuário

Após receber os dados de amostra dos seus clientes, você precisará garantir que está usando o mesmo conjunto de dados em toda a sua aplicação. Seguindo o exemplo do nosso site de pedidos de comida, se você usou o nome de um restaurante na tela “Escolher um Restaurante” , use também  um dos mesmos nomes de restaurante na tela de “Finalizar Compra” .

Fazendo isso, você consegue manter a consistência e criar fluxos de usuário coesos . Além disso, você poderá coletar feedbacks melhores e mais úteis em testes de usabilidade quando chegar a hora.

Passo 3: Teste todos os cenários possíveis e casos extremos.

Como designer, você deve identificar e testar todos os cenários e casos extremos possíveis sempre que possível. Para facilitar isso, peça aos clientes o máximo de dados de exemplo possível para que você possa fazer um brainstorming de todos os cenários possíveis.

Por exemplo, se o cliente lhe fornecer uma lista de nomes de restaurantes (com o nome mais curto tendo quatro letras e o mais longo tendo 20 letras), você poderá garantir antecipadamente que o layout da sua interface seja capaz de acomodar textos de comprimentos variáveis.

Conclusão

Ao usar texto lorem ipsum em seus protótipos e designs, você está essencialmente relegando o conteúdo a um segundo plano e perdendo a oportunidade de coletar feedback sobre uma representação mais realista do seu projeto.

A menos que seu objetivo seja desenvolver rapidamente vários conceitos de design, usar lorem ipsum é uma perda de tempo, pois você eventualmente terá que substituir o conteúdo de preenchimento por conteúdo real.

Você já precisou refazer grandes alterações de design por causa do uso de lorem ipsum em seus protótipos ou projetos? Conte para nós nos comentários abaixo.

Este artigo foi originalmente publicado em Parem de usar Lorem Ipsum em seus projetos de design

A Fase 4 foca na implementação de suporte nativo e centralizado para sites em múltiplos idiomas diretamente no core (núcleo) do WordPress. O objetivo é eliminar a dependência de plugins de tradução de terceiros que, embora essenciais por anos, frequentemente acrescentam complexidade, sobrecarga de banco de dados e problemas de desempenho.

Note que, como é uma fase que ainda não começou e só começará ao fim da fase 3, ainda temos pouca documentação específica sobre ela, mas conseguimos falar sobre alguns pontos gerais encontrados em posts distintos no Make WordPress

A necessidade da implementação no core

Apesar de o WordPress ser a plataforma mais utilizada no mundo, a criação de um site multilíngue sempre exigiu soluções complexas, como:

• Plugins de terceiros: Ferramentas que traduzem o conteúdo, mas criam camadas de abstração na base de dados, relacionando posts por ID.
• Sobrecarga de Performance: A duplicação de conteúdo e a manipulação de strings de tradução por plugins de terceiros costumam introduzir lentidão e dificultar a manutenção.
• Falta de padrão: Cada plugin gerencia suas traduções de seu próprio jeito, com zero compatibilidade entre eles e outros plugins, além de te forçar a usar tais plugins (e normalmente, suas versões pagas) para todo sempre.

A Fase 4 busca integrar o multilinguismo de forma arquitetônica, garantindo que o recurso seja elegante, rápido e inerente à plataforma, assim como a edição de blocos.

Características e metas da fase 4

A integração nativa do multilinguismo no core não se trata apenas de traduzir textos, mas de gerenciar todo o ecossistema de conteúdo em diferentes idiomas:

1. Suporte de Idiomas à nível de posts: Definir um idioma primário para posts, páginas e até mesmo blocos, e gerenciar as traduções como versões interligadas do mesmo conteúdo.
2. Tradução integrada do editor: Permitir que os usuários criem ou editem traduções diretamente na interface do Editor de Blocos (Gutenberg/FSE), usando o mesmo fluxo de trabalho que utilizam para criar conteúdo original.
3. Configuração simplificada: Eliminar a necessidade de menus complexos e de configurações duplicadas, gerenciando a estrutura de idiomas (como URLs e slugs) de forma coesa.
4. Otimização de Banco de Dados: Desenvolver uma solução que minimize a duplicação de dados, evitando a criação de tabelas e estruturas de banco de dados complexas, garantindo que a funcionalidade não prejudique a performance do site.

O impacto final no ecossistema

Com a implementação da Fase 4, o Projeto Gutenberg atinge seu clímax:

• Usuários: Criar um site multilíngue se torna uma funcionalidade plug-and-play, acessível a qualquer usuário sem conhecimento técnico ou necessidade de investimento em soluções pagas.
• Performance: Ao ser integrado ao core, o suporte multilingue será otimizado para o desempenho, aproveitando a arquitetura moderna do WordPress e dos Temas de Bloco (FSE).
• Desenvolvedores: Embora represente um desafio inicial para os autores de plugins de tradução, o core fornecerá uma API padronizada, permitindo que eles se concentrem em recursos avançados de tradução (como serviços de IA e gerenciamento de glossários) em vez de na infraestrutura básica.

O Projeto Gutenberg é um plano ambicioso de quatro fases que visa reimaginar o WordPress como uma plataforma de publicação e design moderna, completa em todas as frentes: Edição, Customização, Colaboração e, finalmente, Multilinguismo.

Este artigo foi originalmente publicado em Fase 4 do projeto Gutenberg — O futuro multilíngue do WordPress

Com a Fase 1 (Editor de Blocos) e a Fase 2 (Full Site Editing) concluídas, o Projeto Gutenberg iniciou a Fase 3: Colaboração, dedicada à colaboração e aos fluxos de trabalho no WordPress.

O que é a Fase 3

A Fase 3 marca um ponto de virada no Projeto Gutenberg.

Depois de consolidar o editor de blocos (Fase 1) e o editor de sites (Fase 2), o foco agora é permitir que múltiplas pessoas trabalhem juntas dentro do WordPress de maneira fluida e em tempo real.

Em outras palavras, enquanto as fases anteriores reinventaram como criamos, esta transforma como colaboramos.

De acordo com o post oficial (Make WordPress Core — Phase 3: Collaboration, 2023) (link)

Os pilares da Fase 3

A Fase 3 é guiada por quatro pilares principais, cada um representando uma área de evolução na experiência de colaboração.

1. Edição colaborativa em tempo real

Um dos avanços mais esperados é a capacidade de edição simultânea — vários usuários trabalhando no mesmo conteúdo, com sincronização automática. Para isso, o time de desenvolvimento está implementando uma camada de comunicação baseada em CRDTs (Conflict-free Replicated Data Types), a mesma tecnologia usada em ferramentas como o Yjs (yjs.dev)

Isso permitirá que cada editor veja em tempo real quem está modificando o conteúdo e onde, evitando conflitos e perdas de dados.

2. Comentários e anotações no editor

Outro grande foco é o sistema de comentários contextuais dentro do editor de blocos. Com ele, será possível adicionar observações, fazer perguntas e revisar trechos de texto sem sair da interface.

Esses comentários deverão se integrar ao sistema de notificações e menções do WordPress, criando uma comunicação direta entre autores, revisores e administradores.

Essa funcionalidade já está sendo testada no plugin Gutenberg (wordpress.org/plugins/gutenberg) e deve amadurecer ao longo de 2026.

3. Revisões e histórico aprimorados

A Fase 3 também reformula o sistema de revisões de conteúdo, permitindo:

• Comparar visualmente mudanças entre versões.
• Restaurar partes específicas de um post.
• Ver quem alterou o quê e quando.

Esses avanços aproximam o WordPress de um ambiente profissional de redação, adequado para portais de mídia, agências e grandes equipes.

4. Fluxos de trabalho e permissões

Hoje, o WordPress trabalha com papéis fixos (autor, editor, administrador), o que limita fluxos editoriais mais complexos.

Na Fase 3, será possível criar funções personalizadas e configurar etapas de aprovação, como revisão de conteúdo antes da publicação.

Isso tornará o WordPress mais adaptável para ambientes corporativos e multiusuário.

Progresso atual

Segundo os relatórios mais recentes no blog oficial (Make WordPress Core) — (Update on Phase 3, nov/2024)

O impacto da Fase 3 no ecossistema WordPress

A introdução de colaboração em tempo real e fluxos de trabalho avançados representa mais do que uma melhoria técnica — é uma mudança cultural no WordPress.

Com a Fase 3, o CMS se aproxima de ferramentas modernas de trabalho em equipe, mas mantendo o controle total dos dados e da hospedagem.
Isso significa que empresas, portais e equipes podem trabalhar de forma colaborativa sem depender de plataformas proprietárias.

Para comunidades open source e desenvolvedores, essa mudança também abre espaço para novos tipos de plugins — voltados a gestão de equipes, notificações, relatórios editoriais e automações internas.

Conclusão: O Futuro da Coautoria no WordPress

A Fase 3 do Projeto Gutenberg é um dos maiores saltos evolutivos da história do WordPress. É a ponte que levará o WordPress do Full Site Editor a uma ferramenta completa de gestão de conteúdo para empresas e grandes equipes.

Ao se concentrar na Colaboração, a plataforma está não apenas alcançando concorrentes modernos, mas também reafirmando seu compromisso de fornecer uma base robusta e de código aberto para a criação web em qualquer escala.

A conclusão bem-sucedida desta fase garantirá que o WordPress permaneça a espinha dorsal de milhões de sites, oferecendo uma experiência de trabalho em equipe que é tão flexível e poderosa quanto seu novo sistema de blocos.

Este artigo foi originalmente publicado em Fase 3 do projeto Gutenberg — Colaboração e fluxo de trabalho

Com base no recente “Field Guide” publicado por Weston Ruter e nas análises da comunidade, o foco desta versão é refinar como o navegador carrega e prioriza os recursos do seu site. Para desenvolvedores e donos de sites preocupados com o Core Web Vitals, LCP (Largest Contentful Paint) e o TTFB, essas são ótimas notícias.

Vamos mergulhar nas três principais mudanças técnicas que farão seu site voar.

1. Script Modules e a lógica do fetchpriority

Com a adoção da Interactivity API, muitos blocos passaram a depender de script modules. Anteriormente, os scripts de visualização (view scripts) eram impressos no <head> para serem descobertos cedo. O problema? Isso criava uma disputa de rede (network contention) justamente quando o navegador deveria estar baixando elementos essenciais para o LCP (Elementos que carregam antes da dobra do navegador, como uma imagem principal).

No WordPress 6.9, o Core ficou mais inteligente:

• Otimização Padrão: Módulos de script para blocos interativos agora recebem fetchpriority="low" por padrão. O mesmo se aplica ao script clássico de comment-reply.
• Para Desenvolvedores: A API WP_Scripts foi atualizada. Agora, ao registrar ou enfileirar scripts (wp_register_script / wp_enqueue_script), você pode passar a chave fetchpriority no array de argumentos $args.
  • Valores aceitos: auto (padrão), low, e high.

Isso dá aos desenvolvedores controle granular para “despriorizar” scripts secundários sem precisar de hacks ou plugins extras.

2. CSS: carregamento sob demanda e novos limites

A gestão de estilos recebeu três atualizações críticas voltadas para reduzir o bloqueio de renderização:

1. Temas padrão otimizados: Os temas padrão do WordPress (os que já vem com ele, como o Twenty TwentyFive) agora carregam estilos de blocos sob demanda (on demand), em vez de carregar um monolito de CSS no cabeçalho. Se o bloco não estiver na página, o CSS não carrega.
2. Blocos Ocultos: O Core agora omite automaticamente os estilos de blocos que estão ocultos, otimizando ainda mais o carregamento da página.
3. Inline CSS (O Salto de 20KB para 40KB):
   • O limite para CSS inline foi dobrado. Com designs cada vez mais complexos, 20KB era atingido muito rápido. Ao dobrar esse limite, o WordPress consegue embutir mais estilos diretamente na página, reduzindo o “render-blocking” (bloqueio de renderização) e acelerando o FCP (First Contentful Paint).
   • O Impacto Real: Segundo os testes do Weston Ruter em conexões 4G, essa mudança sozinha reduziu a métrica LCP-TTFB em visitas não cacheadas de 655,7 ms para 449,9 ms. Isso representa uma melhoria impressionante de ~31% na velocidade de percepção visual para novos visitantes.

3. A nova arquitetura de “Output Buffering”

Esta é a mudança mais técnica e estrutural.

Historicamente, plugins que precisavam processar o HTML final (como otimizadores de imagem ou plugins de cache) criavam seus próprios buffers de saída, o que frequentemente causava conflitos.

O WordPress 6.9 padroniza isso com o Template Enhancement Output Buffer.

Novos Hooks:

• wp_before_include_template: Disparado imediatamente antes do template ser incluído.
• wp_start_template_enhancement_output_buffer(): Inicia o buffer de forma controlada.

Por que isso é importante? Isso cria um caminho oficial para processar o HTML completo antes do envio ao navegador.

Desenvolvedores podem usar filtros para injetar headers Server-Timing, remover CSS não utilizado (tree-shaking no servidor) ou realizar outras otimizações complexas de forma segura e compatível com o Core.

Como exemplo de filtragem do buffer de saída, o código a seguir garante que as cinco primeiras tags IMG na resposta não sejam carregadas com lazyload, enquanto as tags IMG restantes são carregadas com lazyload:

add_filter(
	'wp_template_enhancement_output_buffer',
	function ( $buffer ) {
		$processor = new WP_HTML_Tag_Processor( $buffer );
		$img_index = 0;
		while ( $processor->next_tag( 'IMG' ) ) {
			if ( $img_index < 5 ) {
				$processor->remove_attribute( 'loading' );
			} else {
				$processor->set_attribute( 'loading', 'lazy' );
			}
			$img_index++;
		}
		return $processor->get_updated_html();
	}
);

Conclusão

O WordPress 6.9 não está apenas “mais rápido”; ele está mais eficiente na gestão de recursos. Para nós, desenvolvedores, o suporte nativo a fetchpriority e o novo output buffer significam menos dependência de “gambiarras” para atingir pontuações altas no PageSpeed.

As melhorias de CSS, especialmente o carregamento sob demanda em temas clássicos, mostram que o Core continua preocupado em modernizar a base legada enquanto avança com o Full Site Editing.

Para se aprofundar nos detalhes técnicos, recomendo a leitura do Field Guide oficial do Weston Ruter e esta excelente análise do The Repository.

Este artigo foi originalmente publicado em WordPress 6.9: Melhorias de performance no front-end

Após a turbulentíssima, mas fundamental, Fase 1 (o Editor de Blocos), o Projeto Gutenberg avançou para a Fase 2: Personalização e edição do site. Esta fase foi a concretização da visão de longo prazo de Matt Mullenweg: estender o poder do sistema de blocos a toda a experiência de construção do site.

Lançada progressivamente e consolidada no WordPress 5.9 (Janeiro de 2022), a Fase 2 introduziu o Full Site Editing (FSE) – a Edição Completa do Site. O objetivo era claro: eliminar a necessidade de código em PHP e de navegadores complexos (como o Customizer e os menus de Widgets) para controlar o design de elementos globais de um site.

Se a ideia da Fase 1 ensinou os usuários a editar o conteúdo com blocos, a da Fase 2 era ensinar a construir o esqueleto do site com eles.

A Transição: Saindo do “post_content”

A grande limitação da Fase 1 era que os blocos estavam confinados à área de conteúdo (post_content) de posts e páginas. Para editar o cabeçalho, rodapé, barra lateral ou navegação, o usuário ainda dependia de códigos, widgets e da interface do Customizer/Personalizar… ou até mesmo de plugins externos (os famosos page builders).

A Fase 2 superou essa barreira, buscando resolver três focos principais, conforme delineado no roteiro original:

• Atualizar temas, widgets e menus: integrar esses sistemas legados ao novo paradigma de blocos.
• Estar fora do post_content: levar a edição para elementos globais.
• Foco na Personalização: dar ao usuário controle total sobre o layout e o estilo.

1. O Editor de Site Unificado (Site Editor)

O FSE substituiu o antigo Customizer e as telas tradicionais de Menus e Widgets por uma interface unificada acessível via Aparência > Editor (vale lembrar que isso acontecerá apenas para temas prontos/compatíveis com o FSE, temas “antigos” continuarão tendo o Customizer disponível).

A ideia era trazer todos os elementos globais (cabeçalho, rodapé, barra lateral) para a mesma interface visual do editor de posts, permitindo a edição e pré-visualização dos blocos no contexto do site.

2. Estilos Globais (Global Styles)

Esta é uma das ferramentas mais poderosas do FSE. Os Estilos Globais permitem que o usuário defina as características de design – fontes, cores, espaçamento e layout – para o site inteiro, tudo a partir de uma única interface.

A definição de estilos globais passa a ser definida em um arquivo no arquivo theme.json, que fica na pasta do seu tema. Este arquivo de configuração permite que desenvolvedores de temas definam paletas de cores, tamanhos de fonte e configurações de layout padrão para todo o site, garantindo consistência e simplificando o processo de design para o usuário final.

Os Novos Pilares da Construção de Sites

A Fase 2 exigiu novas ferramentas e uma mudança completa na arquitetura de temas:

Temas de Bloco (Block Themes)

Para utilizar o FSE, surgiu um novo tipo de tema.

Ao contrário dos temas clássicos que dependiam da criação de arquivos PHP (complexos para muitas pessoas), os Temas de Bloco são construídos exclusivamente com blocos, usando arquivos HTML para definir templates (modelos) e template parts (partes do modelo, como cabeçalho e rodapé).

Edição de Templates

O FSE deu aos usuários o poder de criar e modificar os modelos de páginas (template parts). Isso significa que, sem escrever código, é possível:

• Criar um modelo de página de arquivo (lista de posts).
• Projetar um modelo de página 404 ou página única.
• Reutilizar partes de modelo (como rodapés) em vários templates.

Blocos Dinâmicos e o Query Block

Para substituir as funcionalidades de temas e widgets que tradicionalmente dependiam de código PHP, o FSE introduziu uma série de blocos dinâmicos que carregam informações do banco de dados em tempo real. O bloco Navegação, por exemplo, assume a função da antiga tela de Aparência > Menus, permitindo que os usuários construam e editem seus menus diretamente na visualização do site. Da mesma forma, blocos como Título do Site e Logo do Site substituem configurações que antes eram acessadas apenas através do Customizer ou em arquivos de tema.

O bloco mais poderoso nessa categoria é o Query Block. Ele é a solução da Fase 2 para exibir listas de posts, páginas ou tipos de posts personalizados. Essencialmente, o Query Block permite que o usuário crie layouts complexos para páginas de blog, arquivos e resultados de busca, incluindo filtragem e ordenação, sem a necessidade de escrever uma única query de banco de dados ou código PHP dentro do tema. Ele é o elemento que dá ao usuário o controle total sobre o conteúdo dinâmico do site.

Impacto e Legado

A Fase 2 marcou o momento em que o WordPress se tornou um competidor direto e open source dos Page Builders proprietários.

O maior ganho foi a consistência e a simplificação, aplicando o conceito de blocos de ponta a ponta, o que reduziu significativamente o “ponto de dor” de ter de ir e vir entre interfaces desconectadas. Ao unificar a experiência de edição e design em um único lugar, o FSE proporcionou ao usuário controle sem código sobre o layout completo do site.

Para os desenvolvedores, o paradigma mudou: o foco do trabalho pode migrar da escrita de código PHP complexo para a criação de blocos reutilizáveis e a configuração do arquivo theme.json, tornando a construção de temas mais orientada a componentes. Além disso, a nova arquitetura dos Temas de Blocos, ao carregar apenas o CSS necessário para os blocos presentes na página, tende a gerar códigos mais limpos e aprimorar a velocidade de carregamento, resultando em ganhos notáveis de performance.

Notas do Editor

O FSE realmente é algo que te dá mais possibilidades para criar um site sem depender tanto de plugins de page builders, como o Elementor. Entretanto, isso exigirá que você aprenda uma nova forma de criar suas páginas, e isso pode acabar lhe fazendo criar comparações descabidas.

Comparar um plugin comercial com mais de uma dezenas de anos com um editor nativo feito essencialmente por voluntários (e alguns profissionais pagos por empresas de terceiros para dedicar seu tempo para a comunidade), acaba por criar uma comparação desproporcional, sobretudo quando se pensa que a evolução de ferramentas open source depende também do feedback de seus usuários (e falar apenas o Elementor é melhor não é um feedback que aponte as melhorias necessárias).

Recentemente, tive a oportunidade de coordenar a criação do site do WordCamp Brasil 2025 e todos os sites de WordCamps (as conferências oficiais do WordPress, das quais tenho o prazer de ser organizador principal pela terceira vez e de ajudar o quinto WordCamp em terras cariocas a acontecer) são feitos totalmente com o editor de blocos, com o tema padrão do WordPress (Twenty TwentyFive) e sem instalar nenhum plugin adicional.

Para algumas coisas, precisamos entender a melhor forma de fazer e tivemos um aprendizado válido com a experiência, vendo que realmente dá para criar diversos tipos de sites assim.

Como exemplo, destaco aqui uma pequena lista de belos sites de WordCamps criados:

• WordCamp Ahmedabad 2023 (na India);
• WordCamp Madrid 2023 (Espanha);
• WordCamp Gdynia 2025 (Polônia).

Note, então, que, nos dias de hoje, muitas pessoas ainda não aprenderam a usar o FSE; entretanto, já é possível criar sites bem funcionais com ele, usando o próprio tema padrão que vem com o WordPress , eliminando, assim, a necessidade de buscar outros temas. Entretanto, outros temas, como o Kadence e seu plugin Kadence Blocks, adicionam ainda mais funcionalidades interessantes.

O Próximo Passo: Fase 3 – Colaboração

Com a Fase 2 integrada ao núcleo do WordPress, o projeto Gutenberg avançou para a Fase 3: Colaboração, cujo objetivo é transformar o WordPress em uma ferramenta de trabalho em equipe robusta, adicionando funcionalidades de coautoria e edição multiusuário em tempo real.

Este artigo foi originalmente publicado em Fase 2 do projeto Gutenberg: Full Site Editing

Uma atualização malfeita ou um plugin com uma falha de segurança pode causar desde uma simples “tela branca da morte” até um desastre completo de segurança.

A boa notícia? O WordPress.org acaba de implementar uma nova camada de proteção automática que defende seu site antes que esses plugins problemáticos cheguem até você.

A equipe de plugins do WordPress, em colaboração com as equipes de Performance e Meta, anunciou uma nova funcionalidade crucial: o Plugin Check Plugin (PCP) agora gera relatórios de segurança automáticos sempre que um plugin é atualizado.

O “Plugin Check Plugin” é uma ferramenta que executa uma série de verificações no código do plugin e, em seguida, gera um relatório detalhado. Este relatório permite que os desenvolvedores identifiquem e apliquem as medidas de segurança adequadas, melhorando a qualidade geral do plugin.

Mais detalhes dessa novidade

Anteriormente, o Plugin Check já era uma ferramenta disponível para que os desenvolvedores analisassem seus plugins. Desde 17 de setembro de 2025, já havia uma detecção automatizada de requisitos mínimos realizada por tal plugin. No entanto, a novidade é que, em 27 de outubro de 2025, essa verificação tornou-se automática e integrada diretamente ao repositório do WordPress.org (e foi divulgada neste post no Make, site oficial do WordPress.org).

Essa detecção automática será aplicada a todas as atualizações de plugins, tanto os novos quanto os já existentes e aprovados no repositório. O sistema foi implementado para identificar problemas relacionados não apenas à segurança, mas também à compatibilidade e conformidade com as diretrizes da plataforma.

O objetivo principal desta iniciativa é, claro: elevar o padrão de segurança de todo o ecossistema de plugins do WordPress.

Ao fornecer feedback proativo e automatizado, a equipe do WordPress espera promover e manter boas práticas de desenvolvimento entre todos os autores de plugins, que receberão esses relatórios de segurança por e-mail assim que enviarem uma atualização, o que os incentiva a manter seus plugins sempre seguros e eficientes.

Mesmo que você não seja um desenvolvedor, esta é uma das atualizações de infraestrutura mais importantes dos últimos tempos para a sua tranquilidade.

Destaco os seguintes pontos:

• Segurança proativa, não reativa: Antes, muitas falhas de segurança só eram descobertas depois de serem exploradas em sites reais (talvez o seu!). Agora, a ferramenta identifica problemas de segurança comuns e alerta o desenvolvedor para corrigi-los antes que a atualização seja liberada no seu painel.
• Menos “Quebras” após atualizar: O pesadelo de clicar em “atualizar” e ver o site sair do ar diminui. A verificação não olha apenas para a segurança, mas também para a compatibilidade e a conformidade. Isso força os desenvolvedores a seguir as melhores práticas, o que resulta em plugins mais estáveis e que “conversam” melhor entre si.
• Um ecossistema mais confiável: Ao automatizar essa verificação, o WordPress está elevando o padrão de qualidade de todos os plugins no repositório. Isso significa que, ao navegar pela loja de plugins, você tem uma garantia extra de que o que está ali passou por um filtro de qualidade mais rigoroso.

Para você, dono de um site WordPress, a mensagem é simples: o ecossistema que você usa para o seu negócio ou projeto pessoal ficou significativamente mais robusto e seguro.

Mas vale lembrar, sempre, das boas práticas em projetos de desenvolvimento: Site em produção (ou seja, o seu site no ar) não é um ambiente para testes, por isso cobre que seus desenvolvedores tenham um ambiente de testes para testar atualização de plugins antes de as aplicar diretamente em um site que está no ar e pode ter problemas com uma atualização que cause problemas ou incompatibilidade entre plugins.

Este artigo foi originalmente publicado em Equipe do WordPress.org automatiza Relatórios de Segurança para plugins