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/
11 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
dsturm
March 26, 2026, 9:15am
7
Thanks, @ben .
Yes, the plugin isn’t tagged correctly , so it’s clear to me why there is no current version available. For another plugin, Germanized for WooCommerce , we have a new version that was correctly tagged about 40 minutes ago , but it is still not available on WP Packages.
I don’t want to rush things
ben
March 26, 2026, 2:06pm
8
Pipeline runs every five minutes:
I’ll look into why this plugin is missing when I’m back on my machine
And FYI, you pasted a URL to repo.wp-composer.com which hasn’t been updated since the switchover. See the blog post for the one-liner to switch to repo.wp-packages.org .
Still investigating why this plugin wasn’t updated to 4.0.0 on the regular pipeline run
1 Like
ben
March 26, 2026, 3:23pm
9
@dsturm Thank you for bringing this to our attention, the fix:
main ← fix/retry-stale-api-sync
opened 03:07PM - 26 Mar 26 UTC
## Summary
- Compare fetched `versions_json` against existing DB value after eac… h API fetch
- If unchanged and within 24-hour retry window: keep package dirty for next run
- If unchanged and window expired: advance `last_synced_at` (non-version change)
- If changed: advance `last_synced_at` normally
- Log counters `stale_retried` / `stale_expired` in both update logs and sync run stats
## Context
Race condition: SVN commit detected → pipeline fetches wp.org API → API returns cached/stale data → `last_synced_at` advanced → package never retried. Real example: `woocommerce-germanized` 4.0.0 was tagged and confirmed on the API at `2026-03-26 8:29am GMT`, but our pipeline synced 2 minutes later with stale data (3.20.7) and stayed stuck for 6+ hours.
A one-time `./wppackages update --force` should be run after deploy to heal any currently stuck packages.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Confirmed that Germanized for WooCommerce now has 4.0.0:
https://wp-packages.org/packages/wp-plugin/woocommerce-germanized https://repo.wp-packages.org/p2/wp-plugin/woocommerce-germanized.json
1 Like
)
, but since you mentioned that updates follow a 5-minute schedule, I expected it to be listed by now. Am I mistaken?