WordPress Podcast (português)

Durante uma década, o programa do WordPress na HackerOne recebeu entre 20 e 30 relatórios por mês; este ano, já ultrapassou os 3000, mais do que nos doze anos anteriores juntos.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras a informação de 26 de outubro a 1 de novembro de 2026.

Dois meses depois do lançamento da Core Security Initiative, a equipa de segurança faz um balanço com números que ajudam a perceber por que razão temos visto tantas correções seguidas. Durante uma década, o programa do WordPress na HackerOne recebeu entre 20 e 30 relatórios por mês; em julho, recebeu 450, em agosto, 773, e este ano já ultrapassou os 3000, mais do que nos doze anos anteriores juntos.

Grande parte destes resultados vem de investigação acelerada por ferramentas de IA, o que torna o WordPress mais seguro, mas obriga a acelerar tudo o que se segue:

É por isso que houve quatro versões de segurança em 41 dias, da 7.1.1 à 7.1.4, e sete desde meados de julho, com mais de 50 vulnerabilidades críticas ou de gravidade elevada corrigidas. Todas as correções foram aplicadas a todos os ramos de versões com suporte, até à 4.7.

Cada lançamento tem uma equipa fixa de pessoas de confiança, com funções bem definidas, e é disponibilizado em duas fases, para proteger primeiro as versões mais utilizadas. As tarefas mais demoradas estão a ser automatizadas: a adaptação das correções a versões anteriores, que chegava a ser feita manualmente em 25 ramos, faz parte de um processo em que 73% dos 109 passos de um lançamento de segurança estão agora automatizados, com ferramentas abertas.

Algumas restrições são mantidas de propósito, como limitar a um pequeno grupo a possibilidade de preparar os pacotes de lançamento, para prevenir ataques à cadeia de fornecimento de software.

Este ano, foram encerrados quase 3000 relatórios, e a fila dos que aguardavam triagem passou de 359 para menos de uma centena. A equipa reorientou as suas ferramentas para encontrar vulnerabilidades no núcleo do WordPress antes de serem comunicadas, recorrendo a modelos com pesos abertos e a ambientes de teste personalizados.

O WordPress aderiu também ao OSS Scanner da Anthropic, que oferece análises gratuitas a projetos de código aberto. Os primeiros resultados já estão a ser analisados, e a Anthropic já aparece nos agradecimentos dos anúncios de lançamento.

O WordPress 7.1.4 é a quarta versão de segurança em 41 dias, a mesma que foi referida no balanço da Core Security Initiative, e traz uma longa lista de correções.

A mais grave é uma falha no processo de atualização que poderia permitir a execução remota de código durante o período em que uma atualização está a ser aplicada. As restantes são, sobretudo, vulnerabilidades de XSS persistente:

Há ainda várias na Interactivity API, além de uma vulnerabilidade de negação de serviço persistente nessa mesma API. Foram também corrigidas duas falhas de acesso:

Os certificados raiz incluídos no WordPress foram igualmente atualizados.

Como sempre, atualiza de imediato. As correções foram adaptadas às versões anteriores, até à 4.7, e esta é uma versão de ciclo curto: a próxima versão principal continua a ser a 7.2, prevista para 8 de dezembro. O anúncio não apresenta identificadores CVE nem números totais, e a página do HelpHub fornece mais pormenores.

Entretanto, a versão 7.2 continua a avançar: à Beta 2 já seguiu uma Beta 3, com todas as correções da 7.1.4 que lhe são aplicáveis. A segunda beta continua a aperfeiçoar a versão, sem alterações ao calendário nem grandes novidades:

O Feature Notifications, o projeto que pretende dotar o WordPress de um sistema unificado de notificações, já tem uma proposta de design que mostra como poderá funcionar, testada com todas as mensagens atualmente apresentadas pelo WooCommerce e pelo WooPayments, e uma demonstração interativa.

A ideia é ter um único sino de notificações para o site, disponível em toda a área de administração, dentro do editor e na parte pública do site, em vez de aparecer apenas em alguns ecrãs, como acontece com os avisos atuais. Ao abrir cada notificação, é possível perceber o assunto, quem a envia e qual o próximo passo. Os problemas que precisam de resolução mantêm-se no topo até serem resolvidos.

A segunda versão do protótipo centra-se nas regras que garantem uma apresentação e um funcionamento consistentes, independentemente de quem envia as notificações. Os plugins enviam dados, não definem o design, e escolhem entre quatro formatos. Cada notificação é caracterizada segundo cinco dimensões, entre as quais o tipo, a gravidade e o estado de leitura, cujos valores são definidos pelo núcleo do WordPress. Os avisos críticos são raros e bem visíveis: tornam o contador vermelho até serem resolvidos, não apenas até serem lidos. Há um separador de alertas e regras para evitar o excesso de notificações, como substituir ou agrupar mensagens repetidas e permitir desativar, de uma só vez, as sugestões e as ofertas.

A equipa de IA do WordPress publicou uma proposta para permitir que qualquer pessoa gira o seu site com o agente de IA que preferir, sem ter de integrar um assistente no WordPress.

Milhões de pessoas já usam agentes para pesquisar, fazer compras ou gerir negócios, e vários produtos, plugins e ferramentas demonstraram que existe procura por esta forma de gerir sites. Abres o agente, pedes ajuda com o teu site, o agente identifica o WordPress e dá-te um link para autorizares o acesso, inicias sessão e está feito.

Atualmente, isso exige instalar e configurar o adaptador MCP, disponibilizar as funcionalidades adequadas e gerir a autenticação com palavras-passe de aplicação, com o risco de acabares por as colar em texto simples no agente, o que não é o ideal.

A abordagem tem quatro frentes coordenadas, aproveitando o ciclo do WordPress 7.2 para estabelecer as bases e apontando à versão 7.3 para a integração no núcleo.

A equipa de Comunidade reconheceu um problema de privacidade nas páginas dos bilhetes dos eventos: entre 20 de maio de 2025 e 28 de outubro de 2026, algumas pessoas que tinham escolhido não aparecer na lista pública de participantes acabaram por aparecer.

A página de edição do bilhete mostrava “Sim” na pergunta sobre a inclusão na lista, mesmo quando a resposta tinha sido “Não”. Ao guardar a página, por exemplo para alterar um nome, a resposta passava para “Sim”. Foram apresentados nomes e Gravatars e, em alguns eventos, links para sites ou perfis de redes sociais e informações como a empresa ou o cargo. Segundo a análise realizada, não foram expostos endereços de email, números de telefone, moradas ou respostas sobre alimentação ou acessibilidade. Foram afetados cerca de 1280 bilhetes de 168 eventos, com o WordCamp Asia 2026, o WordCamp Europe 2026 e o WordCamp Dhaka 2025 a registarem os maiores números.

Como a resposta anterior não ficava registada, a equipa ocultou da lista todas as pessoas que poderiam ter sido afetadas, correspondentes a cerca de 8580 bilhetes, incluindo algumas que tinham efetivamente escolhido aparecer. O erro foi corrigido no próprio dia em que foi detetado. Será enviado um email aos organizadores e aos participantes de eventos futuros. Quem quiser voltar a aparecer na lista deve abrir o link no email do bilhete, selecionar “Sim” e guardar. Para questões relacionadas com dados pessoais, o contacto é [email protected].

Há também uma novidade mais agradável para quem organiza eventos: o CampTix passa a permitir o registo de entrada com códigos QR e a inclusão destes códigos nas credenciais. Cada participante recebe o seu próprio código, tanto no email como na página do bilhete. À entrada, o voluntário abre o endereço secreto num telemóvel, lê o código, confirma com “Sim” e a linha passa a verde. O leitor avisa se o bilhete foi reembolsado ou cancelado, se está pendente ou se já foi utilizado para registar a entrada. Se um código tiver sido partilhado, é possível emitir outro, invalidando o anterior.

A próxima versão do bbPress é, mais uma vez, dedicada à segurança e à manutenção. A versão 2.6.21 reforça o controlo de acesso nos feeds dos fóruns, nos resultados de pesquisa, na atividade do BuddyPress, nos fóruns de grupos, nos pedidos de acesso a anexos, na movimentação de tópicos e nos redirecionamentos de tópicos e respostas antigos. As palavras-passe dos fóruns herdadas de versões anteriores passam a ser aplicadas de forma consistente quando o WordPress apresenta o conteúdo de tópicos e respostas, e os pedidos de moderação enviados ao Akismet têm de usar HTTPS.

Na manutenção, foram melhoradas as consultas que determinam a atividade mais recente dos fóruns e a contagem de elementos subordinados. Os metadados são preservados quando uma consulta à base de dados falha, e as datas originais e o conteúdo das revisões são mantidos durante a moderação e a edição. São também corrigidos elementos de lista simples sem uma lista envolvente no WordPress 6.9 e posteriores, os excertos gerados são preservados sem duplicar conteúdo, é adicionada a relação ugc aos links de tópicos e respostas, e os ícones da administração são atualizados para o WordPress 7.2 e posteriores, acompanhando a transição de Dashicons para SVG.

A organização do WordPress Day for AI Faro 2026 publicou, na última semana, o artigo de encerramento do evento, fazendo o balanço bastante positivo e revelando as ligações para os vídeos das apresentações e as fotos oficiais.

Por fim, este podcast é distribuído sob uma licença Creative Commons, como uma versão derivada do podcast em espanhol. Encontras todos os links para mais informações, bem como o podcast noutros idiomas, em WPpodcast .org.

Obrigada por ouvires e até ao próximo episódio.

A equipa do WordPress Photos criou o PhotoFetch, um plugin que permite pesquisar fotografias livres de direitos e adicioná-las ao teu site de forma rápida e simples.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras a informação de 19 a 25 de outubro de 2026.

O WordPress 7.2 já está em testes: a Beta 1 foi lançada a 20 de outubro e, como sempre, destina-se apenas a ambientes de teste, nunca a sites em produção.

A data de lançamento prevista é 8 de dezembro, a que consta do anúncio e do calendário das sessões de lançamento. O guia da equipa de Testes indica o dia 9, uma discrepância a ter em conta. É a última versão principal de 2026 e chega com o novo tema por omissão, Ipsum.

Para quem edita conteúdos, a mudança mais visível é um conjunto de melhorias no editor. Os estilos responsivos introduzidos na versão 7.1 são alargados, sobretudo na Galeria, onde poderás definir as colunas, o recorte e a proporção das imagens por tipo de ecrã.

Os Estilos Globais recebem um filtro «Personalizado» para mostrar apenas os blocos com estilos modificados. Depois de ter sido adiada na versão 7.1, regressa também a apresentação dos valores herdados nos controlos do inspetor de blocos. São acrescentadas sombras de texto com controlos próprios, bem como a possibilidade de aplicar estilos aos elementos de formulário sem mexer no código.

As Notas ganham reações com emojis, um ícone próprio na barra de ferramentas e um modo minimizado, e passam para a margem da área de edição, para poderem permanecer abertas ao lado da barra de definições dos blocos. Há ainda gestão de ligações de navegação a partir da barra lateral do Editor do Site, mensagens de erro mais claras e um inspetor de artigos reconstruído com o sistema DataForm.

Na área multimédia e na administração, há várias alterações úteis:

O painel estreia o widget «Neste dia», substitui os Dashicons da barra de administração e dos menus por ícones SVG e acrescenta uma opção para desativar a reordenação das caixas de metadados, pensada para dispositivos com ecrã tátil.

Para quem trabalha com alojamento, há uma alteração de desempenho que merece atenção: o WordPress deixa de combinar scripts e folhas de estilo em ficheiros grandes, passando a carregá-los separadamente para tirar melhor partido da cache do navegador, e pré-carrega o ecrã de administração com maior probabilidade de ser visitado a seguir.

