WP Packages od Roots: open source Composer dla WordPressa w 2026

#Co Roots faktycznie wypuścił

W marcu 2026 zespół Roots (Scott Walkinshaw, Ben Word i kontrybutorzy) wypuścił WP Packages na wp-packages.org. Mirror obejmuje każdą darmową wtyczkę i motyw z katalogu WordPress.org i serwuje je jako repozytorium Composer JSON.

Premiera nie poszła gładko. Projekt wystartował we wtorek jako “WP Composer”. Do piątku Nils Adermann (współtwórca Composera, kontrybutor specyfikacji SemVer) skontaktował się sygnalizując, że Composer to zastrzeżony znak towarowy projektu Composer. Roots zmienił nazwę w weekend, zachował stare URL-e wp-composer.org odpowiadające 410 z notką o deprecation i wypuścił aktualizację skeletonu Bedrocka, żeby nowe projekty wskazywały na nowy host. To rodzaj incydentu, który u korporacyjnego dostawcy zająłby sześć tygodni przeglądu prawnego. W open-source naprawia się to zanim post mortem trafi na bloga.

#composer.json zastępujący twój dashboard

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wp-packages.org"
    }
  ],
  "require": {
    "php": ">=8.2",
    "wp-packages/advanced-custom-fields": "^6.3",
    "wp-packages/woocommerce": "^9.4",
    "wp-packages/wordpress-seo": "^23.0"
  }
}

composer install rozwiązuje drzewo, zapisuje composer.lock i pobiera ZIP-y do web/app/plugins/ (układ Bedrocka) lub wp-content/plugins/ (waniliowy WordPress z composer/installers). Na projekcie Bedrock z 25 wtyczkami warm-cache install schodzi w 30 do 90 sekund. Cold cache, brak katalogu cache Composera, świeży runner CI: 2 do 4 minut, głównie czas pobierania. Ta liczba zaczyna mieć znaczenie kiedy composer install ląduje w każdym buildzie PR-a.

#Co tak naprawdę daje self-hosting

Self-hosting WP Packages to jedyna funkcja której WPackagist nie ma. Trzy realne scenariusze gdzie się zwraca, w polskim kontekście:

• Audyt łańcucha dostaw. Klienci enterprise (banki, firmy ubezpieczeniowe, jednostki sektora publicznego z wymogami KSC) wymagają, żeby każda zależność była serwowana z infrastruktury którą kontrolują. Z WP Packages forkujesz projekt, mirrorujesz na wewnętrzny endpoint w cyber_Folks Cloud, OVH lub Atman dedykowanym, i twój composer.json nie rozmawia już z zewnętrznym hostem podczas deploya.
• Środowiska air-gapped. Jenkins albo GitLab Runner w sieci klienta z izolacją od internetu nie dosięgnie wpackagist.org ani wp-packages.org. Z self-hostowanym WP Packages plus lokalny cache Composera, pipeline jest “offline-clean”.
• Customowe filtrowanie. Realny przykład polskiej agencji: zablokowali wtyczki nieaktualizowane od ponad 18 miesięcy. Sforkowali WP Packages, dodali filtr na etapie indeksowania, i composer require na nieaktualnej wtyczce wywala teraz jasny błąd zamiast cicho instalować porzucony kod.

Dla większości polskich agencji WPackagist wystarczy. Powyższe to przypadki, w których przestaje wystarczać.

#WPackagist: nadal default i jest powód

WPackagist prowadzi Outlandish, brytyjska kooperatywa. Mirroruje katalog WordPress.org od 2013 roku z bardzo nielicznymi awariami. Konwencja nazw pakietów (wpackagist-plugin/woocommerce, wpackagist-theme/twentytwentyfour) stała się de facto standardem; każdy polski tutorial Bedrocka napisany przed marcem 2026 (głównie 10Clouds tech blog, posty na blog.10clouds.com) zakłada WPackagist.

#Side-by-side

#Kiedy się przesiąść, a kiedy nie

Przesiądź się na WP Packages jeśli potrzebujesz self-hostingu, ustandaryzowałeś się na całym stacku Roots i preferujesz wsparcie od jednego dostawcy, albo dostałeś opóźnienia synchronizacji WPackagista które zepsuły build i chcesz drugi mirror jako backup. Zostań na WPackagist jeśli twoje CI jest zielone, composer.lock jest powtarzalny, a “zmigrujmy prefiks na 200 stronach klienckich” nie jest u nikogo na roadmapie.

