O WordPress definiu um conjunto claro de princípios e passos para determinar se um projeto deve ser alojado ou migrado para a sua organização oficial no GitHub.
Remember that you can listen to this program from Pocket Casts, Spotify, and Apple Podcasts or subscribe to the feed directly.
Transcrição do programa
Olá, eu sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da Comunidade WordPress.
Neste episódio, vais encontrar as informações de 1 a 8 de junho de 2025.
O WordPress definiu um conjunto claro de princípios e passos para decidir se um projeto merece ser alojado ou migrado para a sua organização oficial no GitHub. O objetivo principal é garantir a propriedade comunitária e a qualidade, o que significa que apenas repositórios que tragam valor ao ecossistema, com código acessível e bem gerido, serão considerados candidatos.
Para integrar a organização, um projeto terá de cumprir três grupos principais de requisitos:
- O primeiro ponto é a documentação e objetivos claros, devendo existir um ficheiro README ou uma publicação no blog Make WordPress a definir claramente o problema que resolve e os seus objetivos, bem como atualizações periódicas do seu estado.
- O segundo ponto é o patrocínio e manutenção, com pelo menos um colaborador ativo pertencente a uma equipa de contribuidores reconhecida — idealmente com várias pessoas — garantindo a continuidade do projeto, devidamente indicado no README e num ficheiro CODEOWNERS.
- O terceiro ponto é o compromisso com o suporte e as boas práticas, respondendo rapidamente a pedidos e bugs, seguindo os standards de código do WordPress, mantendo documentação acessível e cumprindo com as licenças (GPL) e o código de conduta da Comunidade.
Uma vez aceite, existem regras quanto ao ciclo de vida e segurança:
- Por exemplo, se um repositório ficar órfão ou sem manutenção e não for um plugin canónico, será arquivado após seis meses sem resposta, podendo ser reaberto se surgir uma nova pessoa para o manter.
- Apenas os repositórios explicitamente incluídos na política do HackerOne estarão abrangidos pelo programa de recompensas, embora qualquer bug crítico deva ser imediatamente tratado em coordenação com a equipa de segurança.
- Além disso, projetos experimentais ou ferramentas internas devem ter etiquetas e expectativas de suporte distintas para evitar confundir utilizadores finais com componentes ainda em desenvolvimento.
Tudo isto insere-se na estratégia de que o lançamento de novas funcionalidades no WordPress deve depender menos do ‘core’ e mais de plugins funcionais, que permitem testar e validar ideias que poderão futuramente ser incluídas no próprio WordPress.
Novidades no Gutenberg
As versões 20.4 e 20.5 do Gutenberg já estão disponíveis com várias novidades importantes.
No Gutenberg 20.4, foi introduzida uma preferência persistente do utilizador para a opção “Mostrar modelo” no editor. Adicionalmente, o bloco Query Loop passa a permitir ordenar o conteúdo de acordo com a ordem de menu.
No Gutenberg 20.5, os blocos criados com o pacote “create-block” passam agora a incluir um manifesto de bloco com metadados, melhorando a performance no carregamento. Além disso, o painel de pré-publicação deixa de apresentar sugestões de etiquetas ou categorias caso nenhuma tenha sido adicionada.
Novo plugin canónico de performance
A equipa de Performance lançou o plugin canónico View Transitions, que implementa a nova API CSS View Transitions para transições suaves de página durante a navegação entre URLs em sites WordPress. Em vez do habitual “flash” ao trocar de página, o plugin aplica por omissão um efeito de desvanecimento (“fade”) entre o estado antigo e o novo do DOM, proporcionando uma experiência mais fluida.
Após a criação da nova equipa de IA (Inteligência Artificial), dedicada a explorar aberta e responsavelmente como a IA pode melhorar a experiência WordPress, a sua fase inicial irá focar-se na criação de um conjunto de plugins canónicos e ferramentas de base que preparem o terreno para uma eventual integração no core.
Para o seu funcionamento, a equipa irá seguir uma estrutura aberta:
- reuniões quinzenais,
- planeamento,
- código em repositórios públicos no GitHub,
- e decisões tomadas através de revisões de pull requests e propostas formais.
A equipa de Testes identificou uma falha no atual fluxo de trabalho do WordPress. Quando alguém testa uma correção de bug — um patch — e o teste passa, essa pessoa adiciona a etiqueta dev-feedback para informar os programadores de que o patch está pronto. O problema é que a maioria dos testers não faz uma revisão aprofundada do código, deixando os programadores incertos se a etiqueta representa ou não uma revisão técnica rigorosa. Como resultado, muitos programadores ignoram estes avisos, a não ser que venham de testers reconhecidos por fazerem revisões de código detalhadas, tornando os restantes relatórios praticamente inúteis.
Como solução, propõe-se a introdução de uma nova etiqueta, needs-code-review. Com isto, testers que apenas fazem testes funcionais podem assinalar que é necessária uma revisão completa do código, enquanto aqueles que realizarem uma revisão técnica rigorosa poderão continuar a usar dev-feedback. Assim, os programadores conseguem rapidamente perceber quais os patches que já passaram por uma análise profunda e quais ainda precisam de revisão adicional antes de avançarem para produção.
WordCamp Europa 2025
O WordCamp Europe 2025 encerrou no passado sábado em Basileia, com 1.723 participantes presenciais de 84 países e mais de 20.000 participantes online, após três dias intensos que começaram com um Contributor Day que contou com 640 participantes distribuídos por 21 equipas.
Como é habitual nos WordCamp Europe, Matt Mullenweg, desta vez acompanhado por Mary Hubbard, dedicou meia hora a discutir projetos e o ecossistema WordPress, respondendo depois a questões da audiência.
Entre os temas em destaque estiveram os regulamentos europeus sobre proteção de dados e cibersegurança, o lançamento do FAIR Project, e o projeto Campus Connect, onde, em Itália, 5.000 estudantes irão obter créditos universitários ao contribuírem com 150 horas de trabalho para o WordPress, embora não tenham sido ainda detalhados os processos de integração dos estudantes na comunidade e tarefas.
Tudo o que se relaciona com o Five for the Future recebeu bastante atenção, quer nas sessões de debate e perguntas, quer durante o WP Café realizado na mesma manhã com a presença da Mary.
Se não pudeste assistir ao evento, estão disponíveis mais de 6.000 fotos para explorares os participantes e os momentos-chave.
No próximo ano, o WordCamp Europe 2026 terá lugar em Cracóvia, Polónia, de 4 a 6 de junho.
Anunciados dois novos eventos em Portugal
Ainda no âmbito do WordCamp Europa 2025, foram submetidas propostas de dois novos eventos em Portugal para os próximos 12 meses.
Para 15 de novembro está prevista a realização no Porto de um WordPress Day dedicado ao comércio eletrónico. Trata-se de um evento de um dia único e temático, exclusivamente relacionado com e-commerce.
Tem contornos diferentes de um WordCamp e um grande foco na qualidade do conteúdo. Terá um limite máximo de 100 participantes.
O segundo evento anunciado foi o WordCamp Portugal 2026. Na sequência do WordCamp Lisboa 2025, um conjunto de organizadores ativos da comunidade portuguesa de WordPress abordou a ideia de alterar a denominação do principal evento anual em Portugal.
Assim, vai nascer o WordCamp Portugal, que substitui as designações de WordCamp Lisboa e WordCamp Porto.
O primeiro WordCamp Portugal vai decorrer no Porto em Maio do próximo ano.
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 noutras línguas, em WPpodcast.org.
Obrigado por estares desse lado, até ao próximo episódio.
Deixe um comentário