WP Composer: niezależny zamiennik dla WPackagist w workflow z Composerem

Przez ponad dekadę WPackagist był domyślnym sposobem na instalowanie wtyczek i motywów z katalogu WordPress.org za pomocą Composera. W marcu 2026 sytuacja się zmieniła: WPackagist został przejęty przez WP Engine (hosting wspierany przez private equity). Dla narzędzia, które jest tak centralnym elementem „WordPress + Composer workflow”, oznacza to realne ryzyko zamknięcia decyzji (dostępność, kierunek, potencjalne opłaty) w ramach jednej firmy.

W odpowiedzi powstał WP Composer – niezależne, w pełni open source repozytorium Composera dla wtyczek i motywów WordPressa. Projekt jest budowany i utrzymywany przez Roots, a finansowany wyłącznie przez społeczność.

Dlaczego to w ogóle ma znaczenie?

WPackagist został pierwotnie zbudowany przez Outlandish i przez lata utrzymywany w dobrym stanie. Z czasem jednak projekt zaczął cierpieć na typowe problemy „osieroconej infrastruktury”: wolniejsze aktualizacje, ograniczone utrzymanie i brak realnego wpływu społeczności na kierunek rozwoju. Przejęcie przez WP Engine tylko spotęgowało te obawy.

Jest też aspekt transparentności: nie jest jasne, czy WPackagist pozostaje w pełni otwartym oprogramowaniem w praktyce – publiczne repozytorium GitHub (https://github.com/outlandishideas/wpackagist) nie odzwierciedla już działania produkcyjnej wersji serwisu. A gdy fundamentalne narzędzie deweloperskie przestaje być rozwijane „na oczach wszystkich”, społeczność traci głos.

WP Composer celuje dokładnie w te słabe punkty: ma być transparentny, społecznościowo finansowany i rozwijany przez ludzi, którzy od lat budują nowoczesny stack dla WordPressa.

Jeśli chcesz porównać różnice w detalach (wydajność, metadane i różnice w podejściu), jest gotowe zestawienie: full comparison of WP Composer vs WPackagist.

Co dokładnie daje WP Composer?

Najważniejsze: każda darmowa wtyczka i motyw z katalogu WordPress.org jest dostępna do instalacji przez Composer – z czystym nazewnictwem paczek.

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

Konwencja jest prosta i przewidywalna: wtyczki instalujesz jako wp-plugin/<em>, a motywy jako wp-theme/</em>. To usuwa wcześniejsze prefiksy wpackagist-plugin i wpackagist-theme, które przez lata były po prostu „historycznym balastem” w konfiguracjach projektów.

WP Composer jest też rekomendowany jako repozytorium do użycia razem z paczkami WordPress core od Roots: roots/wordpress, roots/wordpress-full oraz roots/wordpress-no-content. W typowym projekcie na Bedrock spotkasz układ: roots/wordpress dla core oraz WP Composer dla wtyczek i motywów.

Migracja z WPackagist (krok po kroku)

Przejście jest mechaniczne i sprowadza się do podmiany repozytorium oraz nazewnictwa paczek. Najczęstszy scenariusz to trzy komendy:

1) Usuń paczki WPackagist z projektu

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

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

2) Podmień repozytorium w konfiguracji Composera

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) Dodaj zależności w nowym formacie nazewnictwa

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

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

Jeżeli wolisz zautomatyzować zmianę w composer.json, jest gotowy skrypt migracyjny, który aktualizuje konfigurację automatycznie: migration script.

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

Dodatkowo, jeśli korzystasz z GitHub Action do śledzenia aktualizacji wtyczek, to akcja została przemianowana z WPackagist Changelog Action na WP Composer Changelog Action i w pełni wspiera nowe nazwy wp-plugin/<em> i wp-theme/</em>.

Wydajność: dlaczego resolve w Composerze potrafi być o rząd wielkości szybszy

WP Composer wspiera protokół metadata-url z Composera v2. W praktyce oznacza to, że Composer pobiera metadane tylko dla tych paczek, których naprawdę potrzebuje do rozwiązania zależności. WPackagist bazuje na starszym podejściu provider-includes, które zmusza Composera do pobierania dużych plików indeksów zawierających metadane dla tysięcy paczek jeszcze zanim zacznie sensownie rozwiązywać Twoje wymagania.

Czasy resolve (Composer 2) – cold resolve, bez cache

Wyniki poniżej dotyczą cold resolve (brak cache). Im niżej, tym lepiej.

• 10 wtyczek: WP Composer 0.7s vs WPackagist 12.3s – 17× szybciej
• 20 wtyczek: WP Composer 1.1s vs WPackagist 19.0s – 17× szybciej

Metadane i cache’owanie

• Composer v2 metadata-url: WP Composer – tak, WPackagist – nie
• CDN caching: WP Composer – public, max-age=300, WPackagist – no-cache, private
• Pliki per-paczka: WP Composer – immutable, content-addressed, cache’owane bezterminowo; WPackagist – nie jest content-addressed

W pełni open source (i możliwy self-hosting)

Kod aplikacji, dokumentacja i konfiguracja wdrożeniowa WP Composer są w całości dostępne na GitHubie: https://github.com/roots/wp-composer. Projekt przyjmuje kontrybucje, a jeśli chcesz, możesz sforkować repozytorium i uruchomić własną instancję.

Finansowanie przez społeczność

WP Composer jest finansowany w 100% przez społeczność przez GitHub Sponsors: https://github.com/sponsors/roots. To finansowanie pokrywa infrastrukturę, rozwój i utrzymanie WP Composer oraz szerzej – ekosystem Roots.

Jeśli Twoje projekty WordPressowe realnie polegają na Composerze (wtyczki, motywy, powtarzalne deploye), taki model finansowania jest też sposobem na utrzymanie niezależności narzędzia: https://github.com/sponsors/roots.

Podsumowanie: co warto zapamiętać

• WPackagist po przejęciu w marcu 2026 stał się elementem infrastruktury kontrolowanym przez jedną firmę, co rodzi ryzyka dla całego workflow „WordPress + Composer”.
• WP Composer to niezależne repozytorium Composera dla wtyczek i motywów z WordPress.org, rozwijane przez Roots, w pełni open source i finansowane przez społeczność.
• Nowe, czyste nazwy paczek (wp-plugin/<em>, wp-theme/</em>) upraszczają konfiguracje i migracje.
• Wsparcie metadata-url w Composer v2 oraz sensowne cache’owanie przekładają się na znacznie krótsze czasy resolve w porównaniu do WPackagist.
• Migracja jest prosta: usuwasz stare paczki, podmieniasz repozytorium, dodajesz zależności w nowym formacie (albo uruchamiasz skrypt migracyjny).