Te dwa się nie wykluczają. Nic nie stoi na przeszkodzie żeby zadeklarować oba repozytoria i przypiąć konkretne wtyczki do konkretnych mirrorów. To prawdopodobnie skończy się jako standard u większości agencji.

#Bedrock, Sage, Trellis: gdzie Composer się faktycznie zwraca

Stack Roots to powód dla którego Composer-na-WordPressie wydaje się natywny, a nie przyspawany.

#Bedrock: układ projektu

Bedrock to skeleton projektu, nie framework. Co realnie robi:

• Wyciąga rdzeń WordPressa do web/wp/ (zarządzany przez Composera), więc wp-config.php jest cienkim loaderem, nie kanonicznym plikiem konfiguracji.
• Przenosi całą konfigurację środowiskową do .env (czytane przez vlucas/phpdotenv) i config/environments/{development,staging,production}.php. Stała WP_ENV decyduje który plik środowiskowy się ładuje.
• Traktuje web/app/plugins/, web/app/themes/ i web/app/mu-plugins/ jako cele instalacji Composera przez composer/installers.
• Dostarcza autoloader mu-plugins/register-theme-directory.php, więc composer require na motywie faktycznie rejestruje go w WordPressie.

.env jest w gitignore. Sekrety produkcyjne żyją w menedżerze sekretów (Vault, 1Password, AWS Secrets Manager), nie w wp-config.php. To kontrakt który sprawia, że WP_DEBUG, klucze licencyjne ACF Pro i credentiale do bazy są bezpieczne per-środowisko, zamiast “czy ktoś znowu wypchnął zły wp-config.php na staging?”.

composer create-project roots/bedrock moj-projekt
cd moj-projekt
cp .env.example .env
# edytuj .env z lokalnymi credentialami DB i WP_ENV=development
composer install

Polski hosting pod Bedrocka: cyber_Folks ma SSH i Composera natywnie na pakietach Premium SSD i wyżej. Atman dedykowany z Plesk/cPanel pozwala wgrać własną wersję Composera. Mydevil ma Composera od pakietu MyDevil S i dokumentację dla Bedrocka. Zenbox i nazwa.pl wymagają hostingu wirtualnego z dostępem SSH (nie wszystkie pakiety go mają). Hekko ma SSH na pakietach Pro i wyżej. Generalnie unikaj hostingów współdzielonych bez SSH; w 2026 Composer-build-na-serwerze to antywzorzec.

#Sage 10 do Sage 11: podatek migracyjny

Sage to motyw od Roots. Sage 11 (wypuszczony 2024) wprowadził Acorn, kontener w stylu Laravel działający wewnątrz WordPressa, plus szablony Blade zamiast czystego PHP. Migracje Sage 10 do Sage 11 mają specyficzne tryby awarii warte poznania zanim się zapiszesz:

• Acorn breaking changes. Akcje hookowane przez mechanizm service provider Acorna odpalają się później niż te same hooki rejestrowane w functions.php. Kod zakładający priorytet 10 na hooku init może wymagać przeniesienia na priorytet 20 albo do innego hooka.
• Blade vs PHP templates. single.blade.php zamiast single.php. Stare wywołania get_template_part nadal działają ale omijają pipeline Blade i tracą mechanikę section/yield.
• Pipeline assetów. Sage 10 używał Bud (wrapper Webpack 5); Sage 11 przeszedł na Vite. Konfiguracje Bud nie są przenośne. Twój tailwind.config.js jest, ale uważaj na różnice kolejności pluginów PostCSS.

Migracja nie jest na jeden klik. Zarezerwuj dwa dni na mały motyw, tydzień na cokolwiek z customowymi blokami Gutenberga.

#Trellis: opcja której prawdopodobnie nie potrzebujesz

Trellis to Ansible plus Vagrant do lokalnego developmentu i provisioningu zdalnego. Buduje serwery Ubuntu LTS z Nginx, MariaDB, PHP-FPM, Redis i pipeline’em deploya. Realnie: Trellis jest świetny dla agencji z własną infrastrukturą (50 do 200 stron na dedykach na OVH, Atman albo nazwa.pl Cloud Server) i przesadą dla wszystkich innych. Jeśli deployujesz na zarządzany WordPress hosting (cyber_Folks Cloud, WP Engine, Kinsta), Trellis to nie jest właściwe narzędzie. Jeśli zarządzasz własną flotą DigitalOcean czy Hetznera, jest.

