WP Composer: nepriklausomas WPackagist pakaitalas WordPress įskiepiams ir temoms per Composer

Daugiau nei dešimtmetį WPackagist buvo numatytasis kelias, kai reikėdavo WordPress įskiepius ir temas diegti per Composer (t. y. PHP priklausomybių valdiklį, kuris leidžia versijuoti ir automatizuoti diegimą kaip bet kurioje modernioje PHP aplikacijoje). Tai tapo de facto standartu tiek Bedrock tipo projektuose, tiek bet kuriuose repo-driven WordPress diegimuose, kur norisi aiškios priklausomybių kontrolės.

2026 m. kovą WPackagist buvo įsigytas WP Engine – privataus kapitalo remiamos hostingo kompanijos. Kai tokio lygio infrastruktūra atsiduria vienos korporacijos rankose, atsiranda reali rizika visai WordPress kūrėjų ekosistemai: sprendimai dėl prieinamumo, krypties ar net kainodaros gali būti priimami už uždarų durų, o ne viešai ir bendruomeniškai. Dėl to Roots komanda sukūrė alternatyvą – WP Composer.

Kas yra WP Composer ir kuo jis skiriasi

WP Composer – nepriklausomas, bendruomenės finansuojamas, visiškai atviro kodo Composer repozitorijos sprendimas, skirtas WordPress.org katalogo nemokamiems įskiepiams ir temoms. Jį kuria ir prižiūri Roots.

Čia svarbūs du principai: (1) skaidrumas ir atviras valdymas, (2) praktiškumas kasdieniam naudojimui – nuo metaduomenų pateikimo iki našumo, kai Composer sprendžia priklausomybes (resolve).

Kodėl tai svarbu WordPress kūrėjams

WPackagist istorija gerai parodo, kas nutinka, kai kritinis įrankis tampa „tiesiog kažkieno palaikomas“: vėlyvuoju laikotarpiu projektas kentėjo nuo apleistos priežiūros, lėtų atnaujinimų ir ribotų galimybių bendruomenei realiai įsitraukti. Įsigijimas iš esmės tik padidino šiuos nuogąstavimus.

Papildomas signalas – neaiškumas dėl atviro kodo realybės: WPackagist GitHub repozitorija (https://github.com/outlandishideas/wpackagist) nebėra patikimas indikatorius, kas iš tiesų veikia produkcijoje, nes ji, panašu, nebeatitinka gyvos svetainės.

WP Composer idėja paprasta: reikia alternatyvos, kuri būtų skaidri, finansuojama bendruomenės ir kurią kurtų žmonės, turintys ilgalaikę patirtį moderniame WordPress stack’e.

Jei norisi detaliau palyginti techninius niuansus (našumą, metaduomenis ir skirtumus), Roots pateikia išsamų palyginimą: https://wp-composer.com/wp-composer-vs-wpackagist.

Ką suteikia WP Composer

WP Composer repozitorijoje yra kiekvienas nemokamas įskiepis ir tema iš WordPress.org katalogo, kuriuos galima diegti per Composer. Didelis praktinis patogumas – švarus paketų vardinimas:

{
  "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"
  }
}

Įskiepiai naudoja wp-plugin/<em>, temos – wp-theme/</em>. Tai reiškia, kad nebereikia istorinių wpackagist-plugin ir wpackagist-theme prefiksų, kurie ilgainiui tapo triukšmu composer.json faile ir automatizacijoje.

WP Composer taip pat yra rekomenduojamas repozitorijos pasirinkimas, jei naudoji Roots WordPress core paketus: roots/wordpress, roots/wordpress-full ir roots/wordpress-no-content. Tipinis Bedrock projektas WordPress branduoliui ima roots/wordpress, o įskiepiams ir temoms – WP Composer.

Migracija iš WPackagist: komandos ir automatinis skriptas

Perėjimas iš WPackagist į WP Composer yra gana tiesus – realiai tai keli Composer veiksmai: pašalini senus paketus, pakeiti repozitoriją ir vėl įsirašai tuos pačius įskiepius/temas su nauju vardinimu.

1) Pašalink WPackagist paketus

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

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

2) Pakeisk repozitoriją į WP 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) Pridėk paketus su nauju wp-plugin/<em> ir wp-theme/</em> vardinimu

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

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

Jei nori automatizuoti composer.json pakeitimus, yra paruoštas migracijos skriptas, kuris atnaujina konfigūraciją automatiškai:

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

Dar viena detalė tiems, kas automatizuoja įskiepių atnaujinimų sekimą CI/CD: GitHub Action, anksčiau žinomas kaip WPackagist Changelog Action, pervadintas į WP Composer Changelog Action ir pilnai palaiko naują wp-plugin/<em> bei wp-theme/</em> formatą.

Našumas: kodėl WP Composer resolve yra žymiai greitesnis

Didžiausias techninis skirtumas – metaduomenų pateikimo protokolas. WP Composer palaiko Composer v2 metadata-url protokolą, leidžiantį Composer atsisiųsti metaduomenis tik tiems paketams, kurių realiai reikia tavo projektui. Tuo tarpu WPackagist vis dar remiasi senesniu provider-includes metodu, kai Composer priverstas atsisiųsti didelius indeksų failus su tūkstančių paketų metaduomenimis dar prieš išspręsdamas priklausomybes.

Composer resolve laikai (cold resolve, be cache)

Žemiau – „cold resolve“ matavimai (be cache). Mažesnis laikas yra geriau:

• 10 įskiepių: WP Composer 0.7s, WPackagist 12.3s (17x greičiau)
• 20 įskiepių: WP Composer 1.1s, WPackagist 19.0s (17x greičiau)

Metaduomenys ir cache elgsena

• Composer v2 metadata-url: WP Composer – Yes, WPackagist – No
• CDN caching: WP Composer – public, max-age=300, WPackagist – no-cache, private
• Per-package failai: WP Composer – immutable, content-addressed, cached indefinitely; WPackagist – not content-addressed

Visiškai atviras kodas: gali fork’inti ir paleisti savo instanciją

WP Composer aplikacijos kodas, dokumentacija ir deployment konfigūracija yra viešai prieinami GitHub: https://github.com/roots/wp-composer. Praktinė šio fakto vertė – ne tik galimybė prisidėti pull request’ais, bet ir tai, kad bet kas gali fork’inti projektą ir paleisti savo instanciją, jei atsirastų poreikis.

Bendruomenės finansavimas: kaip išlaikomas nepriklausomumas

WP Composer išlaikomas vien bendruomenės lėšomis per GitHub Sponsors: https://github.com/sponsors/roots. Tokia finansavimo schema tiesiogiai apmoka infrastruktūrą, kūrimą ir priežiūrą – ir kartu padeda išlaikyti įrankį nepriklausomą bei laisvai prieinamą.

Jei tavo WordPress vystymo procese Composer yra kertinis įrankis (ypač Bedrock ar panašiuose setup’uose), Roots rėmimas per GitHub Sponsors yra tiesiausias būdas prisidėti prie šios infrastruktūros stabilumo.

Trumpa santrauka: kada verta pereiti

• Jei WordPress įskiepius ir temas valdai per Composer, WP Composer duoda švaresnį vardinimą (wp-plugin/<em>, wp-theme/</em>).
• Jei composer install/update laikas pradeda erzinti, metadata-url palaikymas ir cache strategija gali duoti apčiuopiamą pagreitį.
• Jei tau svarbi įrankių nepriklausomybė ir skaidrumas, atviro kodo repo + bendruomenės finansavimas yra stiprus argumentas.