Para quem desenvolve, a grande novidade é a Secrets API, uma forma normalizada de guardar chaves de API e tokens com encriptação, rotação de credenciais e fornecedores de armazenamento personalizáveis, com suporte para WP-CLI e verificações no Diagnóstico do Site, baseada na proposta das últimas semanas. Chegam também redirecionamentos para conteúdos aleatórios, novas capacidades na Abilities API, a diretiva data-wp-html da Interactivity API e um reforço adicional da robustez da HTML API. A equipa de Testes pede ajuda através de um guia detalhado que explica o que testar em cada funcionalidade. Quem encontrar erros pode comunicá-los nos fóruns, no Trac ou no repositório do Gutenberg, indicando as versões do WordPress e do PHP, o tema, os plugins e os passos para reproduzir o problema.

A tecnologia por trás do WordPress Playground já executa outro sistema de gestão de conteúdos no navegador. Herman Peeren, colaborador do Joomla, criou o Joomla Playground, um projeto da comunidade ainda numa fase inicial que abre o Joomla num separador, com a área de administração e o site público, sem um servidor PHP ou uma base de dados locais.

Assenta em duas peças do ecossistema WordPress: os pacotes wasm, que executam PHP como WebAssembly no navegador, e mysql-on-sqlite, a biblioteca que permite executar consultas MySQL em SQLite, à qual ligou um adaptador específico para Joomla. Funciona em navegadores baseados em Chromium, documenta a utilização do Joomla 6.2 e 5.4 com PHP 8.3 a 8.5 e permite guardar o site no navegador, importar e exportar ficheiros ZIP e inspecionar mensagens de correio eletrónico sem as enviar.

O que interessa ao WordPress é o contributo que o Joomla devolve, porque esta utilização revela situações que o WordPress, por si só, não põe à prova. Na compatibilidade SQL, por exemplo, os identificadores de sessão guardados como valores binários não correspondiam às comparações de texto usadas pelo Joomla e impediam o início de sessão, um caso que poderá dar origem a um teste de regressão para a biblioteca partilhada. Guardar milhares de ficheiros soltos no armazenamento do navegador era lento, por isso Peeren passou a usar um ZIP de base partilhado, juntamente com uma cópia do estado dos ficheiros modificados, recorrendo ao registo de alterações do sistema de ficheiros do Playground. Segundo as suas medições, o tempo necessário para guardar passou de 13 segundos para cerca de 0,3. Além disso, como havia um único processo PHP partilhado, uma ligação de rede interrompida bloqueava os pedidos seguintes durante minutos, e a indexação de pesquisa em segundo plano passava à frente da navegação. Ativar o acesso à rede através do fetch do navegador e dividir a indexação em blocos, para ceder a vez a outras tarefas, reduziu para cerca de metade o tempo até ser possível utilizar a demonstração.

O WordPress Contributor Toolkit, a aplicação para computador que permite contribuir para o Core e o Gutenberg, chega à versão 2.0 com uma interface redesenhada e traduzida para dez idiomas. Os fluxos de trabalho do Core e do Gutenberg que vimos na versão anterior mantêm-se. Toda a janela é construída com o sistema de design do WordPress, pelo que os botões, avisos e caixas de diálogo serão familiares a quem usa o editor de blocos. A lista de sites passa também a mostrar o estado do servidor de cada site. Há ainda uma caixa de diálogo de definições com três grupos — geral, sites e conta —, com temas claro, escuro, do sistema ou personalizados a partir de uma cor de fundo e de uma cor principal, e opções como a versão de PHP de cada site ou a possibilidade de voltar a iniciar o que estava em execução quando fechaste a aplicação.

A outra grande mudança é o idioma. Todas as cadeias de texto da interface podem ser traduzidas em translate.wordpress.org, e a versão 2.0 inclui checo, neerlandês, inglês do Canadá e do Reino Unido, galego, húngaro, laociano, polaco, sérvio e turco. Um idioma entra na aplicação quando atinge pelo menos 80% de tradução, pelo que a lista irá crescer a cada versão. A própria equipa sugere a tradução como uma primeira contribuição. Por omissão, a aplicação segue o idioma do sistema operativo.

Há também melhorias pensadas para a utilização prática durante os Dias de Contribuição. Depois de aplicares um patch ou um pull request, os detalhes do site mostram os ficheiros alterados numa estrutura em árvore, distinguindo os que pertencem ao patch dos que alteraste, com um botão para reverter apenas um sem perderes o que estás a testar. Os dados lidos do Trac, como o resumo, o estado ou o componente, mantêm-se quando fechas e voltas a abrir a aplicação, e há um botão para os atualizar. A instalação ocupa ainda menos cerca de 350 MB, o que faz diferença quando todos descarregam a aplicação ao mesmo tempo na mesma rede.

Emre Erkan, gestor de localização da equipa turca, mediu quantas pessoas com funções de gestão nos Polyglots continuam ativas, e o resultado é bastante desanimador. Analisou os perfis públicos das 870 pessoas que são gestoras de localização ou editoras gerais de tradução nas 203 variantes linguísticas. Apenas 31% traduziram alguma coisa nos últimos 90 dias, 15% fizeram-no entre há três meses e um ano, 36% há mais de um ano e 17% não têm atividade registada desde meados de 2022. Numa análise por variante linguística, em 95 delas, quase metade, nenhum gestor ou editor geral esteve ativo no último trimestre, e em 74 nem sequer no último ano. Isto importa porque são estas pessoas que abrem a porta às restantes: sem elas, ninguém atribui a função de editor de tradução de projeto, e quem fica à espera acaba por sair em silêncio. O processo previsto no manual para variantes linguísticas inativas só é acionado quando uma tradução está duas versões principais atrasada. Por isso, uma variante pode parecer atualizada graças a duas ou três pessoas, enquanto quase todos os seus gestores estão ausentes há anos.

Nos comentários, Emre acrescentou uma segunda análise dos pedidos de atribuição de funções de editor publicados desde 2022: 4601 publicações e 6640 pedidos contabilizados por variante linguística. Metade recebeu resposta de um gestor ou editor da mesma variante, com uma mediana de nove horas, mas 39% nunca receberam resposta da respetiva equipa. Em 1901 desses casos, a única pessoa que tratou do pedido foi Tor-Björn Fjellner. O mais marcante é o ritmo: entre janeiro e outubro de 2026 já havia 2821 pedidos, 2,4 vezes o total de todo o ano de 2025, o que se relaciona com a vaga de traduções automáticas de que temos falado. Tobi confirma-o: a maioria das variantes linguísticas depende de um ou dois editores ativos, e a pressão de quem desenvolve e envia milhares de cadeias de texto para idiomas que não fala está a desgastar as pessoas. É também referido que os editores de projeto ficam inativos porque só trabalham no projeto que lhes interessa e não recebem notificações depois disso, e que as importações marcadas como «atuais» não ficam registadas nos perfis, pelo que os números tendem a sobrestimar a inatividade.

Quanto às soluções, há um amplo consenso. Há já algum tempo que se propõe um estatuto honorário ou emérito, em parte por razões de segurança, já que faz sentido limitar as permissões de quem deixou de contribuir, sobretudo sem autenticação de dois fatores, e em parte para que quem chega sinta que faz falta.

O WordPress Credits, o programa que liga estudantes de instituições parceiras a trabalho concreto de contribuição para o projeto, abre níveis de patrocínio para 2027. Começou com oito instituições e, no primeiro ano, trabalhou em 17 países e chegou a mais de 900 estudantes, números que podes acompanhar no painel público do programa. Esse crescimento explica a mudança: o plano curricular, a tradução, as ferramentas e a integração de novas instituições precisam de financiamento estável, e o sistema de patrocínios atual não foi concebido para isso. Será uma experiência-piloto, e a equipa promete publicar o que aprender e abandonar o que não funcionar. Os patrocinadores atuais têm financiado mentores e contribuído com produtos usados pelos estudantes, e os níveis partem daquilo que esses apoios tornaram possível.

Há cinco níveis:

Todos aparecem na página de parceiros e são mencionados no destaque dedicado aos mentores. A partir de Supporter, têm direito a um logótipo, um distintivo para o próprio site e um relatório anual. A partir de Backer, podem identificar a parte concreta do programa que financiam, com um relatório sobre esse custo e um artigo educativo sobre o produto patrocinado. Champion acrescenta outro artigo com informação factual e neutra sobre mais produtos, um convite para a sessão anual de parceiros educativos e um webinar ou evento conjunto. Os artigos são escritos pela empresa, mas publicados em wordpresseducation.org após revisão da equipa, para que a sua utilidade para os estudantes venha em primeiro lugar. Além dos níveis, qualquer patrocinador pode oferecer acesso gratuito aos seus produtos, que a Fundação distribui, sem exigir cartão de pagamento e com uma forma de exportar o trabalho, para que ninguém fique preso ao produto.

O nível para o qual a equipa mais quer chamar a atenção é Partner, que financia um programa completo com nome próprio. Até agora, a equipa não conseguiu criar um programa deste tipo porque estava limitada ao orçamento disponível. O patrocinador seria o parceiro exclusivo desse programa, teria presença no seu lançamento e receberia um relatório específico. A equipa prefere concebê-lo em conjunto com o patrocinador, em vez de apresentar uma lista fechada. Entre as ideias estão estudantes a traduzir o WordPress para idiomas com pouca cobertura, a trabalhar na acessibilidade ou a criar sites para organizações sem fins lucrativos que, de outra forma, não poderiam contratar esse serviço. Um gestor do programa irá contactar cada patrocinador atual para ajustar o respetivo nível. Os eventos Campus Connect ficam fora destes níveis.

Já existe um plugin para usar o diretório Photos sem sair do painel. Chama-se PhotoFetch, está publicado no diretório de plugins do WordPress.org e permite pesquisar fotografias e importá-las diretamente para a Biblioteca Multimédia. Tem um ecrã próprio no menu da Biblioteca Multimédia para pesquisar e importar, mas também se integra no seletor de conteúdos multimédia do editor, como um separador ao lado do da Biblioteca. O diretório Photos reúne imagens disponibilizadas pelo público sob a licença CC0, ou seja, livres de direitos, pelo que o plugin evita teres de descarregar uma fotografia e voltar a carregá-la manualmente.

O mais interessante é a sua origem. Uma equipa de sete pessoas criou-o durante o Dia de Contribuição do WordCamp US 2026. Depois da ideia inicial e da pesquisa para avaliar a sua viabilidade, o resto do dia foi dedicado às funcionalidades, à documentação e aos testes. É um bom exemplo do que um dia de contribuição bem aproveitado pode produzir.

A equipa do BuddyPress publicou as versões de segurança 14.5.3, 12.7.3 e 11.6.3, com correções para os três ramos que ainda recebem suporte. No dia seguinte chegou também a 14.5.4, mas não te confundas: segundo as notas dessa versão, não traz novas correções. Trata-se apenas de uma alteração do número de versão acrescentada ao ramo principal para que os sites possam atualizar. Todas as correções estão na 14.5.3 e, como a versão da base de dados não muda, não é necessário executar qualquer migração.

Os seis erros corrigidos são significativos. Há duas vulnerabilidades de injeção de SQL, uma do tipo cego na gestão de campos de perfil e outra através de um argumento não associado a um parâmetro da consulta. É também bloqueada uma utilização abusiva da função maybe_unserialize e impedido que utilizadores sem permissões de administrador atribuam a si próprios tipos de membro. As outras duas estão relacionadas com grupos: deixa de ser possível comentar atividades de grupos dos quais não se é membro, e a REST API deixa de revelar detalhes de grupos ocultos.