#Tryby awarii o których nikt nie wspomina we wstępie

To cztery sposoby na które composer install rujnuje komuś popołudnie.

#Drift wersji PHP między lokalnym a CI

composer require rozwiązuje względem wersji PHP którą widzi dziś. Wtyczka oznaczona "php": ">=8.2" instaluje się dobrze na laptopie z PHP 8.3. Środowisko stagingowe zamrożone na PHP 8.1 wywali composer install z mało pomocnym błędem platform-requirement. Zapnij config.platform.php w composer.json na najniższą wersję jaką uruchamia jakiekolwiek środowisko:

{
  "config": {
    "platform": {
      "php": "8.2.20"
    }
  }
}

Ta jedna linia uratowała więcej deployów niż jakakolwiek optymalizacja CI. Szczególnie istotna w kontekście polskich hostingów współdzielonych, gdzie PHP 8.1 i 8.2 wciąż są domyślne na cyber_Folks i Mydevil w 2026.

#mu-plugins/register.php załadowany przeciw złej wersji WordPressa

Autoloader Bedrocka w mu-plugins/ uruchamia się w czasie boota PHP, przed inicjalizacją rdzenia WordPressa. Jeśli zrobisz composer update rdzenia WordPressa do wersji która zmieniła semantykę WP_PLUGIN_DIR (zdarzyło się w WP 6.5), autoloader może rejestrować katalogi motywów które już nie istnieją. Symptom: białe okno na produkcji, OK na stagingu. Naprawa: zapnij roots/wordpress na znaną dobrą wersję minor i bumpuj świadomie.

#Aktywacja licencji ACF Pro w środowiskach deploya

ACF Pro autentykuje swoją licencję względem advancedcustomfields.com. Buildy artefaktów deploya (Bitbucket Pipelines, GitHub Actions) działają jako świeży kontener bez DOM, bez sesji admina, z IP którego serwer licencji ACF nigdy nie widział. Flow aktywacji który działa w wp-admin nie działa w runnerze CI. Naprawy które faktycznie działają w 2026:

• Użyj proxy Roots Premium jeśli jesteś na planie organizacji Roots (pośredniczy w licencjach ACF Pro i innych wtyczek premium przez Composera).
• Ustaw ACF_PRO_LICENSE jako zmienną środowiskową czytaną przez API PHP ACF i pomiń flow aktywacji w dashboardzie zupełnie.
• Użyj HTTP basic auth Composera (auth.json) do autentykacji względem oficjalnego endpointu Composera ACF na connect.advancedcustomfields.com.

Pierwsze dwie to jedyne które przeżyją migrację serwera bez ręcznej interwencji.

#Niekompatybilność lockfile Composer 2.7 vs Composer 2.6

Composer 2.7 zmienił sposób zapisywania platform overrides w composer.lock. composer.lock zapisany przez 2.7 wywala instalację na 2.6 z mylącym błędem “the lock file is not up to date”. Ustandaryzuj wersję Composera w CI (composer self-update 2.7.7) i udokumentuj w README. Tak, to denerwujące. Tak, ugryzło dość zespołów że Composer 2.8 będzie ostrzegał o tym jawnie.

#Wtyczki premium: część którą docs przemilczają

Połowa wtyczek na realnej stronie klienckiej nie jest w katalogu WordPress.org. ACF Pro, Gravity Forms, WP Migrate, GP Premium, FacetWP, WP All Import Pro. Wsparcie Composera bardzo się różni:

• ACF Pro: oficjalny endpoint Composera na connect.advancedcustomfields.com. Działa dobrze, wymaga auth.json z kluczem licencyjnym jako hasłem.
• Gravity Forms: oficjalne wsparcie Composera od 2023. Klucz licencyjny w auth.json, nazwa pakietu gravityforms/gravityforms.
• GP Premium (GeneratePress): brak oficjalnego endpointu Composera. SatisPress albo proxy Roots Premium.
• WP Migrate Pro (Delicious Brains, teraz WP Engine): pobieranie ZIP-a z URL-em zamkniętym licencją. Custom repozytorium Composera deklarujące pakiet jako typ package z URL-em inline, albo proxy przez SatisPress.
• WP All Import Pro: brak endpointu Composera. ZIP-y na URL-u zamkniętym licencją. SatisPress albo commit ZIP-a do prywatnego repozytorium.

