WP Composer: et community-finansieret alternativ til WPackagist i din Composer-baserede WordPress-stack

I rigtig mange moderne WordPress-projekter (især dem der kører Composer-first) er plugin- og tema-dependencies lige så vigtige som PHP-pakkerne i resten af applikationen. I over et årti har WPackagist været den de facto løsning til at trække gratis plugins og temaer fra WordPress.org ind i composer.json.

Men når kritisk infrastruktur for hele WordPress’ Composer-workflow lander under kontrol af én virksomhed, opstår der nogle ret naturlige bekymringer: hvem bestemmer retning, tilgængelighed, eventuel prissætning og drift – og hvor gennemsigtigt foregår det?

Derfor er WP Composer kommet på banen: et uafhængigt, community-finansieret og fuldt open source Composer repository for WordPress-plugins og -temaer, bygget og vedligeholdt af Roots. Tanken er enkel: samme nytteværdi som WPackagist har leveret, men med mere gennemsigtighed, moderne Composer-protokoller og et governance-/funding-setup, der ikke er låst til én enkelt virksomhed.

Hvorfor det her overhovedet betyder noget

WPackagist blev oprindeligt lavet af Outlandish og var i mange år en solid brik i værktøjskassen. Senere har projektet dog været præget af begrænset vedligeholdelse: langsommere opdateringer, mindre aktiv drift og uden reelt community-input.

I marts 2026 blev WPackagist opkøbt af WP Engine (et private equity-backet hosting-selskab). Når en så central dependency-kilde bliver ejet af en enkelt aktør, rykker beslutningerne nemt fra åbne processer over i lukkede mødelokaler. Samtidig er det uklart, hvor “open source” WPackagist i praksis er i dag, fordi deres GitHub-repository ikke længere afspejler den live service: https://github.com/outlandishideas/wpackagist

WP Composer positionerer sig som et alternativ, der er transparent, community-finansieret og bygget af folk, der har arbejdet med Composer-baseret WordPress i mange år. Der ligger også en detaljeret sammenligning mellem WP Composer og WPackagist (performance, metadata og forskelle i praksis) her: https://wp-composer.com/wp-composer-vs-wpackagist

Hvad WP Composer leverer i praksis

WP Composer indekserer alle gratis plugins og temaer fra WordPress.org directory, så de kan installeres via Composer – men med et mere rent navngivningsskema:

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

Konventionen er konsekvent:

• Plugins bruger wp-plugin/*.
• Temaer bruger wp-theme/*.
• Dermed slipper du for wpackagist-plugin og wpackagist-theme som præfikser.

WP Composer er samtidig det anbefalede repository, hvis du bruger Roots’ WordPress core-pakker: roots/wordpress, roots/wordpress-full og roots/wordpress-no-content (oversigt: https://wp-composer.com/roots-wordpress). I et klassisk Bedrock-setup (https://roots.io/bedrock/) betyder det typisk roots/wordpress til core og WP Composer til plugins og temaer.

Migrering fra WPackagist (trin-for-trin)

Hvis du allerede har et projekt, der kræver plugins/temaer via WPackagist, er skiftet ret ligetil og kan klares med få kommandoer.

1) Fjern dine WPackagist-pakker

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

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

2) Skift repository-konfigurationen

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) Kræv pakkerne igen med de nye navne

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

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

Vil du automatisere ændringerne i composer.json, findes der et migreringsscript, som opdaterer filen for dig. Scriptet ligger her: https://github.com/roots/wp-composer/blob/main/scripts/migrate-from-wpackagist.sh og kan køres sådan:

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

Hvis du bruger Roots’ GitHub Action til at tracke plugin-opdateringer, er den også flyttet med: “WPackagist Changelog Action” er omdøbt til “WP Composer Changelog Action” og understøtter fuldt ud wp-plugin/<em> og wp-theme/</em>-formatet: https://github.com/roots/wp-composer-changelog-action

Performance: hvorfor resolves pludselig bliver meget hurtigere

Den store tekniske forskel ligger i, hvordan metadata leveres til Composer. WP Composer understøtter Composer v2’s metadata-url-protokol, hvor Composer kun henter metadata for de pakker, den faktisk har brug for.

WPackagist bruger stadig den ældre provider-includes-model, som tvinger Composer til at downloade store index-filer med metadata for tusindvis af pakker, før dine dependencies kan resolves. Det kan være markant langsommere – især ved “cold resolve”, hvor du ikke har cache lokalt.

Composer resolve-tider (cold resolve, ingen cache – lavere er bedre)

Her er et konkret benchmark for cold resolves:

<table>
  <thead>
    <tr>
      <th>Plugins</th>
      <th>WP Composer</th>
      <th>WPackagist</th>
      <th>Speedup</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10 plugins</td>
      <td><strong>0.7s</strong></td>
      <td>12.3s</td>
      <td>17x faster</td>
    </tr>
    <tr>
      <td>20 plugins</td>
      <td><strong>1.1s</strong></td>
      <td>19.0s</td>
      <td>17x faster</td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th>Plugins</th>
      <th>WP Composer</th>
      <th>WPackagist</th>
      <th>Speedup</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10 plugins</td>
      <td><strong>0.7s</strong></td>
      <td>12.3s</td>
      <td>17x faster</td>
    </tr>
    <tr>
      <td>20 plugins</td>
      <td><strong>1.1s</strong></td>
      <td>19.0s</td>
      <td>17x faster</td>
    </tr>
  </tbody>
</table>

Metadata og caching (hvad der gør forskellen)

<table>
  <thead>
    <tr>
      <th></th>
      <th>WP Composer</th>
      <th>WPackagist</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Composer v2 metadata-url</td>
      <td><strong>Yes</strong></td>
      <td>No</td>
    </tr>
    <tr>
      <td>CDN caching</td>
      <td><code>public, max-age=300</code></td>
      <td><code>no-cache, private</code></td>
    </tr>
    <tr>
      <td>Per-package files</td>
      <td>Immutable, content-addressed, cached indefinitely</td>
      <td>Not content-addressed</td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th></th>
      <th>WP Composer</th>
      <th>WPackagist</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Composer v2 metadata-url</td>
      <td><strong>Yes</strong></td>
      <td>No</td>
    </tr>
    <tr>
      <td>CDN caching</td>
      <td><code>public, max-age=300</code></td>
      <td><code>no-cache, private</code></td>
    </tr>
    <tr>
      <td>Per-package files</td>
      <td>Immutable, content-addressed, cached indefinitely</td>
      <td>Not content-addressed</td>
    </tr>
  </tbody>
</table>

Benchmarks er kørt fra én lokation med Composer 2.7+; resultater kan variere afhængigt af region og netværksforhold. Benchmark-scripts er open source her: https://github.com/roots/wp-composer/tree/main/benchmarks

Fuld open source: kør det selv, hvis du vil

WP Composer er ikke bare et “gratis endpoint”. Hele applikationskoden, dokumentationen og deployment-konfigurationen er open source på GitHub: https://github.com/roots/wp-composer. Det betyder i praksis, at alle kan inspicere, bidrage – og i sidste ende forke og drive deres egen instance, hvis de har behov for det.

Community-finansiering via GitHub Sponsors

Driften er finansieret af community’et gennem GitHub Sponsors: https://github.com/sponsors/roots. Sponsorship går direkte til infrastruktur, udvikling og vedligehold af WP Composer samt det bredere Roots-økosystem.

Der findes også en direkte sponsorløsning her: https://github.com/sponsors/roots

Kort opsummeret

• WP Composer er et uafhængigt Composer repository til gratis WordPress.org plugins og temaer, med pænere pakkenavne (wp-plugin/<em> og wp-theme/</em>).
• Migrering fra WPackagist kan klares med få Composer-kommandoer – eller via et script, der omskriver composer.json.
• metadata-url i Composer v2 giver markant hurtigere resolves end den ældre provider-includes-model.
• Hele projektet er open source, og driften er community-finansieret via GitHub Sponsors.