Por cá, o fim de semana ficou marcado pelo WordPress Day for AI, que decorreu em Faro, no sábado.

Foi um enorme sucesso, contando com mais de 130 pessoas, entre participantes, organizadores e voluntários, patrocinadores e oradores. Foram 16 sessões cheias de novidades, de interação entre os participantes, partilha de conhecimento e troca de experiências relacionadas com a utilização da inteligência artificial no WordPress.

Muito em breve vão estar disponíveis os vídeos das sessões na WordPress TV, para que possas recordar ou ver pela primeira vez. É verdade que, se não estiveste no evento, perdeste a interação entre os participantes, o networking e o envolvimento no local com os oradores.

Quanto a este evento… já não há nada a fazer.

Agora, o que importa é participares nos próximos eventos da comunidade portuguesa de WordPress. Foi anunciado o lançamento de um novo grupo de Meetup: o Meetup WordPress da Madeira. Foi também anunciado o WordCamp Portugal 2027, que será realizado em Lisboa, ainda sem uma data e um local definidos.

O Porto WordPress Meetup vai estar presente, pelo segundo ano consecutivo, na conferência do Porto Tech Hub de 2026, que irá decorrer no dia 10 de novembro, na Alfândega.

Esta conferência, que junta empresas tecnológicas da área do Porto e não só, inclui uma área dedicada às comunidades tech da cidade do Porto. O Porto WordPress Meetup estará ainda nesse dia no palco das comunidades para uma apresentação feita por Carlos Moreira e Fábio Nunes sobre “WordPress in 2027, Reinventing a Giant. In the Age of AI”.

Está agendada para as 11:10.

Os bilhetes para o evento estão disponíveis, e a comunidade portuguesa de WordPress oferece-te um código de cupão que podes usar para adquirir o teu bilhete com 40% de desconto.

É este: PTH2026-u1w4-PORTOWORDPRESSMEETUP_40

“A IA não vai gostar dos teus clientes, mas tu podes: o poder das relações humanas nos negócios WordPress” é, em português, o título da apresentação que Manuela Van Prooijen vai fazer no Porto WordPress Meetup de Outubro, no dia 29.

Há dez anos, Manuela apresentou uma palestra no WordCamp Netherlands e no WordCamp Geneva intitulada “Longa vida ao cliente: como tirar mais partido dos teus clientes WordPress!”. Ao rever essa apresentação, percebeu que quase tudo o que disse na altura continua a fazer sentido hoje, talvez ainda mais.

Promete um exercício prático para encontrar formas de surpreender os nossos clientes, fazê-los sorrir e dar-lhes bons motivos para continuarem a trabalhar connosco.

A apresentação será em inglês.

Como sempre, a participação é gratuita mas pede-se o registo de presença na página do evento no Meetup .com.

Por fim, este podcast é distribuído sob uma licença Creative Commons, como versão derivada do podcast em espanhol. Podes encontrar todas as ligações para mais informação, bem como o podcast noutros idiomas, em WPpodcast .org.

Obrigada por ouvires e até ao próximo episódio.

Conseguir boas traduções para a interface do WordPress é mais difícil do que nunca, e a culpa é da IA.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras as notícias de 12 a 18 de outubro de 2026.

Conseguir boas traduções para a interface do WordPress é mais difícil do que nunca, e a culpa é da IA.

A tradução automática tem ajudado há vinte anos, mas agora muitos programadores usam modelos como o ChatGPT ou o Claude para traduzir em massa os seus plugins e temas para línguas que não dominam. Depois, esperam que os voluntários revejam o resultado, uma tarefa que exige muito mais trabalho do que gerar as traduções. As equipas de cada localização acumulam milhares de cadeias de texto por aprovar todas as semanas. O resultado habitual é rever algumas por amostragem e aprovar ou rejeitar as restantes em massa, com ferramentas que só permitem trabalhar num ecrã de cada vez.

Ao mesmo tempo, os pedidos para obter a função de Editor de Tradução de Projeto, ou PTE, dispararam: nos últimos seis meses, a equipa passou a receber mais pedidos por dia do que antes recebia por semana. E os programadores já não pedem acesso para uma ou duas localizações, mas para dez ou vinte.

Há três frentes de trabalho:

Os comentários acrescentam algumas nuances. Uma proposta, por exemplo, é limitar as importações a cem cadeias de texto até que um editor as aprove. Outra defende que só os editores possam fazer importações e pull requests. Há quem assinale que muitos programadores pensam precisar da função de PTE para ver as suas traduções aprovadas. Outros lembram que o verdadeiro incentivo é a visibilidade no diretório e que criar um glossário automático é difícil em alemão, por exemplo, por causa das palavras compostas.

A proposta mais desenvolvida não pretende proibir nada, mas tornar a automatização visível. Ao importar traduções, o autor declararia que usou IA e aceitaria que as cadeias de texto fossem marcadas como não revistas. Os editores poderiam aprová-las em massa ou rejeitá-las com uma única ação. Essas traduções não entrariam na memória de tradução, e os utilizadores veriam um aviso antes da instalação, podendo escolher o inglês ou desativar as traduções automáticas. Do Japão chega a experiência de uma equipa que revê apenas as primeiras cadeias de texto e deixa pedidos de alteração. O seu guia de estilo funciona porque muitas pessoas já o fornecem às ferramentas automáticas. Uma das ideias é limitar o formulário de pedidos a três localizações.

O Gutenberg 24.2 já está disponível e as Notas são o grande destaque. Passam a aparecer numa margem ao lado da área de edição, mantendo-se visíveis quando mudas de bloco ou de definições. Podem ser minimizadas ou ocultadas, é possível anular a eliminação de uma nota e o texto que estás a escrever não se perde quando mudas de bloco.

O bloco Navegação passa a ter uma pesquisa única que abrange páginas, artigos, categorias e etiquetas. A Galeria pode ordenar as imagens e aplicar-lhes um efeito duotone comum. As ferramentas de design continuam a chegar a dezenas de blocos: largura e altura mínimas, sombras, duotone e fundos com imagem ou gradiente.

Para os programadores, a alteração mais importante é que o React 19 passa a estar ativo por predefinição, exceto nos sites com um tema ou plugin que se sabe ter problemas, que continuam a usar o React 18. Esta mudança reverte o adiamento feito no WordPress 7.1. A equipa pede que sejam testados os plugins e temas que usam React; a funcionalidade pode ser desativada na área de Experiências.

O Feature Notifications, projeto para criar um sistema unificado de notificações para o WordPress, voltou à atividade após mais de três anos parado: a última versão, a 0.2.0, data de abril de 2023. Jonathan Bossenger, que teve de se afastar em 2023 e retomou agora o projeto, analisou o código e publicou um plano para chegar à versão 0.3.0. Esta seria a primeira versão verdadeiramente funcional, capaz de criar, guardar, mostrar e dispensar notificações, com lançamento previsto para 1 de dezembro, juntamente com a última versão candidata do WordPress 7.2. As bases estão criadas, com modelos de dados, registo de canais, esquema da base de dados e a interface do centro de notificações na barra de administração, mas o sistema ainda não funciona de ponta a ponta. A camada de persistência não está implementada, a API REST devolve respostas vazias, dispensar uma notificação não guarda a ação e os testes do controlador REST estão desativados.

O plano divide-se em fases que podem avançar em paralelo:

De um modo geral, o regresso do projeto foi bem recebido, porque as notificações no painel de administração são um dos aspetos mais problemáticos da experiência de utilização e pioram à medida que se instalam mais plugins.

Na continuação da aposta numa colaboração mais atenta ao servidor, a equipa de Core publicou um guia para testar os três motores de sincronização candidatos, reunidos num plugin experimental chamado Gutenberg Sync Engines.

O Yjs é o que mais se aproxima do Google Docs, com cursores em tempo real e atualizações muito rápidas. Mas oculta conflitos, porque, quando há duas alterações simultâneas, uma prevalece sem aviso. Também exige a manutenção de duas implementações, uma em JavaScript e outra em PHP.

O DE-RTC é o mais parecido com o WordPress de antigamente: só sincroniza ao guardar, por predefinição a cada dez segundos, e separa os conflitos reais para revisão. Não funciona em tempo real, mas exige poucos recursos a alojamentos modestos e permite que plugins, scripts ou o WP-CLI participem quase como uma pessoa.

O Intent-log envia descrições do que cada pessoa fez, como «dividiu este bloco». Isto dá contexto ao servidor e cria um histórico legível, embora processe uma atualização de cada entrada de cada vez e a sua lógica de combinação ainda não esteja amadurecida.

O debate de fundo toca diretamente no alojamento. Há cinco meios possíveis de comunicação, desde a consulta periódica simples, que funciona em qualquer lado, até aos WebSockets, que exigem um processo separado. O guia avisa que a maioria dos alojamentos partilhados não suporta ligações de longa duração. Por isso, seja qual for o motor escolhido, os sites comuns acabarão por usar a consulta periódica.

Há uma nova versão do bbPress, mais uma vez dedicada à segurança e à manutenção. Por isso, se tens fóruns, volta a atualizar. A versão reforça a validação das palavras-passe de tópicos e respostas e faz com que os shortcodes apareçam como texto literal quando surgem nos ciclos normais de conteúdo do WordPress. A novidade funcional é uma definição de estado para os fóruns de todo o site, com três opções: aberto, fechado e congelado. Os sites existentes continuam em modo aberto, a menos que a definição seja alterada.

O restante trabalho é de manutenção, sobretudo na integração com o BuddyPress: ações dos perfis, percursos dos tópicos de grupos, visibilidade da atividade e acesso aos fóruns dos grupos. Foi também reposta a compatibilidade com links de subscrição de pacotes de temas de terceiros. Os formulários de moderação mantêm os dados após um erro de validação, e há correções nas notificações, conversores, widgets, perfis, administração de temas e respostas, e visibilidade de conteúdo restrito.

No sábado, decorre em Faro o WordPress Day for AI, uma iniciativa da comunidade portuguesa de WordPress, com um programa cheio e rico de apresentações e conversas em redor do WordPress e, claro, da utilização da inteligência artificial na plataforma.

Com duas tracks, uma ‘business’ e outra ‘tech’, o programa integra apresentações em português e em inglês para um dia cheio de conhecimento, partilha de ideias e informação, além de networking.

O evento tem a participação prevista de cerca de 130 pessoas, incluindo os oradores. Com sorte ainda poderá haver bilhetes disponíveis.

“A IA não vai gostar dos teus clientes, mas tu podes: o poder das relações humanas nos negócios WordPress” é, em português, o título da apresentação que Manuela Van Prooijen vai fazer no Porto WordPress Meetup de Outubro, no dia 29.

Há dez anos, Manuela apresentou uma palestra no WordCamp Netherlands e no WordCamp Geneva intitulada “Longa vida ao cliente: como tirar mais partido dos teus clientes WordPress!”. Ao rever essa apresentação, percebeu que quase tudo o que disse na altura continua a fazer sentido hoje, talvez ainda mais.

Promete um exercício prático para encontrar formas de surpreender os nossos clientes, fazê-los sorrir e dar-lhes bons motivos para continuarem a trabalhar connosco.

A apresentação será em inglês.

Como sempre, a participação é gratuita mas pede-se o registo de presença na página do evento no Meetup .com.

Por fim, este podcast é distribuído ao abrigo de uma licença Creative Commons, como versão derivada do podcast em espanhol. Podes encontrar todos os links para mais informações, bem como o podcast noutras línguas, em WPpodcast .org.

Obrigado por ouvires. Até ao próximo episódio.

Já podes ligar-te remotamente ao WordPress a partir da tua ferramenta de inteligência artificial, de forma nativa, com o plugin MCP Adapter.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras a informação de 5 a 11 de outubro de 2026.