Trzy wzorce pokrywają wszystko powyższe:

1. Roots Premium (roots.io/premium). Zarządzany proxy Composera obsługujący licencje dla ACF Pro, Gravity Forms i innych. Cennik indywidualny; dla agencji obsługujących 50+ stron matematyka się zwykle spina.
2. SatisPress. Wtyczka WordPress zamieniająca twoją instalację WordPressa w repozytorium Composera. Instalujesz wtyczki premium normalnie, eksponujesz przez https://twoj-prywatny-host/satispress/, zabezpieczasz HTTP basic auth.
3. Private Packagist od packagist.com. Hostowane repozytorium Composera z obsługą prywatnych pakietów. Kosztuje więcej niż SatisPress, wymaga zerowej infrastruktury.

Cokolwiek wybierzesz, zasada jest: klucze licencyjne nigdy nie idą do composer.json ani auth.json zacommitowanego do gita. Żyją w zmiennych środowiskowych czytanych w czasie instalacji, albo w sekretach CI wstrzykiwanych do auth.json w fazie buildu.

#Integracja CI która przeżywa kontakt z rzeczywistością

Działający pipeline deploya:

# .github/workflows/deploy.yml (fragment)
- name: Set up PHP 8.2
  uses: shivammathur/setup-php@v2
  with:
    php-version: '8.2'
    tools: composer:2.7

- name: Cache Composer
  uses: actions/cache@v4
  with:
    path: ~/.composer/cache
    key: composer-${{ hashFiles('composer.lock') }}

- name: Install
  run: composer install --no-dev --optimize-autoloader --prefer-dist --no-interaction
  env:
    COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH_JSON }}

- name: Deploy artifact
  run: rsync -avz --delete --exclude='.git' --exclude='node_modules' ./ deploy@host:/var/www/html/

Trzy zasady oszczędzające czas debugowania:

• Nigdy nie uruchamiaj composer update w CI. Aktualizuj lokalnie, commituj nowy composer.lock, push. CI uruchamia composer install przeciwko dokładnie temu lockfile’owi.
• Cachuj ~/.composer/cache na hashu composer.lock. Zimne instalacje schodzą z 4 minut do 30 sekund.
• Wstrzykuj auth.json z sekretu. Zmienna środowiskowa COMPOSER_AUTH jest czytana przez Composera natywnie. Nigdy nie commituj credentiali licencjonowanych.

#Co się zmieniło w kulturze WordPressa w 2026

Composer-na-WordPressie był kiedyś sprawą “tylko-dla-shopów-Roots”. W 2026 jest defaultem dla każdej polskiej agencji albo zespołu in-house deployującego do więcej niż jednego środowiska. Trzy sygnały z szerszego ekosystemu:

• Zgłoszenia wtyczek do WordPress.org przekroczyły 500 tygodniowo na początku 2026, wzrost ze 100 do 150 tygodniowo w latach 2022 do 2024 (źródło: tygodniowe raporty Plugin Review Team). Większość nowego wolumenu to kod wspomagany AI. Zespół Pluginów rekrutuje wolontariuszy-recenzentów; pasek jakości katalogu jest pod presją.
• Zarówno Kinsta, jak i WP Engine dodały natywne wsparcie buildu Composera do swoich deployów Git push pod koniec 2025. Kategoria “managed WordPress hosting ignorujący composer.json” się kurczy. cyber_Folks Cloud poszedł podobną drogą w pierwszym kwartale 2026.
• WP-CLI 2.10 dodał subkomendy wp composer opakowujące composer install, composer update i walidację lockfile. Composer staje się częścią oficjalnej powierzchni WP-CLI.

Lekcja dla zarządzania wtyczkami-jako-zależnościami: tooling dojrzewa szybciej niż capacity recenzenckie katalogu WordPress.org. Self-hostowalny mirror jak WP Packages jest bardziej użyteczny w tym kontekście niż byłby pięć lat temu, kiedy katalog był zamkniętym ogrodem któremu wszyscy domyślnie ufali.

#Ostatnia aktualizacja: 2026-04-01

Potrzebujesz pomocy z migracją strony do Bedrocka albo skonfigurowaniem pipeline’u deploya ze sterowaniem przez Composera? Sprawdź nasze usługi WordPress development.