Quick Brief
- WP Engine acquired WPackagist in March 2026, placing foundational WordPress Composer infrastructure under corporate control
- WP Packages launched on March 16, 2026 as a fully independent, community-funded alternative built by Roots
- Cold dependency resolution runs 17x faster on WP Packages: 0.7 seconds vs. 12.3 seconds for 10 plugins
- Migration from WPackagist takes three terminal commands or a single automated script
When WP Engine acquired WPackagist in March 2026, every professional WordPress developer suddenly depended on infrastructure controlled by a private-equity-backed corporation. Four days later, the Roots team shipped WP Packages, a fully independent, open source Composer repository that already outperforms the tool it replaces. This is what a functional community response to corporate control looks like.
Why the WPackagist Acquisition Alarmed Developers
WPackagist was built by Outlandish, a UK-based digital cooperative, and it served the WordPress Composer ecosystem for over a decade. In its later years, the project suffered from deferred maintenance, slow update cycles, and little to no community input, which is what ultimately made Outlandish willing to hand it off.
Within 24 hours of the acquisition, WP Engine updated the Composer info field to display a “WPackagist is now maintained by WP Engine” notice in every developer’s terminal on every composer run. Developer Jonathan de Jong flagged it publicly on March 13, 2026: “And it only took less than 24h for this to pop up on every composer run… Which I’m sure is a permanent message that will just shift to marketing. Prove me wrong.” The message was small. The implication was not.
Roots also raised a structural transparency concern: WPackagist’s GitHub repository no longer reflects the live production site, meaning the project is effectively no longer verifiably open source in practice.
What WP Packages Actually Is
WP Packages (launched as WP Composer on March 16, 2026, and renamed on March 19, 2026) is a Composer repository that mirrors every free plugin and theme listed in the WordPress.org directory. It was built by Ben Word from Roots, the team behind Bedrock, Sage, and Trellis. Ben had already started building a WPackagist replacement last August, long before the acquisition made headlines. When WP Engine’s deal landed, he accelerated the launch.
The project is entirely public. Application code, documentation, and the full Ansible deployment configuration are all available on GitHub, meaning any developer or organization can fork the repository and run their own WordPress Composer registry. Ben has publicly committed that WP Packages will never use the Composer info field to push messages, ads, or upsells.
WP Packages is funded entirely through GitHub Sponsors. Current sponsors include Carrot, Kinsta, WordPress.com, and Itineris.
WP Packages vs. WPackagist: A Direct Comparison
| Feature | WP Packages | WPackagist |
|---|---|---|
| Ownership | Roots / community-funded | WP Engine (private equity-backed) |
| Open source | Fully public, including Ansible deployment config | GitHub repo no longer reflects live site |
| Package naming | wp-plugin/*, wp-theme/* |
wpackagist-plugin/*, wpackagist-theme/* |
| Cold resolve: 10 plugins | 0.7 seconds | 12.3 seconds (17x faster) |
| Cold resolve: 20 plugins | 1.1 seconds | 19.0 seconds (17x faster) |
| Metadata | Authors, descriptions, homepage URLs included | Missing since at least 2020 |
| Sync frequency | Every 5 minutes | ~90 minutes |
| Composer protocol | v2 metadata-url | Legacy provider-includes |
| CDN caching | public, max-age=300; immutable per-package files |
no-cache, private; not content-addressed |
| Info field policy | No messages, ads, or upsells committed | Marketing message added within 24h of acquisition |
| Funding | GitHub Sponsors | Corporate (WP Engine) |
The speed difference is structural, not incidental. WP Packages uses Composer v2’s metadata-url protocol, which fetches metadata only for packages a project actually needs. WPackagist still relies on the older provider-includes approach, which forces Composer to download large index files before resolving any dependency. Roots published open source benchmark scripts so any developer can reproduce these results independently.
How to Migrate from WPackagist to WP Packages
Option 1: Manual migration (three commands)
Step 1: Remove your existing WPackagist packages:
composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive
Step 2: Remove the WPackagist repository and add WP Packages:
composer config --unset repositories.wpackagist && composer config repositories.wp-packages composer https://repo.wp-packages.org
Step 3: Require packages using the new naming convention:
composer require wp-plugin/woocommerce wp-theme/twentytwentyfive
Option 2: Automated migration script
curl -sO https://raw.githubusercontent.com/roots/wp-packages/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh
This script automatically rewrites your composer.json, updating all package prefixes from wpackagist-plugin/ and wpackagist-theme/ to wp-plugin/ and wp-theme/ in a single pass. Projects already using Bedrock have WP Packages configured out of the box as of March 2026.
Roots also provides a WP Packages Changelog Action for GitHub workflows that tracks dependency updates using the new naming format, with full support for wp-plugin/* and wp-theme/*. It replaces the previously named WPackagist Changelog Action.
The Broader Signal for WordPress Infrastructure
What makes the WP Packages story significant is the speed and quality of the response. Ben Word and the Roots team did not wait for the acquisition to finalize before building an alternative. They identified the structural fragility months earlier and built a technically superior tool before the community needed it.
The project answers a question the WordPress ecosystem has struggled with for years: who should own the tooling that underpins professional WordPress development? WP Packages gives a concrete answer. The entire system, including infrastructure and build process, is public. Decisions about availability and direction are made in the open, not in a boardroom.
Considerations and Limitations
WP Packages launched publicly on March 16, 2026, and its long-term infrastructure resilience at the scale WPackagist operates is unproven. Community funding through GitHub Sponsors is sufficient for current operations, but sustained financial commitment is required as usage scales. WPackagist continues to function correctly and WP Engine has committed to keeping it free, so migration is a choice driven by preference for independence, not an emergency.
Frequently Asked Questions (FAQs)
What is WP Packages and how does it differ from WPackagist?
WP Packages is an independent, community-funded Composer repository for WordPress plugins and themes, built by Roots as a direct WPackagist alternative. Unlike WPackagist, which WP Engine acquired in March 2026, WP Packages is fully open source, uses Composer v2 metadata-url protocol for faster dependency resolution, and syncs with WordPress.org every five minutes instead of roughly every 90 minutes.
Why did WP Engine acquire WPackagist in 2026?
WP Engine acquired WPackagist from UK-based digital cooperative Outlandish in March 2026. Outlandish had struggled to maintain the project alongside client work, and WP Engine committed to keeping the service free and operational. The acquisition drew community concern over a private-equity-backed corporation controlling infrastructure central to the WordPress developer workflow.
How much faster is WP Packages compared to WPackagist?
WP Packages resolves cold Composer dependencies 17x faster than WPackagist. Installing 10 plugins takes 0.7 seconds on WP Packages versus 12.3 seconds on WPackagist; 20 plugins takes 1.1 seconds versus 19.0 seconds. This advantage comes from WP Packages using Composer v2’s metadata-url protocol, which fetches only required package metadata rather than large index files. Roots published open source benchmark scripts to verify these results.
Is WP Packages safe to use for production WordPress projects?
WP Packages is fully open source, with its application code, documentation, and Ansible deployment configuration publicly available on GitHub. It is backed by sponsors including Kinsta, WordPress.com, Carrot, and Itineris. As with any project that launched recently, teams should test migrations on staging environments before applying changes to production.
How do I migrate from WPackagist to WP Packages?
Migration requires either three terminal commands or a single automated migration script from the Roots GitHub repository. The script rewrites all wpackagist-plugin/* and wpackagist-theme/* references in your composer.json to the new wp-plugin/* and wp-theme/* naming convention automatically. Bedrock projects already ship with WP Packages configured as of March 2026.
Does WP Packages cover all WordPress.org plugins and themes?
Yes. Every free plugin and theme listed in the WordPress.org directory is available through WP Packages. The repository syncs with the WordPress.org directories every five minutes, compared to WPackagist’s roughly 90-minute update cycle.
Will WP Packages push messages or ads into my terminal?
No. Ben Word has publicly committed that WP Packages will never use Composer’s info field to push messages, marketing notices, or upsells into developer terminals. This commitment was made directly in response to WP Engine updating WPackagist’s info field within 24 hours of its acquisition.
What is the WP Packages Changelog Action?
The WP Packages Changelog Action is a GitHub Actions workflow provided by Roots that tracks WordPress plugin and theme dependency updates using WP Packages’ wp-plugin/* and wp-theme/* naming format. It is a direct rename and upgrade of the previously named WPackagist Changelog Action, designed for CI/CD pipelines and Bedrock-based WordPress projects.
