WP Composer: il repository Composer open source e indipendente per plugin e temi WordPress (alternativa a WPackagist)
Per più di dieci anni, WPackagist è stato la scelta “di default” per installare plugin e temi WordPress via Composer (il dependency manager PHP usato per dichiarare e risolvere dipendenze in modo riproducibile). Era comodo: puntavi un repository Composer, richiedevi wpackagist-plugin/<em> o wpackagist-theme/</em> e via.
Nel marzo 2026, WPackagist è stato acquisito da WP Engine (hosting sostenuto da private equity). Quando un’infrastruttura così centrale per il workflow WordPress+Composer finisce sotto il controllo di una singola azienda, il tema non è solo “chi paga i server”: è governance, trasparenza e capacità della community di influenzare direzione, disponibilità e scelte operative.
Da qui nasce WP Composer: un repository Composer indipendente, finanziato dalla community e completamente open source, costruito e mantenuto da Roots. L’obiettivo è semplice: offrire una base trasparente e affidabile per consumare via Composer tutto ciò che sta su WordPress.org (plugin e temi gratuiti), senza dipendere da un singolo attore commerciale.
Perché questa storia conta davvero (anche se “funziona già tutto”)
WPackagist era nato in casa Outlandish ed è stato mantenuto per anni. Nella fase più recente, però, molti developer hanno percepito segnali tipici dei progetti “trascurati”: aggiornamenti lenti, manutenzione limitata e scarso spazio a input significativi della community. L’acquisizione da parte di WP Engine ha amplificato queste preoccupazioni: se un tool fondamentale viene governato da una singola corporation, decisioni su disponibilità, pricing e direzione rischiano di spostarsi dalle discussioni aperte alle sale riunioni. Inoltre, c’è anche un tema di trasparenza tecnica: il repository GitHub storico di WPackagist (https://github.com/outlandishideas/wpackagist) non rispecchia più chiaramente lo stato del servizio live.
WP Composer si posiziona come alternativa con tre caratteristiche nette: trasparenza, finanziamento comunitario e sviluppo/gestione in mano a persone che lavorano su questo ecosistema da molto tempo. Per un confronto dettagliato su performance, metadati e differenze operative: WP Composer vs WPackagist.
Cosa offre WP Composer (e cosa cambia nel day‑to‑day)
WP Composer pubblica ogni plugin e tema gratuito presenti nel directory ufficiale WordPress.org, rendendoli installabili via Composer con una convenzione di naming più pulita:
{
"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"
}
}
- I plugin usano il prefisso *
wp-plugin/</em>**. - I temi usano il prefisso *
wp-theme/</em>**. - Non servono più i prefissi
wpackagist-pluginewpackagist-theme.
In più, WP Composer è indicato come repository consigliato accanto ai pacchetti WordPress core mantenuti da Roots: roots/wordpress, roots/wordpress-full e roots/wordpress-no-content. Nel setup tipico di un progetto Bedrock, l’idea è usare roots/wordpress per il core e WP Composer per plugin e temi.
Migrazione da WPackagist: comandi essenziali (e script automatico)
Il passaggio è lineare: rimuovi i pacchetti con il vecchio naming, sostituisci il repository e poi richiedi gli stessi componenti con il nuovo formato.
1) Rimuovi i pacchetti WPackagist
composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive
2) Sostituisci il repository
composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com
3) Richiedi i pacchetti con il nuovo naming
composer require wp-plugin/woocommerce wp-theme/twentytwentyfive
Se preferisci automatizzare l’aggiornamento del tuo composer.json, è disponibile uno script di migrazione che applica le modifiche in modo automatico: https://github.com/roots/wp-composer/blob/main/scripts/migrate-from-wpackagist.sh
curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh
Nota per chi usa CI/CD: se ti appoggiavi alla GitHub Action per tracciare gli aggiornamenti dei plugin, l’azione è stata rinominata da “WPackagist Changelog Action” a WP Composer Changelog Action, con supporto completo al naming wp-plugin/<em> e wp-theme/</em>.
Performance: perché WP Composer può velocizzare in modo drastico Composer
Sul piano tecnico, uno dei punti più interessanti è il supporto di WP Composer al protocollo metadata-url di Composer v2. In pratica, Composer può scaricare i metadati solo dei pacchetti che ti servono davvero.
WPackagist, invece, resta sull’approccio più vecchio provider-includes, che forza Composer a scaricare grossi file indice con metadati di migliaia di pacchetti prima ancora di poter risolvere correttamente le dipendenze.
Tempi di resolve (cold, senza cache)
Nei benchmark riportati (eseguiti da una singola location con Composer 2.7+), i tempi di risoluzione “a freddo” mostrano un salto importante: valori più bassi sono migliori.
- Con 10 plugin: WP Composer 0.7s vs WPackagist 12.3s → 17x più veloce
- Con 20 plugin: WP Composer 1.1s vs WPackagist 19.0s → 17x più veloce
Benchmark e variabilità
I risultati possono variare in base a regione e condizioni di rete. Gli script di benchmark sono pubblici: https://github.com/roots/wp-composer/tree/main/benchmarks
Metadati e caching: differenze pratiche
- Supporto Composer v2
metadata-url: WP Composer sì, WPackagist no - Caching via CDN: WP Composer usa header
public, max-age=300, WPackagistno-cache, private - File per-pacchetto: WP Composer usa file immutabili, content-addressed, cacheabili indefinitamente; WPackagist non usa content-addressing
Completamente open source (nel senso operativo del termine)
WP Composer non è solo un endpoint da consumare: l’intero progetto – codice applicativo, documentazione e configurazione di deployment – è pubblicato su GitHub: https://github.com/roots/wp-composer Questo significa che chiunque può contribuire, ma anche fare fork e avviare una propria istanza se necessario. In termini di resilienza dell’ecosistema, è una differenza enorme rispetto a servizi opachi o difficili da riprodurre.
Finanziamento dalla community: come resta indipendente
Il modello dichiarato è community-funded: WP Composer viene finanziato tramite GitHub Sponsors, e le sponsorizzazioni sostengono direttamente infrastruttura, sviluppo e manutenzione del repository e, più in generale, dell’ecosistema Roots. Se in azienda o in agenzia usi Composer per gestire WordPress in modo serio (Bedrock o setup simili), il punto non è solo “supportare un progetto”: è mantenere indipendente e disponibile un pezzo di tooling che sta nel mezzo della supply chain del tuo deploy.
- Pagina GitHub Sponsors: https://github.com/sponsors/roots
- Sito di WP Composer: https://wp-composer.com
Giulia Romano
Appassionata di data science e machine learning. Mi interessano Python, TensorFlow e la visualizzazione dei dati. Credo nel processo decisionale basato sui dati.
Tutti gli articoliAltro da Giulia Romano
FAIR e repository federati per WordPress: perché Joost de Valk lascia il progetto (e cosa cambia per plugin e temi)
CVE-2026-1357 in WPvivid Backup: upload di file arbitrari e rischio RCE (ma solo se usi la chiave “send to site”)
WordPress punta di nuovo a tre major release nel 2026: si apre la pianificazione per la 7.0 (AI Client, admin redesign e PHP minimo)