Quinto conjunto de correções de segurança para a versão 7.1 em apenas dois meses: o WordPress 7.1.3 corrige sete vulnerabilidades e quatro erros, com a recomendação de atualizar imediatamente.

Nenhuma parece tão grave como a execução remota de código corrigida na versão 7.1.2, mas a lista é variada:

A estas juntam-se a divulgação, sem autenticação, de comentários em artigos privados ou não publicados, uma vulnerabilidade de XSS em conteúdos incorporados do Imgur e uma colisão de nomes de ações num hook. As correções estão a ser aplicadas retroativamente até ao ramo 4.7, e tudo isto está em linha com o que a Core Security Initiative relatou sobre a vaga de denúncias de vulnerabilidades impulsionada por ferramentas de IA.

Entretanto, já existe um calendário das sessões de lançamento da versão 7.2, cujo lançamento está previsto para 8 de dezembro. A Beta 1 chega a 20 de outubro; seguem-se três versões candidatas a lançamento, a partir de 17 de novembro, e um ensaio geral a 7 de dezembro, com um período de 24 horas sem alterações ao código.

Três grandes mudanças no Core do WordPress 7.2: HTML, SQL e revisão das normas de CSS.

A mais importante é a reescrita da função kses, que tem filtrado o HTML de artigos de origem não fidedigna ao longo de toda a história do WordPress.

A implementação original é anterior ao HTML5 e remonta à época em que se escrevia HTML à mão. Hoje, a sua finalidade é quase exclusivamente eliminar riscos de segurança, pelo que a nova versão passa a usar a API de HTML do WordPress, em vez de expressões regulares e cadeias de funções.

A interface não muda, nem é necessário alterar plugins ou temas, mas o comportamento muda perante dados de entrada invulgares:

Um problema antigo do WordPress está de regresso: a lista de utilizadores pode ser ordenada por nome próprio, mas não por apelido.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras a informação de 27 de setembro a 4 de outubro de 2026.

O Gutenberg 24.1 é, acima de tudo, uma versão dedicada à consistência das ferramentas de design: cerca de 140 dos seus contributos destinam-se a garantir que quase todos os blocos nativos têm as mesmas opções de fundo, cor, sombra e tipografia.

As opções de imagem, tamanho e gradiente de fundo, sombras, contornos e cores de ligações, títulos e botões chegam agora a blocos como Acordeão, Separadores, Comentários ou os blocos de artigos. Os blocos Grupo, Biografia do autor e Lista de termos passam também a permitir a disposição do texto em colunas. A sombra do texto, introduzida há algumas versões, tem agora o seu próprio painel nos Estilos globais e está disponível nos blocos Parágrafo e Título. Os blocos Capa e Multimédia e texto passam a ter uma secção de seleção de multimédia no painel de definições, à semelhança do que já acontecia com os blocos Imagem e Logótipo do site.

O plugin Presence API, que mostra quem está a trabalhar e onde no painel do WordPress, anunciado em abril, chega à versão 0.14.0 com várias novidades significativas.

A mais relevante é o suporte para multissite: quem administra a rede pode agora ver, de uma só vez, quem está ligado em todos os sites, uma funcionalidade ativa por omissão nas redes que não sejam de grande dimensão. Muda também a forma como são geridos os bloqueios de edição de artigos, que deixam de ser guardados como metadados do artigo e passam para a própria tabela de presenças. Assim, renovar um bloqueio deixa de invalidar a cache de consultas de artigos nos sites com cache persistente de objetos, o que constituía um verdadeiro problema de desempenho. O Presence funciona também com qualquer tipo de conteúdo que tenha um editor, incluindo o que cada pessoa tem aberto no Editor do site, e com papéis de utilizador que apenas permitem editar páginas ou tipos de conteúdo personalizados.

Há dois aspetos que se destacam. Quanto à privacidade, o registo de atividade está ativo por omissão, mas pode ser desativado por site ou para toda a rede. Existe também uma secção na política de privacidade, bem como ferramentas de exportação e apagamento de dados. Além disso, saber onde está cada pessoa continua, por omissão, reservado a quem tem permissão para listar utilizadores; as restantes pessoas apenas veem quem está ligado. Quanto à IA, os agentes que editam através da REST API ou de MCP não enviam o sinal periódico de atividade habitual. Por isso, desde a versão 0.13, cada gravação regista uma presença temporária, identificada com a etiqueta «Agente» na barra de administração e na coluna de editores. O plugin não decide quem é um agente: consulta o plugin Agent Users ou qualquer outro que responda através do filtro disponibilizado. Entre as melhorias estão um melhor desempenho, com um único separador a fazer as consultas e a partilhar os resultados com os restantes, um aviso no Diagnóstico do site se o Heartbeat não estiver a manter as presenças atualizadas e uma ferramenta de depuração na barra de administração, apenas para desenvolvimento.

Foi reaberta a discussão sobre um problema antigo do WordPress: no ecrã de perfil, o nome próprio aparece sempre antes do apelido e nenhum idioma permite alterar essa ordem. Em japonês, húngaro, chinês, coreano ou vietnamita, o apelido escreve-se primeiro. O WordPress já permite essa ordem na apresentação pública do nome, mas não no seu preenchimento. O pedido mais antigo no Trac data de 2008 e, desde então, a questão tem sido sucessivamente adiada, à espera de uma solução global com um único campo para o nome completo que nunca chegou. Entretanto, os utilizadores no Japão ou na Malásia recorrem a truques como colocar o apelido no campo do nome próprio ou inverter os campos com CSS.

A proposta é dividir o problema em dois:

Fumiki Takahashi, que reabriu a discussão, reconhece o enviesamento da amostra: quem participa no Slack ou no Trac já se habituou à ordem inglesa e responde que isso não incomoda. No entanto, as pessoas mais afetadas, como quem tem um pequeno café e cria o site no seu próprio idioma, quase nunca participam nesses espaços. É pedido à equipa de cada variante linguística que partilhe como se escrevem os nomes nos documentos oficiais, o que faz atualmente no WordPress e se a alteração seria adequada.

Os primeiros comentários já acrescentam algumas nuances: em russo, a ordem formal coloca o apelido primeiro, mas a ordem atual do WordPress não causa estranheza, porque nome próprio, patronímico e apelido também é uma sequência natural. Quando não existe um campo para o patronímico, o habitual é omiti-lo, em vez de o juntar ao nome próprio ou ao apelido. Tor-Björn Fjellner, mentor da equipa Polyglots, defende que a opção mais razoável é um único campo, porque é impossível adivinhar onde deve ficar cada parte do nome, e sugere um segundo campo com o valor a usar na ordenação. Fumiki considera que esta abordagem está de acordo com as recomendações de internacionalização do W3C e acrescenta que o mais importante é saber como as pessoas escrevem efetivamente os seus nomes em cada região, para além da teoria.

Foi detetada uma contradição no manual da equipa de Comunidade sobre quem pode organizar um evento de um grupo de meetup. Uma página do manual, intitulada “Qualquer membro pode organizar um evento”, diz que qualquer membro o pode fazer sem restrições, enquanto as Cinco Regras de Boa-fé falam em membros “responsáveis e de confiança”. A autora da proposta viu-se perante esta contradição quando uma pessoa que nunca tinha participado num meetup lhe pediu para organizar um e ela sugeriu que participasse primeiro num dos encontros existentes. Um membro perguntou-lhe então se qualquer pessoa podia ou não organizar um evento, e ela não conseguiu dar uma resposta clara. A sua hipótese é que, quando o conteúdo foi dividido em páginas separadas em 2023, o texto foi copiado, mas perdeu-se o contexto: na versão de 2016, a frase referia-se a uma caixa de seleção específica nas ferramentas do grupo, enquanto o título da página atual a transforma num princípio geral.

A resposta da equipa, que lhe chegou por mensagem privada e não está documentada em lado nenhum, é que qualquer membro pode organizar um evento sem ser coorganizador do grupo, mas tem de se articular com os coorganizadores, que confirmam que a pessoa é de confiança e cumpre as regras. Por isso, propõe-se confirmar esta interpretação, remover a página “Qualquer membro pode organizar um evento” e distribuir o seu conteúdo pela documentação de gestão dos grupos, pelas regras e pelo registo deste caso na auditoria ao manual.

Na equipa de Fotografias, descobriu-se que a regra contra imagens geradas por IA existe, mas apenas verbalmente. Foram revistas as conversas no canal do Slack desde 2023 e, em várias ocasiões, foi afirmado que uma imagem gerada não é uma fotografia e não é aceite. Os moderadores pedem que sejam submetidas apenas fotografias reais. No entanto, nem as diretrizes, nem a lista de verificação antes do carregamento, nem o email de rejeição, nem as perguntas frequentes mencionam a IA. Assim, quem submete uma imagem só fica a saber da regra quando esta é rejeitada. Também não está documentado como contestar uma rejeição, o que deixou sem resposta pessoas que afirmavam ter carregado fotografias reais, com a dificuldade acrescida de a imagem ser apagada quando é rejeitada.

A proposta consiste em quatro alterações simples: acrescentar “imagens geradas por IA” à frase das diretrizes que já exclui capturas de ecrã e arte digital; fazer o mesmo na caixa de seleção da lista de verificação; alargar o motivo de rejeição “Não é uma fotografia” ou criar um específico para IA; e acrescentar às perguntas frequentes que quem considerar ter havido um erro pode responder ao email de rejeição com a fotografia em anexo. A proposta limita-se a imagens integralmente geradas e deixa a edição com IA, como o aumento de resolução ou o preenchimento generativo, para outra discussão.

O bbPress 2.6.19 é uma nova versão de segurança que passa a fazer respeitar as palavras-passe dos fóruns antigos nas respostas da REST API e na atividade do BuddyPress, e reforça as verificações de acesso a conteúdos restritos nos feeds, nos fóruns de grupos e noutras formas indiretas de visualização. Reforça também as permissões de moderação e dos papéis nos fóruns, protege as credenciais do importador e a gestão de contas, e melhora o tratamento de caracteres especiais nos perfis e na administração.

Entre as correções de manutenção estão ajustes nas associações e notificações dos fóruns de grupos do BuddyPress, na limpeza efetuada pelo conversor, nas palavras-passe importadas da base de dados, nos emails de subscrição e na posição das respostas.

A organização do WordPress Day for AI anunciou mais dois oradores e vai incluir um evento especial no programa.

Foram anunciadas duas sessões da track Tech que tratam da diferença entre dar poder à IA dentro do WordPress, sem lhe dar as chaves todas.

Uma das apresentações mostra a porta nova pela qual os agentes de IA entram no WordPress e no WooCommerce. A outra mostra o que tens de montar para que essa porta não fique escancarada.

Marco Almeida vai falar sobre a WordPress Abilities API e como interagir com o WooCommerce em linguagem humana e Ivelina Dimova sobre os limites a aplicar à IA no WordPress.

Quando ao evento especial, sabe-se que está a ser preparado mas, para já, é uma surpresa.

Entretanto, o programa está já disponível, incluindo 16 sessões, das quais quatro são lightning, além do prometido evento especial.

Podes comprar bilhetes para o evento no site oficial.

Por fim, este podcast é distribuído sob uma licença Creative Commons, como versão derivada do podcast em espanhol. Podes encontrar todos os links para mais informações, bem como o podcast noutros idiomas, em WPpodcast .org.

Obrigada por ouvires e até ao próximo episódio.

Se queres contribuir para o WordPress usando IA, agora podes ligar-te ao servidor MCP do Trac para encontrar tickets, changesets e tudo o que precisas para explorar o backlog de trabalho pendente.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da Comunidade WordPress.

Neste episódio, vais encontrar a informação de 21 a 26 de setembro de 2026.

