WP Composer: neatkarīgs Composer repozitorijs WordPress spraudņiem un tēmām kā alternatīva WPackagist
WordPress projektos, kur spraudņus un tēmas pārvaldi ar Composer, repozitorijs faktiski kļūst par daļu no piegādes ķēdes (supply chain). Ilgu laiku de facto standarts bija WPackagist – daudziem tas vienkārši bija “tas repozitorijs, ko ieliek composer.json un aizmirst”. Taču situācija ir mainījusies, un līdz ar to ir vērts pārskatīt savu iestatījumu.
2026. gada martā WPackagist nonāca WP Engine (privātā kapitāla atbalstīta hostinga uzņēmuma) īpašumā. Kad tik centrāla infrastruktūra WordPress + Composer darbplūsmai tiek kontrolēta vienas komercorganizācijas rokās, rodas gan ilgtermiņa neatkarības, gan caurspīdīguma jautājumi – īpaši, ja lēmumi par pieejamību, cenu politiku vai virzienu var tikt pieņemti aiz slēgtām durvīm.
Šajā kontekstā parādījies WP Composer – neatkarīgs, kopienas finansēts un pilnībā atvērtā koda Composer repozitorijs WordPress spraudņiem un tēmām. To veido un uztur Roots komanda, un mērķis ir skaidrs: nodrošināt alternatīvu, kas ir pārskatāma, uzturēta un nav pakļauta viena uzņēmuma kontrolei.
Kāpēc šis ir svarīgi WordPress izstrādātājiem, kas izmanto Composer
WPackagist savulaik izveidoja Outlandish un tas gadiem ilgi darbojās kā stabila bāze WordPress spraudņu/tēmu instalēšanai caur Composer. Tomēr vēlākā periodā uzturēšana kļuva gausa: atjauninājumi bija lēni, uzturēšana ierobežota, un kopienas iesaiste – minimāla. Pēc iegādes bažas tikai pieauga, jo īpaši ap atvērtā koda principiem un projekta atbilstību tam, ko redzam publiskajos repozitorijos.
Papildu signāls: WPackagist publiskais GitHub repozitorijs vairs neatspoguļo to, kas reāli strādā “dzīvajā” servisā. Ja rīks ir kritisks ikdienas build procesam, izstrādātājiem ir svarīgi saprast, kas tieši tiek palaists, kā tas tiek izvērsts un kādi ir uzturēšanas principi.
WP Composer pozicionējas kā tieši pretējs modelis: caurspīdīgs, kopienas finansēts, ar pilnībā publisku kodu un iespēju ikvienam izveidot savu instanci, ja rodas nepieciešamība.
Tehniskai salīdzināšanai (veiktspēja, metadati un atšķirības) ir sagatavota arī atsevišķa lapa: WP Composer vs WPackagist.
Ko tieši nodrošina WP Composer
WP Composer ideja ir praktiska: dot iespēju instalēt katru bezmaksas spraudni un tēmu no WordPress.org direktorijas caur Composer, bet ar sakārtotu un paredzamu package naming (pakotņu nosaukumdošanu).
Galvenā izmaiņa, ko uzreiz jutīsi ikdienā: spraudņiem tiek izmantots prefikss wp-plugin/<em>, bet tēmām – wp-theme/</em>. Tas nozīmē, ka vairs nav jādzīvo ar vēsturiskajiem wpackagist-plugin un wpackagist-theme nosaukumiem.
{
"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"
}
}
Svarīga nianse: only filtrs ļauj skaidri nodefinēt, ka šis repozitorijs paredzēts tieši spraudņu un tēmu paketēm, nevis jebkam citam.
Saderība ar Roots WordPress core pakotnēm un Bedrock tipisku uzbūvi
Ja tev projektā ir Roots ekosistēma, WP Composer ir paredzēts kā rekomendētais repozitorijs lietošanai kopā ar WordPress core pakotnēm: roots/wordpress, roots/wordpress-full un roots/wordpress-no-content.
Tipisks Bedrock projekts izmanto roots/wordpress WordPress kodolam, savukārt spraudņi un tēmas nāk no WP Composer. Rezultāts: strukturēts dependency management un mazāk “roku darba” serveru vidēs, kur visu gribi reproducēt no composer.lock.
Migrācija no WPackagist uz WP Composer
Pāreja pēc būtības ir trīs soļi: (1) noņem vecās wpackagist-<em> pakotnes, (2) nomaini repozitorija ierakstu, (3) pieprasi tās pašas pakotnes ar jauno wp-plugin/</em> un wp-theme/* naming.
1) Noņem WPackagist pakotnes
composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive
2) Nomaini repozitoriju konfigurāciju
composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com
3) Pievieno pakotnes ar jauno nosaukumdošanu
composer require wp-plugin/woocommerce wp-theme/twentytwentyfive
Automātiska composer.json atjaunošana ar migrācijas skriptu
Ja ir vairāki projekti vai composer.json ir apjomīgs, var izmantot gatavu migrācijas skriptu, kas automātiski atjauno failu:
curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh
Ja izmanto GitHub Action spraudņu atjauninājumu izsekošanai, ir pārdēvēts arī iepriekšējais WPackagist Changelog Action – tagad tas ir WP Composer Changelog Action ar pilnu atbalstu wp-plugin/<em> un wp-theme/</em> formātam.
Veiktspēja: kāpēc WP Composer dependency resolve ir tik jūtami ātrāks
WP Composer izmanto Composer v2 metadata-url protokolu, kas ļauj Composer klientam ielādēt metadatus tikai tām pakotnēm, kuras patiešām ir vajadzīgas konkrētajā dependency resolve procesā. Pretstatā tam, WPackagist joprojām balstās uz vecāko provider-includes pieeju – tur Composer ir spiests vispirms lejupielādēt lielus indeksu failus ar metadatiem par tūkstošiem pakotņu, pirms vispār var sakārtot atkarības.
Composer resolve laiki (cold resolve)
Cold resolve (bez cache) – jo mazāk, jo labāk:
- 10 spraudņi: WP Composer 0.7s, WPackagist 12.3s – 17x ātrāk
- 20 spraudņi: WP Composer 1.1s, WPackagist 19.0s – 17x ātrāk
Metadati un kešošana (caching)
- Composer v2
metadata-url: WP Composer – Yes, WPackagist – No - CDN caching: WP Composer –
public, max-age=300, WPackagist –no-cache, private - Faili uz pakotni (per-package files): WP Composer – immutable, content-addressed, cache uz nenoteiktu laiku; WPackagist – nav content-addressed
Par benchmarkiem
Mērījumi tika veikti no vienas lokācijas, izmantojot Composer 2.7+. Reālie rezultāti var atšķirties atkarībā no reģiona un tīkla apstākļiem. Benchmark skripti ir publiski: https://github.com/roots/wp-composer/tree/main/benchmarks.
Pilnībā atvērtā koda projekts (un iespēja palaist savu instanci)
WP Composer nav “melna kaste”. Lietotnes kods, dokumentācija un deployment konfigurācija ir atvērtā koda un pieejama GitHub: https://github.com/roots/wp-composer. Praktiski tas nozīmē divas lietas: (1) kopiena var iesaistīties ar pull requestiem un uzlabojumiem, (2) jebkurš var forknēt projektu un palaist savu instanci, ja organizācijā ir prasība pēc pilnas kontroles.
Kopienas finansējums kā neatkarības pamats
Serviss tiek finansēts pilnībā no kopienas caur GitHub Sponsors: https://github.com/sponsors/roots. Šis modelis tieši atbalsta infrastruktūru, izstrādi un uzturēšanu – un vienlaikus palīdz saglabāt repozitoriju neatkarīgu un brīvi pieejamu.
Ja Composer ir būtiska WordPress izstrādes darba plūsmas daļa (īpaši CI/CD un reproducējamu buildu kontekstā), neatkarīga infrastruktūra nav “nice to have” – tā ir riska samazināšana ilgtermiņā.
Īsais kopsavilkums
- WP Composer ir neatkarīgs, kopienas finansēts un pilnībā atvērtā koda Composer repozitorijs WordPress spraudņiem un tēmām.
- Pakotņu nosaukumdošana ir vienkāršāka:
wp-plugin/<em>spraudņiem unwp-theme/</em>tēmām. - Migrācija no WPackagist ir tieša: noņem vecās pakotnes, nomaini repozitoriju un pieprasi pakotnes ar jauno naming (vai izmanto migrācijas skriptu).
- Veiktspēja ir būtiski labāka, jo tiek izmantots Composer v2
metadata-urlprotokols un gudrāka kešošana. - Viss projekts ir publisks GitHub, un uzturēšana balstās kopienas finansējumā caur GitHub Sponsors.
Noderīgas saites: WP Composer, repo endpoints: https://repo.wp-composer.com, salīdzinājums: https://wp-composer.com/wp-composer-vs-wpackagist, un diskusija Roots Discourse: https://discourse.roots.io/t/-/30235.
Ieva Ozoliņa
E-pasta mārketinga un automatizācijas speciāliste. Klaviyo un mārketinga automatizācija ir mani favorīti. Personalizēta klientu pieredze visos kanālos.
Visas publikācijas
