WP Composer: A Community-Funded Composer Repository for WordPress (and a Practical WPackagist Replacement)

If you’ve been managing WordPress sites with Composer, there’s a good chance WPackagist has been a silent dependency in your workflow for years. It solved a real problem: making WordPress.org plugins and themes installable as Composer packages, so teams could pin versions, ship reproducible builds, and treat WordPress like the rest of their PHP stack.

That convenience comes with a catch: when a piece of infrastructure becomes foundational to how a large chunk of the ecosystem builds and deploys, governance and transparency matter as much as uptime. With WPackagist now owned by a single corporation, many teams are re-evaluating the long-term risk of relying on it as the default repository.

WP Composer is a new, independent alternative: a community-funded, fully open source Composer repository for WordPress plugins and themes, built and maintained by Roots. It mirrors the free WordPress.org plugin and theme directories, but is designed around modern Composer capabilities and a cleaner naming scheme.

Why this change is happening now

WPackagist was originally created by Outlandish and maintained for years. Over time, it increasingly showed signs of neglect: slower updates, limited maintenance, and little meaningful input from the broader community.

In March 2026, WPackagist was acquired by WP Engine, a private equity-backed hosting company. That acquisition intensified existing concerns around centralization. When core developer tooling is controlled by a single corporate owner, the community’s influence tends to shrink-and decisions about availability, pricing, and direction can move behind closed doors.

There’s also a practical transparency issue: the public WPackagist GitHub repository no longer appears to reflect what’s running on the live site, which makes it harder to reason about how the service works and how it’s operated.

WP Composer is explicitly built to be the opposite of that: transparent, community-funded, and openly operated as a piece of shared infrastructure.

What WP Composer provides

WP Composer exposes every free plugin and theme from the WordPress.org directory as Composer packages. The key developer-facing improvement is naming: plugins live under wp-plugin/<em> and themes under wp-theme/</em>, avoiding the older wpackagist-plugin and wpackagist-theme prefixes.

Here’s what a minimal composer.json configuration looks like:

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

WP Composer is also positioned as the recommended repository to pair with Roots’ WordPress core packages: roots/wordpress, roots/wordpress-full, and roots/wordpress-no-content. In practice, a typical Bedrock project uses roots/wordpress for core, and WP Composer for plugins and themes.

Migrating from WPackagist (commands you can copy/paste)

If your existing project is using WPackagist, the migration is straightforward. The main work is swapping repository configuration and updating package names.

1) Remove your existing WPackagist packages

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

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

2) Swap the repository configuration

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) Require the packages again using WP Composer naming

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

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

Prefer automation? Use the migration script

If you’d rather update composer.json automatically, there’s a ready-made migration script you can run locally:

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

And if your workflow includes automated changelog tracking, note that Roots has renamed the WPackagist Changelog Action to the WP Composer Changelog Action, with full support for the new wp-plugin/<em> and wp-theme/</em> package formats.

Performance: why WP Composer resolves so much faster

Beyond governance, WP Composer’s other immediate win is performance. It supports Composer v2’s metadata-url protocol, which allows Composer to fetch metadata only for the packages you actually need. That’s a big deal on WordPress projects where a “normal” plugin set might still mean dozens of dependencies.

By contrast, WPackagist relies on the older provider-includes approach. In practice, that means Composer often has to download large index files containing metadata for thousands of packages before it can even begin resolving your dependency graph.

Composer resolve times (cold, no cache)

In benchmarks run from a single location using Composer 2.7+ (results can vary by region and network), WP Composer shows a large speed advantage on cold resolves:

• 10 plugins: WP Composer 0.7s vs WPackagist 12.3s (17x faster)
• 20 plugins: WP Composer 1.1s vs WPackagist 19.0s (17x faster)

The benchmark scripts used to produce these results are available as open source in the WP Composer repository: https://github.com/roots/wp-composer/tree/main/benchmarks

Metadata and caching behavior

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

Fully open source (so the community can verify and fork)

WP Composer’s application code, documentation, and deployment configuration are published as open source on GitHub: https://github.com/roots/wp-composer

That means the operational model is inspectable, contributions can happen in the open, and-crucially-anyone can fork the project and run their own instance if they need to.

Community-funded (to keep core tooling independent)

WP Composer is funded entirely through GitHub Sponsors: https://github.com/sponsors/roots

That funding supports the infrastructure, ongoing development, and maintenance of WP Composer, as well as the broader Roots ecosystem. If Composer is a core part of how you build and deploy WordPress, this model is designed to keep the repository independent and freely available.

Quick recap

• WP Composer is an independent Composer repository for WordPress.org plugins and themes.
• It uses cleaner package naming: wp-plugin/<em> and wp-theme/</em>.
• Migration from WPackagist is a few Composer commands (or a script).
• It’s significantly faster thanks to Composer v2 metadata-url support and modern caching behavior.
• The entire stack is open source, and funding is community-driven via GitHub Sponsors.