Quarta versão de segurança da série em pouco mais de mês e meio, e desta vez com severidade crítica: o WordPress 7.1.2 corrige uma vulnerabilidade comunicada de forma responsável que permite a um atacante não autenticado fazer com que a resolução de templates de página inclua um ficheiro PHP local arbitrário, desde que seja legível e esteja localizado fora dos diretórios do tema ativo. Se determinadas pré-condições forem cumpridas, tanto no ambiente do servidor como no tema ativo, isto pode levar à execução remota de código. Tem o seu próprio CVE, CVE-2026-87902.

Atualização recomendada imediatamente, desta vez sem desculpas: os patches já foram retroportados para todos os ramos com suporte de segurança, da versão 4.7 à 7.0, por isso está na altura de verificares a tua versão e atualizares o mais depressa possível.

Consequência direta do episódio que já cobrimos sobre o lançamento do WordPress 7.1 no palco da WordCamp US: Anne McCarthy anuncia que o WordPress vai abandonar o formato de lançamento ao vivo em palco.

Depois de duas rondas da experiência, como o State of the Word 2025 e o próprio 7.1 na WordCamp US, a equipa reconhece que associar o lançamento a um evento físico traz mais problemas do que vantagens: logística complexa, limites ao número de pessoas da equipa de lançamento que podem deslocar-se ao evento e a própria equipa a relatar que executar em palco um processo que não foi pensado para isso acrescenta stress real e desnecessário.

A alternativa, proposta por Matt depois de a discutir com Anne, é passar para um formato de webinar em direto no Zoom, sem data fixa associada a um evento: quem faz parte da release squad e do próprio lançamento pode participar na sessão ao vivo, enquanto todas as outras pessoas assistem e colocam perguntas. Isto permite que mais pessoas da equipa participem, dependendo do seu fuso horário, sem o custo de viajar para um evento. Este novo formato começa já com o WordPress 7.2, previsto para o início de dezembro, com mais detalhes sobre como participar à medida que a data se aproximar.

O Gutenberg concluiu a migração dos seus testes unitários e de integração em JavaScript, deixando o Jest para trás em favor do Vitest. A razão resume-se a duas vantagens importantes:

Os próprios testes em Vitest terminaram mais depressa do que o grupo mais lento dos que corriam em Node, pelo que a nova cobertura em browser não aumentou o tempo total de execução.

Para quem contribui para o core do WordPress, há agora um servidor MCP público e gratuito para consultar o Trac a partir de qualquer assistente de IA, sem necessidade de conta ou chave de API.

Funciona com Claude, ChatGPT ou qualquer outro cliente compatível com MCP, e permite perguntar, por exemplo, o que ainda está pendente num ticket específico e que pull requests continuam abertos, ou pedir um resumo de um changeset e do respetivo diff. Inclui ferramentas específicas para pesquisar tickets, ler um ticket juntamente com a sua discussão e anexos, consultar um changeset ou rever a timeline. Por omissão, liga-se ao Core Trac, mas funciona da mesma forma com os restantes Tracs do WordPress.org, como Meta, Themes, Plugins, bbPress, BuddyPress ou GlotPress, bastando alterar o endpoint.

O WordPress Contributor Toolkit chega à versão 1.2 com uma novidade significativa: suporte completo também para contribuir para o Gutenberg, e não apenas para o core. O fluxo é paralelo ao do Core: ao criar um site, escolhes se queres contribuir para o WordPress Core ou para o Gutenberg, uma decisão que já não pode ser alterada depois e que determina que repositório é clonado e como é construído.

No caso do Gutenberg, em vez de associares um ticket do Trac, associas uma issue do GitHub, que traz consigo os respetivos pull requests com um botão “Apply…” para os testar diretamente. Quando o trabalho estiver concluído, podes abrir o pull request no repositório correspondente sem sair da aplicação, com autenticação por device flow que existe apenas em memória enquanto a aplicação está aberta.

O Dev Tools Dock do WordPress Playground acrescenta mais uma ferramenta: um painel de email que captura e apresenta os emails gerados pelo site, sem configurar um servidor de email nem consultar uma caixa de entrada real.

Quando o WordPress envia uma mensagem pelo seu caminho habitual, o PHP escreve-a para um programa compatível com sendmail, e o Playground interceta essa mensagem no browser em vez de a entregar, mostrando o assunto, remetente, destinatário e corpo, com pré-visualização em HTML se a mensagem a incluir.

É útil para praticamente qualquer plugin que envie emails pelo caminho normal do WordPress: formulários de contacto, mensagens de boas-vindas ou aprovação em sites de membros, confirmações de encomendas ou reservas, ou simplesmente para comparar o aspeto de um template de email em diferentes temas ou versões do WordPress.

Terceira versão do bbPress em pouco mais de um mês, embora desta vez sem surpresas de segurança: a 2.6.18 é uma versão de manutenção focada nas importações de fóruns antigos e na atualização de palavras-passe no primeiro início de sessão. Os utilizadores importados de formatos de fóruns antigos podem agora atualizar a palavra-passe ao iniciar sessão pela primeira vez, mesmo nos casos em que a base de dados do fórum original já não existe. Também corrige estados de tópicos, contagens de respostas e datas de fóruns ao importar de PHPWind, e repõe a ligação de edição de Super Moderator nos ecrãs de utilizador no frontend.

A equipa de Community dá novidades sobre a migração dos grupos de meetup do WordPress do Meetup.com para o events.WordPress.org, a alternativa baseada em GatherPress. Depois do pedido de testes no final de agosto, que trouxe muito feedback útil, o plano para os cerca de 700 grupos afetados avança em três fases:

Várias coisas já ficaram decididas: a ferramenta de migração irá importar eventos futuros e locais como rascunhos para os organizadores reverem antes de publicar, mas não copiará a lista de membros, uma vez que cada pessoa terá de aderir por iniciativa própria com uma conta WordPress.org.

Para já, a migração será executada por alguém da própria equipa, e não pelo organizador do grupo, ficando os eventos passados fora desta primeira fase. Precisamente por isso, a equipa insiste que quem organiza um grupo deve começar já a incentivar os seus membros a criar uma conta WordPress.org, porque esse será um requisito inevitável para permanecer no grupo depois da migração.

Ficam ainda duas questões relevantes em aberto:

Mary Hubbard, Executive Director do WordPress Project, assume a presidência da Open Website Alliance, o organismo que reúne as organizações por trás de Drupal, Joomla!, TYPO3 e WordPress para defenderem em conjunto o software livre. O cargo é rotativo entre os membros da Aliança, pelo que é agora a vez do WordPress.

A Aliança nasceu em 2024 a partir do trabalho conjunto destes quatro projetos em resposta ao Cyber Resilience Act da União Europeia, defendendo junto dos legisladores que os seus sistemas de gestão de conteúdos não são apenas infraestrutura digital básica, mas a maquinaria através da qual empresas reais chegam aos seus clientes e vendem produtos, e que qualquer requisito de segurança deve ter em conta esse papel económico sem sufocar a forma como trabalham as comunidades de programadores, tradutores e colaboradores que mantêm o software.

Hubbard enquadra a nomeação na mesma linha da recente assinatura, pelo WordPress, da carta sobre modelos de IA de pesos abertos: a ideia de que todas as pessoas devem ter a liberdade de usar, modificar e partilhar as ferramentas de que dependem.

A organização do WordPress Day for AI anunciou mais seis oradores na última semana.

Começamos por Rose Hes Rozendo, Simone Cimiluca-Radzins e Madalena Costa. Estão todas na track de Business e chegam ao mesmo sítio por caminhos diferentes: a tua voz, a forma como te ligas a quem te compra e a responsabilidade quando alguma coisa corre mal continuam a ser tuas. A IA ajuda muito mas… assinar por ti, não assina.

Noutro plano, Rui Barroca, Juan Rodríguez e Miguel Costa vão assinalar que construir um site, uma ferramenta ou um fluxo de trabalho nunca custou tão pouco. Afinal, um designer sem experiência de programação publica produtos sozinho. Um dono de negócio monta um site inteiro com sugestões de um chat. Um developer despacha em duas horas o que dava dois dias.

A parte interessante é o que vem a seguir: decidir o que vale a pena construir, limpar o que foi construído à pressa e supervisionar máquinas que não sabem quando estão erradas.

Os bilhetes estão disponíveis.

Este podcast é distribuído sob uma licença Creative Commons como versão derivada do podcast em espanhol; podes encontrar todas as ligações para mais informação, e o podcast noutras línguas, em WPpodcast .org.

Obrigado por ouvires, e até ao próximo episódio.

Já conhecemos o roteiro para o WordPress 7.2, o que está planeado para esta versão e o que não deverá entrar.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da Comunidade WordPress.

Neste episódio, vais encontrar a informação de 14 a 20 de setembro de 2026.

O WordPress 7.2 está previsto para o início de dezembro de 2026, e a equipa já publicou o roteiro oficial para este ciclo. Como acontece com todos os roteiros, a própria equipa sublinha que tudo o que está listado se encontra em desenvolvimento ativo, mas nada garante que chegue exatamente assim à versão final. É um roteiro de intenções, não uma lista fechada de compromissos.

O ponto que mais chamou a atenção esta semana foi o próprio tema por omissão: chama-se Ipsum, e com ele o WordPress quebra uma tradição com mais de uma década de dar aos seus temas nomes baseados no ano da versão.

A partir de agora, cada tema por omissão terá o seu próprio nome e mudará quando o design o justificar, não por imposição do calendário.

A história por trás disto é interessante: a equipa tinha passado meses a trabalhar num tema muito mais ambicioso e expressivo, com o nome de código Mētis, pensado para mostrar tudo aquilo que o Gutenberg já consegue fazer. Depois de rever a direção com Matt, os critérios mudaram: o tema incluído no WordPress deve ser o ponto de partida mais simples possível, deixando os designs mais elaborados para existirem separadamente. Mētis continua vivo como projeto independente, mas não será incluído nesta versão.

Ipsum, nome inspirado no clássico texto de preenchimento “lorem ipsum”, que ocupa uma página até chegar o conteúdo real, é uma tela em branco pensada para blogues, com linhas tracejadas a simular traços de lápis do editor, algumas combinações tipográficas e variações de estilo que mudam a cor de toda a página, incluindo as imagens. Todas as combinações cumprem WCAG AA. Já está disponível para descarregar e testar no GitHub, com uma janela de feedback muito apertada antes do lançamento do 7.2.

O Notes, o sistema interno de comentários do editor, dá o seu salto mais ambicioso até agora: chega o modo de sugestões, no qual, em vez de apenas comentares um bloco, podes propor uma alteração real ao texto para outra pessoa aceitar ou rejeitar. É um passo enorme rumo a uma colaboração muito mais direta entre pessoas que editam o mesmo conteúdo. Também foram adicionadas reações com emoji nas próprias notas e um atalho dedicado na barra de ferramentas do bloco para adicionar uma nota sem interromper o fluxo de escrita.

A secção de segurança traz três peças de peso. A mais chamativa, em termos conceptuais, é o chamado “modo sudo”: uma funcionalidade ainda numa fase muito inicial que propõe exigir uma nova autenticação pontual para ações administrativas especialmente sensíveis, mesmo com uma sessão ativa. Isto é comum em sistemas operativos, mas não no WordPress. Para já, apenas foi anunciada a intenção, ficando uma proposta detalhada ainda por publicar.

A segunda é a Secrets API, já abordada na sua proposta inicial: continua a avançar rumo ao 7.2, com suporte para WP-CLI desde o primeiro dia, enquanto a interface de administração fica adiada para uma versão posterior.

