ben
March 16, 2026, 12:57pm
1
We built WP Packages , a fully open source, community-funded Composer repository for WordPress plugins and themes.
Also see WP Packages vs WPackagist — Why Independence Matters
Update: This post has been updated to reflect the new name: https://roots.io/wp-composer-is-now-wp-packages/
10 Likes
dsturm
March 18, 2026, 7:45am
3
Congratulations on this move and your true commitment to open source and the WordPress community!
I’ve already migrated several repositories to use WP Composer instead of WPackagist—most went very smoothly, especially using the bash script.
I do have two issues though:
When I migrated a Bedrock repo, my Sage repo hadn’t been migrated yet, and the Composer install encountered a theme dependency using the ’wpackagist-plugin/' namespace in its composer.json. Would it be possible to add a ’replace’’ key for WPackagist packages in WP Composer?Email Templates Customizer and Designer for WordPress and WooCommerce — WP Composer still lists 1.5.7 as current, whereas https://wordpress.org/plugins/email-templates/ shows 1.5.11 (released a month ago).
That said, I’d be happy to contribute a PR if needed (and I can decrypt Go
1 Like
ben
March 18, 2026, 1:45pm
4
Thanks for calling out these issue!
I’m not sure right off the bat, but if you can figure out a solution before us please feel free to submit a PR or DM to collaborate
I’m not yet on my machine, but maybe it’s related to one of these:
opened 01:30AM - 16 Mar 26 UTC
known issue
## Problem
Some WordPress plugin/theme authors release new versions to SVN trun… k without creating a corresponding SVN tag. WordPress.org serves these as the latest downloadable version, but our composer repository only builds from tagged releases.
**Example: optima-express**
- wp.org serves v8.4.0 to users (from trunk)
- Our latest available version is 8.3.1 (last tagged release)
- SVN: https://plugins.svn.wordpress.org/optima-express/
- Our repo: https://repo.wp-composer.com/p2/wp-plugin/optima-express.json
This means users requiring these packages via composer may not get the version that wp.org would give them via direct download.
## Considerations
- We currently normalize `trunk` to `dev-trunk` and exclude it from stable version listings
- wp.org provides a downloadable zip for trunk — we could support trunk as an installable version
- Need to determine how many packages are affected (plugins where wp.org `version` field doesn't match any tagged version)
## How wpackagist handles this
When wp.org's reported version doesn't exist in the tagged versions, wpackagist adds it as a pseudo-version pointing to the trunk download URL. The download uses the unversioned zip (`/plugin/{slug}.zip`) with a `?timestamp=` param based on last commit time to avoid Composer caching stale trunk builds.
Ref: [wpackagist Update.php](https://github.com/outlandishideas/wpackagist/blob/master/src/Service/Update.php), [Plugin.php](https://github.com/outlandishideas/wpackagist/blob/master/src/Entity/Plugin.php)
Relevant discussion from wpackagist: https://github.com/outlandishideas/wpackagist/issues/475
Key points:
- Ipstenu (WP plugins team) confirmed WP officially recommends tagging every release and is working on disabling trunk as a release mechanism
- Her recommendation: "If the version is trunk, or it's not found, congrats, you're non-compliant with this service, have a nice day."
- wpackagist's current behavior of mapping untagged versions to trunk downloads is acknowledged as a footgun by their own maintainer
- The WP ecosystem is moving away from trunk releases, not toward them
https://github.com/roots/wp-composer/issues/25
We opted out of a “refresh” option because our pipeline generates updated files every 5 minutes (might even be changed to every 2 mins soon)
1 Like
ben
March 19, 2026, 7:39pm
5
)