WP Packages fra Roots: open source Composer-repository for WordPress 2026

#Hva Roots faktisk leverte

I mars 2026 lanserte Roots-teamet (Scott Walkinshaw, Ben Word og bidragsytere) WP Packages på wp-packages.org. Det speiler hver gratis plugin og tema fra WordPress.org-katalogen og leverer dem som et Composer JSON-repository.

Lanseringen gikk ikke knirkefritt. Prosjektet ble lansert tirsdag som “WP Composer”. Innen fredag hadde Nils Adermann (Composer-medskaper, også bidragsyter til SemVer-spesifikasjonen) tatt kontakt for å varsle om at Composer er et registrert varemerke som tilhører Composer-prosjektet. Roots omdøpte i helgen, holdt eksisterende wp-composer.org URL-er i drift med 410 og deprecation-melding, og pushet en Bedrock-mal-oppdatering slik at nye prosjekter pekte mot det omdøpte hostet. Dette er typen hendelse som hos en bedriftsleverandør ville tatt seks uker juridisk gjennomgang. Open-source-prosjekter fikser det før postmortem-bloggposten lander.

#composer.json som erstatter dashboardet ditt

{
  "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 løser så et tre, skriver composer.lock og laster ned ZIP-er til web/app/plugins/ (Bedrock-layout) eller wp-content/plugins/ (vanlig WordPress med composer/installers). På et 25-plugin Bedrock-prosjekt går warm-cache install på 30 til 90 sekunder. Cold cache, ingen Composer-cache-katalog, fersk CI-runner: 2 til 4 minutter, hovedsakelig nedlastingstid. Det tallet begynner å bety noe når composer install lenkes inn i hver PR-build.

#Hva self-hosting faktisk gir deg

Self-hosting av WP Packages er den ene funksjonen WPackagist ikke matcher. Tre reelle scenarioer fra det norske markedet hvor det betaler seg:

• Kommunale anskaffelser og leverandørkjedeaudit. Kommune.no-domener, helseforetak og statlige etater har anskaffelseskrav som forlanger at hver avhengighet leveres fra infrastruktur de kontrollerer. Med WP Packages forker du prosjektet, speiler det til et internt endepunkt på Bahnhof, Eviny Cloud eller Domeneshop VPS, og composer.json-en din snakker ikke lenger med en tredjepartsvert under deploy.
• BankID-eksponerte staging-miljøer. Når en bank eller forsikringsleverandør tester en WordPress-side mot BankID i staging, er nettverkssegmentet lukket. Jenkins eller GitLab Runner inne i banknettet når verken wpackagist.org eller wp-packages.org. Med self-hostet WP Packages pluss en lokal Composer-cache er deploy-pipelinen offline-clean.
• Tilpasset filtrering. Et reelt eksempel fra et Oslo-byrå: plugins som ikke har blitt oppdatert på over 18 måneder ble blokkert fra installasjon på intern infrastruktur. De forket WP Packages, la til filteret ved indekseringstid, og composer require på en utdatert plugin feiler nå med en klar feilmelding i stedet for å stille installere forlatt kode.

For de fleste team holder WPackagist. Ovennevnte er tilfellene hvor det slutter å holde.

#WPackagist: fortsatt default og det av en grunn

WPackagist drives av Outlandish, en britisk samvirkebedrift. Det har speilet WordPress.org-katalogen siden 2013 med svært få avbrudd. Pakkenavnkonvensjonen (wpackagist-plugin/woocommerce, wpackagist-theme/twentytwentyfour) ble de facto-konvensjonen; nesten hver Bedrock-tutorial skrevet før mars 2026 antar WPackagist.

#Side om side

#Når bytte, når ikke

Bytt til WP Packages hvis du trenger self-hosting, hvis du allerede har standardisert på hele Roots-stacken og foretrekker single-vendor-support, eller hvis du har truffet en WPackagist-sync-forsinkelse som ødela et build og vil ha et andre speil som backup. Bli på WPackagist hvis CI er grønt, composer.lock er reproduserbar og “la oss migrere vendor-prefikset på 200 kundesider” ikke er på noens veikart.

De to utelukker ikke hverandre. Ingenting hindrer deg i å deklarere begge repositorier og pinne spesifikke plugins til spesifikke speil. Det er det de fleste byråer kommer til å ende opp med i praksis.

#Bedrock, Sage, Trellis: hvor Composer faktisk betaler seg

Roots-stacken er grunnen til at Composer-på-WordPress føles innfødt i stedet for påskrudd.

#Bedrock: prosjektoppsettet

Bedrock er et prosjektskjelett, ikke et rammeverk. Hva det faktisk gjør:

• Splitter WordPress-kjernen inn i web/wp/ (Composer-styrt), slik at wp-config.php er en tynn loader i stedet for den kanoniske konfigurasjonsfilen.
• Flytter all miljøkonfigurasjon til .env (lest av vlucas/phpdotenv) og config/environments/{development,staging,production}.php. WP_ENV-konstanten styrer hvilken miljøfil som lastes.
• Behandler web/app/plugins/, web/app/themes/ og web/app/mu-plugins/ som Composer-installasjonsmål via composer/installers.
• Leveres med en mu-plugins/register-theme-directory.php autoloader, slik at composer require på et tema faktisk registrerer det med WordPress.

.env er gitignored. Produksjonshemmeligheter lever i hemmelighetshåndteringssystemet (HashiCorp Vault, AWS Secrets Manager), ikke i wp-config.php. Det er kontrakten som gjør WP_DEBUG, ACF Pro lisensnøkler og databasecredentials trygge per miljø, i stedet for “har noen pushet feil wp-config.php til staging igjen?”.

composer create-project roots/bedrock mitt-prosjekt
cd mitt-prosjekt
cp .env.example .env
# rediger .env med lokale DB-credentials og WP_ENV=development
composer install

Norsk hosting for Bedrock: ServeBolt har offisielt Bedrock-støtte og WP-CLI på alle planer, med dedikert dokumentasjon for Composer-deploy. Domeneshop VPS gir deg root-tilgang for vilkårlig toolchain-konfigurasjon. PRO ISP har SSH og Composer på Pro-tariffene. Webhuset støtter Composer på Premium og oppover. UnoEuro (eieren har norsk virksomhet, men hosting er dansk) har SSH på Pro-planene og oppover. Generelt: unngå delt hosting uten SSH; i 2026 er Composer-build-på-server et antimønster.

#Sage 10 til Sage 11: migrasjonsskatten

Sage er Roots-temaet. Sage 11 (utgitt 2024) brakte Acorn, en Laravel-aktig container som kjører inni WordPress, pluss Blade-templates i stedet for ren PHP. Sage 10 til Sage 11-migrasjoner har spesifikke feilmoduser verdt å kjenne før du melder deg på:

• Acorn breaking changes. Hooks registrert gjennom Acorns service provider-mekanisme avfyres senere enn de samme hookene registrert i functions.php. Kode som antok init-prioritet 10 må kanskje flyttes til prioritet 20 eller en annen hook.
• Blade vs PHP-templates. single.blade.php i stedet for single.php. Gamle get_template_part-kall fungerer fortsatt men omgår Blade-pipelinen og mister section/yield-mekanikken.
• Asset-pipeline. Sage 10 brukte Bud (Webpack 5-wrapper); Sage 11 flyttet til Vite. Bud-konfigurasjonsfiler er ikke portable. tailwind.config.js-en din er det, men pass på forskjeller i PostCSS-plugin-rekkefølgen.

Migrasjonen er ikke ett trykk. Sett av to dager for et lite tema, en uke for noe med tilpassede Gutenberg-blokker.

#Trellis: alternativet du sannsynligvis ikke trenger

Trellis er Ansible pluss Vagrant for lokal utvikling og fjernprovisjon. Det bygger Ubuntu LTS-servere med Nginx, MariaDB, PHP-FPM, Redis og en deploy-pipeline. Klart språk: Trellis er utmerket for byråer som eier sin egen infrastruktur (50 til 200 sider på Hetzner-dedikerte eller Domeneshop VPS-er) og overkill for alle andre. Hvis du deployer til managed WordPress hosting (ServeBolt, Kinsta, WP Engine), er Trellis ikke riktig verktøy. Hvis du driver din egen DigitalOcean- eller Hetzner-flåte, er det.

#Feilmoduser ingen nevner i innledningen

Dette er de fire måtene composer install ødelegger noens ettermiddag.

#PHP-versjonsdrift mellom lokalt og CI

composer require løser mot PHP-versjonen den ser i dag. En plugin merket "php": ">=8.2" installerer fint på laptopen din som kjører PHP 8.3. Et staging-miljø frosset på PHP 8.1 vil feile composer install med en lite hjelpsom platform-requirement-feil. Pin config.platform.php i composer.json til den laveste versjonen noen miljø kjører:

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

Denne ene linjen redder flere deploy enn noen CI-optimalisering. Spesielt relevant for norske delte hostere hvor PHP 8.1 og 8.2 fortsatt er default på eldre Webhuset- og PRO ISP-tariffer i 2026.

#mu-plugins/register.php lastet mot feil WordPress-versjon

Bedrocks mu-plugins/-autoloader kjører ved PHP-oppstartstid, før WordPress-kjernen initialiseres. Hvis du composer update WordPress-kjernen til en versjon som endret semantikken til WP_PLUGIN_DIR (skjedde i WP 6.5), kan autoloaderen registrere temakataloger som ikke lenger eksisterer. Symptom: hvit skjerm i produksjon, OK på staging. Fiks: lås roots/wordpress til en kjent god minor og bump bevisst.

#ACF Pro lisensaktivering i deploy-miljøer

ACF Pro autentiserer lisensen sin mot advancedcustomfields.com. Deploy-artefakt-bygg (Bitbucket Pipelines, GitHub Actions) kjører som en fersk container uten DOM, uten admin-sesjon og med en IP ACF-lisensserveren aldri har sett. Aktiveringsflyten som fungerer i wp-admin fungerer ikke i en CI-runner. Fikser som faktisk fungerer i 2026:

• Bruk Roots Premium proxy hvis du er på en Roots organisasjonsplan (den megler ACF Pro og andre premium-lisenser gjennom Composer).
• Sett ACF_PRO_LICENSE som miljøvariabel lest av ACF sin PHP-API og hopp over dashboard-aktiveringsflyten helt.
• Bruk Composer HTTP basic auth (auth.json) for å autentisere mot ACFs offisielle Composer-endepunkt på connect.advancedcustomfields.com.

De to første er de eneste som overlever en servermigrasjon uten manuell intervensjon.

#Composer 2.7 vs Composer 2.6 lockfile-inkompatibilitet

Composer 2.7 endret hvordan composer.lock registrerer plattform-overrides. En composer.lock skrevet av 2.7 feiler ved installasjon på 2.6 med en misvisende “the lock file is not up to date”-feil. Standardiser Composer-versjonen i CI (composer self-update 2.7.7) og dokumenter det i README-en. Ja, dette er irriterende. Ja, det har bitt nok team til at Composer 2.8 vil advare om det eksplisitt.

#Premium-plugins: delen dokumentasjonen hopper over

Halvparten av plugins på en reell kundeside er ikke i WordPress.org-katalogen. ACF Pro, Gravity Forms, WP Migrate, GP Premium, FacetWP, WP All Import Pro. I norsk kontekst legg til Cookie Information eller Cookiebot for personvernforordningen, og ofte Yoast Premium. Composer-støtten varierer kraftig:

• ACF Pro: offisielt Composer-endepunkt på connect.advancedcustomfields.com. Fungerer bra, krever auth.json med lisensnøkkel som passord.
• Gravity Forms: offisiell Composer-støtte siden 2023. Lisensnøkkel i auth.json, pakkenavn gravityforms/gravityforms.
• Cookiebot/Cookie Information: ingen offisielt Composer-endepunkt. SatisPress eller manuell inkludering.
• WP Migrate Pro (Delicious Brains, nå WP Engine): ZIP-nedlasting med lisensnøkkel-URL. Custom Composer-repository som deklarerer pakken som package-type med URL inline, eller proxy gjennom SatisPress.
• WP All Import Pro: ingen Composer-endepunkt. ZIP-er hostet på en lisensnøkkel-URL. SatisPress eller commit ZIP-en til et privat repository.

Tre mønstre dekker alle ovennevnte:

1. Roots Premium (roots.io/premium). En administrert Composer-proxy som håndterer lisenser for ACF Pro, Gravity Forms og andre. Pris individuell; for byråer som driver 50+ sider går regnestykket vanligvis opp.
2. SatisPress. En WordPress-plugin som gjør din egen WordPress-installasjon om til et Composer-repository. Installer premium-plugins normalt, eksponer dem via https://din-private-host/satispress/, lås dem med HTTP basic auth.
3. Private Packagist fra packagist.com. Hostet Composer-repository med privat pakke-støtte. Koster mer enn SatisPress, krever null infrastruktur.

Uansett hva du velger er regelen: lisensnøkler går aldri inn i composer.json eller auth.json sjekket inn i git. De lever i miljøvariabler lest ved installeringstid, eller i CI-hemmeligheter injisert i auth.json under bygg-steget.

#CI-integrasjon som overlever virkeligheten

En fungerende deploy-pipeline:

# .github/workflows/deploy.yml (utdrag)
- 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/

Tre regler som sparer deg debug-tid:

• Aldri kjør composer update i CI. Oppdater lokalt, commit ny composer.lock, push. CI kjører composer install mot nøyaktig den lockfilen.
• Cache ~/.composer/cache med composer.lock-hash som nøkkel. Cold installs går fra 4 minutter til 30 sekunder.
• Inject auth.json fra en hemmelighet. COMPOSER_AUTH miljøvariabel leses av Composer naturlig. Aldri commit lisensierte credentials.

#Hva endret seg i WordPress-kulturen i 2026

Composer-på-WordPress var tidligere en Roots-shop-ting. I 2026 er det default for ethvert norsk byrå eller in-house team som deployer til mer enn ett miljø. Tre signaler fra det bredere økosystemet:

• WordPress.org plugin-innsendinger passerte 500 per uke i begynnelsen av 2026, opp fra 100 til 150 ukentlig gjennom 2022 til 2024 (kilde: ukentlige Plugin Review Team-rapporter). Mesteparten av det nye volumet er AI-assistert kode. Plugins-teamet rekrutterer frivillige anmeldere; katalogens kvalitetsterskel er under press.
• Både Kinsta og WP Engine la til native Composer-byggestøtte til Git push-deploy mot slutten av 2025. ServeBolt fulgte etter i første kvartal 2026. Kategorien “managed WordPress hosting som ignorerer composer.json” krymper.
• WP-CLI 2.10 la til wp composer underkommandoer som pakker composer install, composer update og lockfile-validering. Composer blir del av WP-CLI sin offisielle overflate.

Lærdommen for plugin-som-avhengighet-styring: tooling modnes raskere enn WordPress.org-katalogens anmelderkapasitet. Et self-hostbart speil som WP Packages er mer nyttig i denne konteksten enn det ville vært for fem år siden, da katalogen var en lukket hage alle stolte på som default.

#Sist oppdatert: 2026-04-01

Trenger du hjelp med å migrere en side til Bedrock eller sette opp en Composer-drevet deploy-pipeline? Se våre WordPress utviklingstjenester.