A terceira é um conjunto de melhorias e reforços nas Application Passwords, com melhor deteção de ambientes locais versus HTTPS, notificações por email quando é adicionada uma nova palavra-passe de aplicação e tratamento mais seguro do papel predefinido que lhes é atribuído. A par disto, continua o trabalho de reforço da HTML processing API, para que o WordPress analise markup de forma mais segura e fiável em todo o core.

A mensagem da equipa sobre IA é muito clara e, para sermos justos, funciona como um travão: o ciclo 7.1 deixou claro que as funcionalidades de IA precisam primeiro de demonstrar adoção real e valor prático antes de serem consideradas para o core. Por isso, todo o trabalho nesta área continua no plugin de IA, sem garantia de entrada no 7.2.

Entre o que está a ser preparado estão:

O roteiro destaca quatro frentes concretas de acessibilidade com esforço elevado:

Chega um novo bloco Description List, composto por três blocos estáticos que serializam para as tags HTML

O bloco Ícone completa a sua pesquisa por palavras-chave, pelo que procurar “hamburger” ou “navigation” passa também a mostrar o ícone de menu.

O bloco Table of Contents, que esteve durante muito tempo em estado experimental, passa para renderização dinâmica do lado do servidor para finalmente se tornar estável, com o editor e o frontend a partilharem uma única fonte de verdade para os títulos do conteúdo.

A Interactivity API ganha uma diretiva data-wp-html para renderizar markup a partir da store dentro de uma região interativa, além de uma forma mais clara para os blocos observarem navegação do lado do cliente. E a atualização para React 19 continua a avançar, embora seja pouco provável que chegue a tempo do 7.2.

Uma das alterações estruturais mais significativas do ciclo: o Site Editor extensível está a passar para uma nova base, construída sobre o pacote de routing wordpress/boot, já muito perto da paridade funcional com o editor atual. O que importa aqui não é apenas a reformulação técnica, mas o facto de, pela primeira vez, isto se abrir a terceiros: um endpoint de configuração de vistas do lado do servidor permitirá que autores de plugins registem os seus próprios ecrãs e definições dentro do próprio Site Editor, em vez de terem de construir a sua própria API de raiz sempre que precisam disso. Outros projetos em curso, como a edição de navegação, já estão a construir sobre esta base em vez de duplicarem trabalho.

O sistema DataViews e DataForms continua a refinar a sua extensibilidade, com configuração de vistas e formulários registada no servidor, e campos e ações também registáveis por aí. Como parte disto, o próprio inspetor de posts, imagem em destaque, excerto, estado, data, autor ou template, está a ser migrado para um DataForm, e já está a ser pedida ajuda para testar especificamente essa peça.

A omnibar, introduzida no 7.1, continua a evoluir, com dashicons a serem substituídos por ícones SVG, melhorias na paleta de comandos e revisão contínua de acessibilidade. Há também uma nova ronda de melhorias nas mensagens de erro: mais claras, mais fáceis de diagnosticar e com um botão para copiar, para serem mais fáceis de pesquisar ou partilhar, seguindo os princípios de design defensivo que Matt apresentou há algumas semanas. O widget “On this day” também regressa, depois de uma tentativa sem sucesso de o incluir no 7.1.

Os elementos de formulário, botões, campos de texto, menus pendentes e a label que faltava, poderão finalmente ser estilizados de forma consistente diretamente a partir dos Global Styles, sem tocar manualmente no theme.json.

O styling responsivo introduzido no 7.1 está a ser alargado a mais controlos, com uma API pública para que blocos de terceiros com controlos personalizados também possam tirar partido dela. Agora pode ser definido um estado “active” personalizado para blocos interativos, como o item de menu atual numa navegação, começando pelo bloco Navigation Link e pelo bloco Tabs. E, desta vez com peso renovado, volta o projeto de mostrar os estilos herdados dos Global Styles diretamente no inspetor do bloco, a funcionalidade que foi arquivada no 7.1 depois de várias tentativas de design falhadas. Agora existe ainda a questão adicional de saber se se deve indicar visualmente quando um valor global foi substituído localmente, e como oferecer uma forma clara de reverter essa alteração.

O processamento de media do lado do cliente, que se estreou no 7.1, está agora focado em amadurecer o sistema: reforçar o processo de upload, expandir os formatos suportados e fechar trabalho pendente de desempenho. O inserter de media está a ser redesenhado a pensar em bibliotecas multimédia muito grandes, com mais fontes para a galeria dinâmica e opções de ordenação para a galeria estática.

O modal de edição de media do 7.1 está focado em acompanhar a relação entre uma imagem original e os seus recortes, resolvendo um problema real: hoje, cada recorte cria um anexo independente sem ligação registada ao original, o que pode acabar por encher a biblioteca multimédia com duplicados soltos. No desempenho, o foco está em remover a concatenação de scripts e estilos em favor de preloading, e em imagens responsivas melhoradas, com o plugin Enhanced Responsive Images da equipa de Performance disponível para quem quiser ajudar a testar. E as revisões visuais, introduzidas no 7.0, continuam a ser refinadas para tornar mais suave a comparação e reposição de alterações.

Uma ausência deliberada e bem fundamentada: a edição colaborativa em tempo real não está no roteiro do 7.2, embora o trabalho continue em paralelo ao ciclo de lançamento. A equipa reconhece que ainda há decisões arquiteturais importantes por resolver e, em vez de a listar aqui para depois ter de a retirar, como aconteceu em ciclos anteriores, prefere deixá-la completamente de fora por agora.

Enquanto esperamos pela chegada do 7.2, o WordPress 7.1.1 já está disponível, sendo a primeira versão de manutenção do 7.1. Traz 17 correções no core, 19 correções no editor de blocos e onze correções de segurança, pelo que é uma atualização recomendada de imediato: o próprio anúncio sublinha isto, como é habitual em qualquer versão de segurança.

Entre os bugs corrigidos estão:

A lista continua com correções de peso:

O Gutenberg 24.0 já está disponível. A adição mais prática é que as revisões visuais incluem finalmente o título do post, que tinha ficado de fora até agora: ver alterações ao título lado a lado com alterações ao corpo do texto evita ter de adivinhar quando algo foi renomeado. A Gallery introduz uma variação de grelha totalmente personalizável que substitui o antigo layout flexível não editável, e tanto o número de colunas como o recorte das imagens podem ser configurados de forma diferente por dispositivo, permitindo, por exemplo, que uma galeria mostre quatro colunas no desktop e duas no tablet sem tocar numa linha de CSS.

O Site Title ganha uma opção “fit-text”, fazendo com que o texto escale para preencher a largura disponível em vez de se manter fixo num tamanho definido e depois quebrar linha ou ficar aquém do espaço. Outros destaques incluem:

A equipa de Core que trabalha na edição colaborativa em tempo real explicou porque é que a funcionalidade continua fora do roteiro. O desenho atual junta as alterações apenas no navegador, sem envolvimento do servidor até alguém guardar, e isso deixa três lacunas sérias:

A solução proposta é tornar a colaboração “server-aware”: em vez de as pessoas trocarem alterações diretamente entre si, cada uma envia as suas para o WordPress, que verifica permissões, junta as alterações de todos e resolve conflitos, em vez de deixar tudo nas mãos do navegador. A contrapartida é maior carga no servidor, pelo que o desempenho terá de ser tratado com cuidado, sobretudo em alojamentos mais modestos.

Há três motores de sincronização em teste, disponíveis como plugin para quem quiser experimentá-los e dar feedback:

O curso “AI-Powered WordPress” já está disponível no Learn WordPress, desenhado para percorrer progressivamente tudo o que foi lançado com o plugin canónico de IA desde o 7.0. Está estruturado em quatro módulos: os três primeiros destinam-se a qualquer pessoa que gere ou publique num site WordPress, proprietários, autores, editores ou administradores, sem exigir programação, cobrindo desde a ligação do primeiro fornecedor de IA através do ecrã Connectors, até à utilização das ferramentas editoriais para redigir, resumir e classificar conteúdo, gerar automaticamente texto alternativo acessível, moderar comentários com análise de sentimento e toxicidade, e controlar o que a IA está a fazer no site através do registo de pedidos e das aprovações de conectores.

O quarto módulo dá um salto para o desenvolvimento, sem assumir experiência prévia em PHP, embora ajude já ter mexido em ficheiros de temas ou plugins: cobre a ligação de assistentes como Claude ou ChatGPT a um site através do adaptador MCP, o registo de uma WordPress Ability para que ferramentas de IA possam descobrir funções de um plugin personalizado, e a utilização do WordPress AI Client para lançar prompts a partir dos teus próprios plugins e temas. O curso completo tem uma duração estimada de nove horas, requer um site com WordPress 7.0 ou superior e acesso de administrador, e termina com uma secção sobre boas práticas responsáveis para publicar e construir com IA no WordPress.

Curiosidade: o bbPress saltou diretamente para a versão 2.6.17, ignorando a 2.6.16, porque John James Jacoby encontrou um bug de SQL logo depois de marcar essa versão e optou por lançar a correção sem esperar. É mais uma atualização de segurança e manutenção. Reforça a visibilidade herdada em fóruns privados e ocultos, limites de fóruns de grupos BuddyPress, verificações de acesso de subscritores, edição de perfis, pedidos REST API e XML-RPC, resultados de pesquisa, redirecionamentos canónicos, tags de tópicos, movimentação de respostas, divisão de tópicos e escaping de output em geral.

A outra peça importante é uma revisão profunda das ferramentas de manutenção e reparação de contadores, para tópicos, respostas, fóruns, subfóruns, envolvimento, vozes e contribuições de utilizadores, que agora se comportam melhor durante moderação, movimentações, fusões, divisões, eliminação, restauro, reatribuição e pedidos concorrentes. Além disso, os temas de blocos passam a ter suporte de primeira classe, enquanto o bbPress continua a usar os seus próprios templates PHP.

Embracing Curiosity in the Age of Machine Intelligence é o nome da apresentação do Porto WordPress Meetup desta semana.

Nesta apresentação, Emīl Blūm partilhará a forma como a curiosidade moldou o seu próprio percurso como designer e explicará como qualquer pessoa se pode aproveitar dela para crescer profissionalmente num contexto de crescentes mudanças profundas tecnológicas.

O evento é quinta-feira, às 19h00, na sede da Kaksi Media, no centro de Matosinhos.

A entrada é gratuita, mas os lugares são limitados e pede-se registo de presença na página do evento no Meetup .com.

Samuel Silva, Gemny Ibarra e Lucas Catão de Moraes juntam-se ao WordPress Day for AI Faro 2026 para falar de três dimensões diferentes da Inteligência Artificial: o que podemos construir com ela, o que ela está a mudar na forma como pensamos e como a podemos usar sem comprometer a segurança.

Já falámos de velocidade, produtividade e do impacto da IA no trabalho de quem cria para a web. Agora damos mais um passo.

Porque a conversa sobre IA no WordPress não se resume a agentes, chatbots ou ferramentas que escrevem código por nós.

Também passa por perceber melhor aquilo que procuramos, saber quando estamos a deixar de pensar por nós próprios e garantir que a velocidade que ganhamos não cria novas vulnerabilidades.

É precisamente esse lado mais amplo da IA que estes três oradores vão trazer a Faro.

E, por fim, este podcast é distribuído sob uma licença Creative Commons como versão derivada do podcast em espanhol; podes encontrar todos os links para mais informação, bem como o podcast noutros idiomas, em WPpodcast .org.

Obrigado por ouvires, e até ao próximo episódio.

Embora o WebMCP ainda seja uma proposta de norma para a Internet, já foi integrado no WordPress Playground para utilização com a aplicação de desktop do ChatGPT, que o suporta.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas, e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras a informação de 7 a 13 de setembro de 2026.

