WP Composer: um repositório Composer independente para substituir o WPackagist no teu workflow WordPress

Durante mais de uma década, o WPackagist foi praticamente o caminho padrão para instalar plugins e temas do WordPress via Composer. Funcionava, era familiar, e encaixava bem em projetos com deployments reprodutíveis.

O problema é que este tipo de serviço não é “só mais uma dependência”: é uma peça central do workflow moderno de WordPress com Composer. E quando a infraestrutura passa a ser controlada por uma única empresa, a comunidade perde margem de manobra sobre disponibilidade, direção do projeto e até decisões que podem acabar por ser tomadas fora do espaço público.

Em março de 2026, o WPackagist foi adquirido pela WP Engine (empresa de alojamento com apoio de private equity). Esse contexto acelerou a necessidade de uma alternativa independente. A resposta foi o WP Composer, um repositório Composer para plugins e temas WordPress, totalmente open source e financiado pela comunidade, construído e mantido pela Roots.

Porque isto é relevante para quem desenvolve WordPress

O WPackagist começou por ser desenvolvido pela Outlandish e foi mantido durante anos. Com o tempo, ganhou sinais de pouca manutenção: atualizações mais lentas, suporte limitado e pouca ou nenhuma participação significativa da comunidade no rumo do projeto.

Com a aquisição, as preocupações aumentaram: quando tooling fundamental passa a depender de uma única organização, decisões sobre disponibilidade, eventual monetização e prioridades podem migrar para “salas de reuniões”, em vez de acontecerem de forma aberta.

Há também um ponto prático sobre transparência: o repositório GitHub histórico do WPackagist (https://github.com/outlandishideas/wpackagist) já não reflete necessariamente o que está a correr no site em produção, o que torna mais difícil auditar e confiar no comportamento real do serviço.

A proposta do WP Composer é clara: um serviço transparente, financiado pela comunidade e construído por pessoas que vivem este workflow há muito tempo.

O que o WP Composer disponibiliza (e como se usa no composer.json)

O WP Composer disponibiliza todos os plugins e temas gratuitos do diretório WordPress.org, instaláveis via Composer e com um naming scheme mais limpo e previsível.

{
  "repositories": [
    {
      "name": "wp-composer",
      "type": "composer",
      "url": "https://repo.wp-composer.com",
      "only": ["wp-plugin/*", "wp-theme/*"]
    }
  ],
  "require": {
    "wp-plugin/woocommerce": "^10.0",
    "wp-theme/twentytwentyfive": "^1.0"
  }
}

{
  "repositories": [
    {
      "name": "wp-composer",
      "type": "composer",
      "url": "https://repo.wp-composer.com",
      "only": ["wp-plugin/*", "wp-theme/*"]
    }
  ],
  "require": {
    "wp-plugin/woocommerce": "^10.0",
    "wp-theme/twentytwentyfive": "^1.0"
  }
}

Aqui há duas decisões importantes:

• Plugins usam o prefixo wp-plugin/*.
• Temas usam o prefixo wp-theme/*.

Isto elimina os prefixos wpackagist-plugin e wpackagist-theme, tornando a lista de dependências mais legível e alinhada com o que efetivamente estás a instalar.

O WP Composer é também o repositório recomendado para trabalhar em conjunto com pacotes de core mantidos pela Roots: roots/wordpress, roots/wordpress-full e roots/wordpress-no-content. Num projeto típico com Bedrock, é comum usar roots/wordpress para o core e o WP Composer para plugins e temas.

Migração a partir do WPackagist (passo a passo)

A troca é direta e, na prática, resume-se a remover pacotes antigos, apontar o Composer para o novo repositório e voltar a requerer as dependências com o naming atualizado.

1) Remover os pacotes do WPackagist

composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive

composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive

2) Trocar o repositório configurado no Composer

composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com

composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com

3) Voltar a requerer os pacotes com a nova convenção wp-plugin/<em> e wp-theme/</em>

composer require wp-plugin/woocommerce wp-theme/twentytwentyfive

composer require wp-plugin/woocommerce wp-theme/twentytwentyfive

Alternativa: script de migração automático

Se preferires automatizar a atualização do composer.json, existe um script de migração que faz o trabalho por ti (inclui troca de naming e ajustes necessários):

curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh

curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh

Para quem usa GitHub Actions para acompanhar updates de plugins, a action anteriormente conhecida como WPackagist Changelog Action foi renomeada para WP Composer Changelog Action e suporta totalmente o novo formato wp-plugin/<em> e wp-theme/</em>.

Performance: porque o WP Composer tende a resolver dependências muito mais depressa

A grande diferença técnica aqui é o suporte ao protocolo Composer v2 metadata-url. Em termos práticos, isto permite ao Composer descarregar metadados apenas dos pacotes necessários para resolver as tuas dependências.

O WPackagist, por outro lado, usa a abordagem mais antiga provider-includes, que obriga o Composer a descarregar ficheiros de índice grandes com metadados de milhares de pacotes antes sequer de conseguir fazer o resolution de dependências. O resultado típico é mais tempo “a puxar índices” e menos tempo a fazer o que realmente interessa.

Tempos de resolução (Composer resolve times)

Medição: cold resolve (sem cache). Quanto mais baixo, melhor.

• 10 plugins: WP Composer 0.7s vs WPackagist 12.3s (≈ 17x mais rápido)
• 20 plugins: WP Composer 1.1s vs WPackagist 19.0s (≈ 17x mais rápido)

Metadados e caching

• Composer v2 metadata-url: WP Composer Yes; WPackagist No
• CDN caching: WP Composer public, max-age=300; WPackagist no-cache, private
• Ficheiros por pacote: WP Composer usa ficheiros imutáveis, endereçados por conteúdo (content-addressed) e com cache indefinida; WPackagist não é content-addressed

Os benchmarks foram corridos a partir de uma única localização usando Composer 2.7+. Naturalmente, os resultados podem variar consoante a região e as condições de rede. Os scripts de benchmark estão disponíveis em open source: https://github.com/roots/wp-composer/tree/main/benchmarks.

Open source a sério: código, docs e deploy

O WP Composer é totalmente open source: código da aplicação, documentação e configuração de deployment estão no GitHub, em https://github.com/roots/wp-composer. Isto inclui a possibilidade de contribuições e também a opção de qualquer pessoa fazer fork e correr a sua própria instância, se precisar.

Financiamento pela comunidade (e independência do tooling)

A sustentabilidade do WP Composer é feita através da comunidade, via GitHub Sponsors: https://github.com/sponsors/roots. O objetivo é manter a infraestrutura, o desenvolvimento e a manutenção do repositório sem depender de uma única entidade com controlo total sobre o serviço.

Para quem depende de Composer no dia a dia em projetos WordPress (especialmente em stacks como Bedrock), ter um repositório independente, auditável e com um modelo de financiamento comunitário reduz risco operacional e melhora previsibilidade a médio/longo prazo.