I honestly thought we’d reached a stable point with WordPress dependency management. For a decade, WPackagist was the invisible backbone of our workflows. But when corporate ownership shifts, the relationship between a tool and its users changes instantly. WP Packages isn’t just a reaction to an acquisition; it’s the refactor we’ve actually needed for years.
If you’ve been dealing with slow CI/CD pipelines or resolving dependencies that feel like they’re stuck in 2013, you’re not alone. The community-funded WP Packages project, spearheaded by Ben Word and the Roots team, addresses fundamental architecture flaws that have plagued the ecosystem. Specifically, it moves us away from legacy “provider-includes” and into a modern, high-performance workflow.
The Performance Bottleneck: Why WPackagist is Slow
WPackagist relies on an older approach that forces Composer to download massive index files before it can even begin resolving dependencies. This often results in a “cold” resolve taking upwards of 12 seconds for a handful of plugins. Furthermore, its update cycle is roughly 90 minutes, which is an eternity when you’re waiting for a critical security patch to hit your repository.
In contrast, WP Packages supports the Composer v2 metadata-url protocol. Consequently, Composer only fetches the specific metadata for the packages your project requires. We’re talking about a 17x speed increase—resolving 10 plugins in 0.7 seconds instead of 12.3. This isn’t just a minor optimization; it’s a total shift in package management performance.
Technical Advantages of WP Packages
- Metadata-URL Protocol: Fetch only what you need, significantly reducing memory overhead.
- Immutable Caching: Uses content-addressed per-package files with public cache headers.
- Cleaner Naming: Uses
wp-plugin/andwp-theme/instead of the more verbosewpackagist-plugin/prefix. - Author Integrity: Includes plugin authors, descriptions, and homepage URLs—data WPackagist has ignored for years.
Whether you’re building a custom WordPress AI architecture or a standard site, these infrastructure improvements reduce friction for every developer on your team.
How to Migrate to WP Packages
Switching is straightforward. You can either use a migration script or update your composer.json manually. Personally, I prefer the manual route to ensure I’m not carrying over any legacy trash.
First, remove your old WPackagist repository and add the new one:
composer config --unset repositories.wpackagist && composer config repositories.wp-packages composer https://repo.wp-packages.orgThen, you’ll need to update your requirements to use the new naming convention. For example:
"require": {
"wp-plugin/akismet": "^5.0",
"wp-theme/twentytwentyfive": "^1.0"
}If you have dozens of plugins and don’t want to edit the JSON manually, use the official migration script provided by the Roots team:
curl -sO https://raw.githubusercontent.com/roots/wp-packages/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.shLook, if this WP Packages stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
A Win for Open Source Integrity
The core philosophy behind WP Packages is transparency. The entire application code, build process, and even the Ansible deployment configurations are public on GitHub. Therefore, the ecosystem is no longer reliant on a single corporate entity’s goodwill or marketing strategy. It’s developers building tools for developers—exactly how open source should work. Ship it.