A equipa de lançamento do WordPress 7.2 já foi formada, com Matt Mullenweg de regresso como Release Lead, após uma chamada para voluntários muito concorrida. David Baumwald coordena o lançamento, George Mamadashvili e Peter Wilson são os Tech Leads, e a equipa fica completa com os responsáveis por triagem e testes, além dos responsáveis pelo design e desenvolvimento do novo tema padrão, Twenty Twenty-Seven, liderado por Henrique Iamarino no design e por Maggie Cabrera e Carolina Nymark no desenvolvimento.

Como tem sido norma desde a versão 6.7, a 7.2 mantém o modelo de equipa reduzida, apoiando-se fortemente nos representantes de cada equipa Make para coordenar o trabalho dentro das suas próprias equipas, em vez de centralizar tudo na equipa de lançamento. O interesse dos voluntários ultrapassou largamente os lugares disponíveis, por isso quem não foi selecionado desta vez pode continuar a contribuir através de testes, bug scrubs, triagem ou documentação ao longo do ciclo, que é, na prática, onde aparece a maior parte do trabalho de cada lançamento.

O WordPress Playground suporta agora WebMCP, uma norma ainda em fase de rascunho que permite a uma página web expor ações diretamente como ferramentas que um agente de IA consegue descobrir e utilizar sem sair do navegador.

É uma abordagem diferente do MCP, que se liga a um servidor local ou remoto: o WebMCP funciona dentro da própria página web, sem intermediário. A OpenAI já adicionou suporte para isto no navegador integrado da aplicação de desktop do ChatGPT, com o nome “Site tools”, por isso agora também podes trabalhar com o Playground pedindo-lhe, em linguagem natural, para construir uma landing page ou criar uma demonstração reprodutível de um plugin.

O desafio técnico interessante é que o WordPress corre dentro de um iframe aninhado na página do Playground, e um agente que olhe apenas para a página de nível superior não consegue ver as ferramentas que um plugin regista dentro dessa instância WordPress. A solução é um proxy WebMCP que expõe para o exterior as ferramentas registadas dentro do site e reencaminha as chamadas de volta para dentro, para que um plugin que ofereça, por exemplo, uma ação para criar um rascunho de evento, se torne descobrível e utilizável pelo agente sem ser necessário montar um servidor separado.

A equipa já testou vários fluxos de trabalho reais: construir uma landing page completa de turismo a partir de um único prompt, montar um painel de acompanhamento de compatibilidade com versões do WordPress com cartões editáveis, e transformar as funcionalidades de um plugin em demonstrações interativas que qualquer visitante pode experimentar sem instalar nada.

A equipa de Plugins ativou uma revisão automática de segurança para cada novo lançamento de qualquer plugin no diretório, antes de este ser distribuído através da API de atualizações. Até agora, os novos plugins eram revistos antes de entrarem no diretório, mas as atualizações seguintes não passavam por uma verificação sistemática.

Assim, um plugin que hoje era seguro podia introduzir uma vulnerabilidade ou código malicioso numa versão futura sem que alguém o detetasse a tempo. O gatilho concreto foi um incidente real: a 28 de julho, uma backdoor entrou numa atualização de um plugin com cerca de 20.000 instalações ativas. A revisão automática sinalizou-a, classificou-a como de alto risco e bloqueou a sua distribuição antes de chegar a qualquer site, com o plugin a ser totalmente encerrado 26 minutos depois.

O mecanismo assenta no período de quarentena de seis horas que existe desde junho para cada atualização de plugins e temas. Durante essa janela, vários modelos de IA analisam as alterações de cada lançamento, cruzam os resultados entre si para reduzir falsos positivos e atribuem uma pontuação de risco. Se essa pontuação ultrapassar o limite de alto risco, a distribuição é bloqueada automaticamente, sem depender da disponibilidade de um membro da equipa naquele momento, e todos os autores de plugins são notificados por email com as conclusões específicas. Uma pontuação elevada não implica intenção maliciosa, já que uma vulnerabilidade introduzida sem intenção pode ter uma pontuação tão elevada como um ataque deliberado.

A equipa de Comunidade propôs a criação de um fundo conjunto de patrocínio educativo para estudantes do WPCredits e do WordPress Campus Connect, pensado como um pacote padrão no prospeto de patrocínio dos três principais WordCamps: Ásia, Europa e Estados Unidos. Até agora, isto tem sido tratado caso a caso: o WordCamp US 2025 recebeu dois estudantes do Campus Connect, e o WordCamp Europe 2026 recebeu cinco estudantes do WPCredits, com classificações de 8 a 10 em 10 no relatório de impacto pós-evento. A proposta pretende transformar esse esforço pontual num processo repetível, com um formulário de recomendação preenchido por organizadores ou mentores, e critérios de seleção focados num histórico de contribuição sustentada e na qualidade do perfil WordPress do estudante.

O plano é lançá-lo primeiro como piloto no WordCamp Asia 2027, com um grupo de oito estudantes, uma meta de financiamento de 30.000 dólares e uma contribuição mínima de 3.000 dólares por patrocinador, antes de o expandir para a Europa e os Estados Unidos, se correr bem. Continuam em aberto várias questões: como estruturar o patrocínio em escalões de preço por vaga, onde alojar uma ligação centralizada e disponível todo o ano para o interesse de patrocinadores, em vez de repetir o processo para cada evento, o que acontece se apenas metade das vagas previstas for financiada, e a logística de confirmar os fundos com antecedência suficiente para os estudantes tratarem de voos e vistos.

A organização do WP Day for AI anunciou mais três oradores para o evento: Dave Lockie, Filipa Freitas e Marcel Schmitz.

Dave Lockie vai reduzir ao máximo a distância entre “quero criar uma loja online” e “a minha loja está pronta”. Em vez de uma única abordagem, mostra várias em paralelo, ao vivo, para veres como as ferramentas de IA e os fluxos assistidos estão a acelerar o desenvolvimento de lojas WooCommerce: menos fricção técnica, menos tarefas repetitivas, menos tempo de implementação.

A execução ficou mais rápida. Conteúdos, estruturas, propostas, imagens, wireframes, sites inteiros… tudo em muito menos tempo.

Mas há uma coisa que a IA ainda não resolveu: o cliente. Aliás, trouxe desafios novos.

Hoje o cliente chega com respostas do ChatGPT, soluções geradas por IA, expectativas de entrega quase imediata e aquela pergunta sobre o preço. Filipa Freitas vai explora o impacto da IA na relação entre profissionais e clientes e, sobretudo, na forma como percebemos e comunicamos o valor do nosso trabalho.

Por outro lado, o custo de escrever código caiu a pique. O primeiro instinto de qualquer agência é óbvio: baixar o preço ao cliente.

É provavelmente o erro mais caro que podes cometer este ano, na opinião de Marcel Schmitz, que vai contar que desde há um ano que a Pluginslab entrega todos os projetos com IA no processo: no código, no scoping, na gestão de projeto, nas respostas de suporte. O custo de entrega desceu muito. Os preços não desceram nada. A diferença foi parar a três sítios: à margem; a serviços de entrega rápida, que passaram a ser mais caros porque há clientes que valorizam a velocidade acima de tudo; e a trabalho que antes era recusado por não caber no tempo, e que hoje é uma linha de receita nova.

Os bilhetes para o evento ainda estão disponíveis.

Por fim, este podcast é distribuído sob uma licença Creative Commons como versão derivada do podcast em espanhol. Podes encontrar todas as ligações para mais informação, e o podcast noutros idiomas, em WPpodcast.org.

Obrigado por ouvires, e até ao próximo episódio.

Os ícones que acompanham o WordPress desde a versão 3.8 parecem estar prestes a desaparecer no WordPress 7.2, onde serão substituídos por gráficos vetoriais.

Lembre-se de que pode ouvir este programa no:

Olá, eu sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da Comunidade WordPress.

Neste episódio, encontras a informação de 31 de agosto a 6 de setembro de 2026.

Já existe um calendário para a primeira versão de manutenção da versão atual: o WordPress 7.1.1 chega a 17 de setembro. A própria equipa reconhece que o volume e a gravidade dos problemas reportados nos fóruns, no Trac e no repositório do Gutenberg desde o lançamento da versão 7.1 justificam preparar esta atualização de manutenção com maior antecedência do que é habitual.

Como é normal nestas versões, o 7.1.1 concentra-se exclusivamente na correção de erros: só entram tickets relacionados com regressões introduzidas durante o próprio ciclo do 7.1 ou funcionalidades que tenham sido deliberadamente adiadas para o final desse ciclo. Não haverá novas funcionalidades.

O Gutenberg 23.9 também já está disponível, concentrado sobretudo em pequenas melhorias que tornam a edição do dia a dia mais prática.

Já não precisas de procurar o botão de inserção de blocos quando este está escondido: agora podes adicionar diretamente a partir da própria barra de ferramentas do bloco, pelo que acrescentar outra imagem a uma galeria ou um novo bloco dentro de um grupo deixa de obrigar a mudar a seleção ou a fazer scroll até encontrares o botão.

Os Estilos Globais passam, por sua vez, a apresentar um pequeno indicador em cada bloco que tenha uma substituição de estilo personalizada, com a possibilidade de filtrar e ver de uma só vez apenas os blocos que alteraste manualmente, em vez de teres de os rever um a um.

Entre as restantes novidades, destaca-se a possibilidade de definir espaçamentos horizontais e verticais independentes entre elementos no bloco Grupo, quando este utiliza layouts flexíveis ou em grelha, a capacidade de personalizar o estilo das etiquetas dos formulários através do theme.json e o suporte dos Estilos Globais para citações em bloco, campos de entrada e listas de seleção.

Também podes agora adicionar a tua própria paleta de cores para duotone diretamente a partir do painel de Estilos Globais, em vez de ficares limitado às opções disponibilizadas pelo tema. As restantes alterações dizem respeito sobretudo a melhorias internas de acessibilidade e desempenho, incluindo uma seleção de blocos visivelmente mais rápida em artigos longos.

Está a ser preparado um patch que substitui os Dashicons na barra de administração e no menu lateral pelos novos ícones SVG do WordPress, tirando partido da nova função introduzida no WordPress 7.1.

A razão não é apenas estética: os tipos de letra de ícones, como os Dashicons, apresentam vários problemas de base. Os leitores de ecrã podem anunciá-los de forma imprevisível, uma vez que ocupam pontos de código Unicode sem um significado definido e, por vezes, são lidos como um carácter sem sentido no meio de uma frase.

Também deixam de funcionar corretamente no modo de alto contraste do Windows e noutras configurações de cores forçadas, porque o sistema os trata como texto. Além disso, quando o ficheiro da fonte não carrega ou demora a carregar, surgem caixas ou símbolos estranhos que dão a aparência de um site avariado, enquanto um SVG simplesmente não é apresentado caso falhe o carregamento.

A alteração será bastante visível para os utilizadores, pelo que a equipa está a pedir explicitamente mais feedback do que aquele que recebeu até agora no ticket. Permanecem em aberto alguns detalhes: o ícone de pesquisa fica orientado no sentido oposto ao Dashicon que substitui e o ícone das Entradas poderá deixar de ser um alfinete e passar a ser uma caneta, embora já exista debate sobre qual das opções faz mais sentido.

Os Dashicons surgiram pela primeira vez no WordPress 3.8 Parker, lançado a 12 de dezembro de 2013. Chegaram juntamente com a reformulação da área de administração, o projeto MP6, substituindo os antigos sprites de ícones por uma fonte vetorial, mais nítida em qualquer resolução. A versão inicial incluía 167 ícones e, no WordPress 3.9, foram adicionados mais 30, passando o total para 197.

Um grupo de contribuidores participou numa conversa informal durante a WordCamp US, ao abrigo das regras de Chatham House, sobre a relação do WordPress com a linguagem PHP e com a respetiva comunidade.

O diagnóstico de base é conhecido: uma parte significativa da comunidade PHP não considera os programadores WordPress como programadores PHP “a sério”, em parte porque o compromisso do WordPress com a retrocompatibilidade é visto como um fator que atrasa a própria evolução do PHP, e porque o WordPress participa muito pouco nas discussões onde são decididas novas funcionalidades da linguagem.

Essa mesma janela alargada de compatibilidade também cria dificuldades reais no ecossistema de plugins, já que as dependências externas utilizadas por estes deixam, muitas vezes, de suportar versões de PHP tão antigas como aquelas que o WordPress ainda aceita.

Os dados que mais pesam na discussão são os de adoção: o PHP 7.4 continua a ser utilizado em cerca de 18% dos sites, com poucos incentivos recentes para a atualização além das questões de segurança, já que essas versões antigas deixaram de receber correções.

Foi discutida a possibilidade de promover uma atualização coordenada do lado dos alojamentos, de tornar o PHP 8.x visivelmente mais rápido para que o desempenho se transforme num argumento decisivo e surgiu também uma preocupação de fundo relativamente ao PHP 9: se trouxer alterações significativas à sintaxe, poderá tornar-se impossível manter uma única versão do WordPress compatível simultaneamente com PHP 7.4 e PHP 9.

O resto da conversa incidiu sobre formas de reforçar a relação com o projeto PHP:

Como próximos passos concretos, fala-se em analisar se a distribuição das versões antigas do WordPress sofreu alterações e em explorar a possibilidade de enviar avisos automáticos aos programadores de plugins quando o respetivo código não for compatível com determinada versão do PHP.

A Code Reference estreia exemplos de código realmente executáveis, através do WordPress Playground: o WordPress 7.1 já inclui os dois primeiros, estando previstos mais exemplos para o 7.2.

Nas páginas de referência existe agora um botão “Run”, que executa o fragmento de código diretamente no navegador, sem ser necessário abandonar a documentação nem configurar qualquer ambiente local.

Estes exemplos interativos são definidos diretamente no DocBlock de cada método, dentro do próprio código do WordPress, recorrendo a uma sintaxe ligeiramente diferente da utilizada num exemplo de código convencional. A equipa promete publicar em breve uma página no Handbook com todos os detalhes para quem quiser documentar as suas próprias funções utilizando o mesmo formato.

Está na altura de atualizar os fóruns que utilizam bbPress, uma vez que a versão 2.6.15 corrige cinco falhas de segurança e inclui várias melhorias de compatibilidade.

As correções reforçam as permissões ao editar tópicos e respostas, dividir ou juntar tópicos, atualizar perfis de utilizador e visualizar fóruns privados ou ocultos. A verificação de palavras-passe em importações provenientes de outros sistemas também foi reforçada e foram corrigidos avisos de PHP em alguns pedidos relacionados com fóruns.

Uma das vulnerabilidades tem o seu próprio CVE.

Sofia Correia é a segunda oradora confirmada do WordPress Day for AI Faro 2026.

Especialista em estratégia digital e comunicação vai apresentar uma sessão sobre como a IA resolve o que o cliente não sabe explicar.

Sofia Correia junta-se a Jamie Marsland no leque de oradores, que já tinha sido anunciado.

A fase de apresentação de candidaturas a oradores encerrou a 31 de Agosto e em breve serão anunciados outros oradores e o programa.

Por fim, este podcast é distribuído ao abrigo de uma licença Creative Commons como versão derivada do podcast em espanhol. Podes encontrar todos os links para mais informações, assim como o podcast noutros idiomas, em WPpodcast .org.

Obrigado por ouvires e até ao próximo episódio.

O WordPress está a trabalhar num sistema de encriptação para as credenciais armazenadas no sistema, tanto para APIs de serviços externos como para as utilizadas por outros plugins e ferramentas.

Lembre-se de que pode ouvir este programa no:

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da Comunidade WordPress.

Neste episódio, encontras a informação de 24 a 30 de agosto de 2026.

A comunidade recebeu uma proposta de grande alcance para o WordPress 7.2: uma Secrets API, a primeira forma nativa de armazenar credenciais no WordPress.

Atualmente, qualquer plugin que precise de guardar uma chave de API escreve-a em texto simples na tabela de opções, o que significa que acaba em todas as cópias de segurança, em todos os clones de staging e em todos os terminais partilhados. Com a chegada dos serviços de IA com chaves associadas a modelos de pagamento por utilização, perder uma credencial desta forma deixou de ser um problema menor.

A proposta apresenta funções simples com encriptação obrigatória e sem possibilidade de a desativar, sem qualquer filtro que possa intercetar um segredo em texto simples no momento em que é obtido e com suporte para WP-CLI desde o primeiro dia, precisamente para evitar que as credenciais fiquem expostas no histórico do terminal.

O plano de trabalho é algo invulgar: antes de chegar ao core, será publicado como um plugin autónomo para que a comunidade possa testá-lo em sites reais. Só depois chegará o patch para o core, com uma API idêntica à do plugin. A interface de administração ficará deliberadamente adiada para o WordPress 7.3, para evitar apressar uma decisão de design importante.

A proposta já gerou um debate técnico sério nos comentários, sobretudo por parte de profissionais de alojamento gerido, que explicam que os seus sistemas externos de armazenamento de segredos são apenas de leitura para o WordPress e que a encriptação tem de ser feita nos seus HSM (Hardware Security Module – Módulo de Segurança de Hardware) externos, e não dentro do WordPress. É algo que a proposta atual não resolve bem, porque parte do princípio de que o fornecedor de armazenamento nunca recebe o segredo em texto simples. Continua a ser pedido feedback ativamente e tudo indica que o desenho final poderá mudar consideravelmente em relação a esta primeira versão antes de chegar a um patch efetivo.

É importante explicar que HSM significa Hardware Security Module, isto é Módulo de Segurança de Hardware. É um equipamento físico, dedicado e à prova de violação, usado para gerar, guardar e usar chaves criptográficas com máximo nível de segurança

A equipa de IA confirma dados diretamente relacionados com este tema: a Secrets API para o WordPress 7.2 já foi testada previamente, essencialmente porque é a mesma API que tem sido utilizada há vários meses como experiência de encriptação de chaves dentro do plugin de IA. A equipa alinhou formalmente a favor da sua integração no core no WordPress 7.2, embora peça que a documentação inclua uma forma simples de detetar se a função está disponível, permitindo migrar de forma limpa código antigo que ainda guarda segredos em texto simples.

A equipa de Segurança anunciou a Core Security Initiative, um esforço coordenado que também ajuda a explicar algo que temos observado nas últimas semanas: a avalanche de correções de segurança na série 7.0.

Segundo a própria equipa, o volume de relatórios de segurança cresceu enormemente durante o último ano, em grande parte porque os modelos de IA mais avançados tornam a análise de código em busca de vulnerabilidades cada vez mais acessível.

É algo que está a acontecer em todo o ecossistema de software, não apenas no WordPress. E, segundo a equipa, é um bom problema: mais olhos sobre o código tornam o WordPress mais seguro, mas obrigam a aumentar a capacidade de classificação, validação e resolução desses relatórios.

A iniciativa assenta em três frentes:

O WordPress Playground tornou-se algo consideravelmente mais ambicioso do que uma simples sandbox: agora permite executar qualquer versão histórica do WordPress diretamente no navegador, desde a 0.7 até à 6.2, muito antes da existência do editor de blocos ou da REST API.

A atualização é ativada através de uma nova caixa “Include older versions” no painel de definições e, nos bastidores, realiza um trabalho bastante sofisticado: para as versões do WordPress entre a 0.7 e a 4.9 utiliza uma versão WebAssembly do PHP 5.2.17, enquanto para as versões 5.0 a 6.2 fixa o PHP 7.4, porque estas versões intermédias funcionam de forma mais fiável aí do que em versões modernas do PHP. O seletor mostra até o nome de código de cada versão, pelo que testar o WordPress 2.8 “Baker” é tão simples como escolhê-lo numa lista.

A utilidade prática é evidente para quem desenvolve plugins ou temas:

Um grupo de contribuidores está a desenvolver uma alternativa ao Meetup. com para os grupos da comunidade WordPress, baseada no plugin GatherPress, e já está a pedir ajuda para a testar em Events.WordPress.org.

A ideia é que cada grupo tenha o seu próprio site, onde as pessoas possam aderir e confirmar a presença nos eventos, com os organizadores a gerirem tudo a partir da área pública do site, sem terem de passar pelo painel de administração.

Para testar, basta iniciar sessão no grupo de teste com uma conta WordPress, passando automaticamente a ter a função de “Member”. Existem outras duas funções com mais permissões, “Event Organizer” e “Organizer”, também acessíveis a partir da própria página de membros para quem quiser testar essas áreas.

A equipa pede explicitamente uma primeira impressão geral, em vez de um relatório exaustivo de erros:

Os primeiros comentários já revelaram algumas lacunas interessantes: o editor da descrição dos eventos é bastante mais limitado do que o habitual editor de blocos, o fuso horário do evento não é apresentado, algo importante para eventos online com participantes de vários países, e existe pelo menos um caso em que sair de um grupo não elimina corretamente uma confirmação de presença já guardada para um evento.

Existem também pedidos para a criação de um site de teste em espanhol, uma vez que as equipas de tradução do Meta e da WordCamp já estão a trabalhar nas novas strings.

O WordPress assinou a carta aberta “Open Weights and American AI Leadership”, que apela aos responsáveis políticos dos Estados Unidos para que não imponham restrições prematuras aos modelos de IA de pesos abertos, ou open-weight, aqueles que qualquer pessoa pode descarregar, analisar, modificar e executar na sua própria infraestrutura.

A carta foi publicada a 24 de julho e já conta com mais de 270 empresas e organizações signatárias. O argumento subjacente é o mesmo que qualquer pessoa familiarizada com o código aberto reconhecerá imediatamente: a tecnologia melhora e torna-se mais segura quanto mais pessoas a podem estudar e desenvolver.

Mary Hubbard, CEO do WordPress, enquadra a assinatura precisamente na filosofia que o projeto segue há vinte anos: quem utiliza uma tecnologia deve poder moldá-la de acordo com as suas necessidades, e os modelos de pesos abertos estendem essa mesma liberdade ao domínio da IA.

Entre os pedidos concretos dirigidos aos legisladores estão:

A organização do WordPress Day for AI, agendado para 24 de outubro, em Faro, anunciou o primeiro orador confirmado: Jamie Marsland.

Head do canal do YouTube do WordPress.com mas também com um canal em nome próprio com mais de 200.000 subscritores, Jamie passa os dias a explicar WordPress a pessoas com problemas reais. Já falou em diversos WordCamp, incluindo o WCEU, o WCUS e WC Ásia. Agora vem a Faro.

A sessão que vai apresentar chama-se “From Idea to Product with AI: Building a Canva-Style WordPress Editor and Beyond”. Vai mostrar como a IA o ajudou a construir o Gogh, um editor de páginas ao estilo do Canva para WordPress que guarda tudo em blocos nativos do Gutenberg.

Vai ainda revelar como o mesmo fluxo de trabalho deu origem a uma aplicação de apoio ao cliente, gerou documentação, criou vídeos e artigos, escreveu textos de marketing e fechou o ciclo, transformando conversas com utilizadores em melhorias concretas do produto.

Por fim, este podcast é distribuído sob uma licença Creative Commons como versão derivada do podcast em espanhol. Podes encontrar todos os links para mais informações, assim como o podcast noutros idiomas, em WPpodcast.org.

Obrigado por ouvires e até ao próximo episódio.