# Introducing WP Packages as a WPackagist Replacement **URL:** https://discourse.roots.io/t/introducing-wp-packages-as-a-wpackagist-replacement/30235 **Category:** blog **Tags:** wp-packages **Created:** 2026-03-16T12:57:21Z **Posts:** 10 ## Post 1 by @ben — 2026-03-16T12:57:21Z We built [WP Packages](https://wp-packages.org/), a fully open source, community-funded Composer repository for WordPress plugins and themes. ### **[Read more on the blog](https://roots.io/introducing-wp-composer-as-a-wpackagist-replacement/)** Also see [WP Packages vs WPackagist — Why Independence Matters](https://wp-packages.org/wp-packages-vs-wpackagist) * * * Update: This post has been updated to reflect the new name: [https://roots.io/wp-composer-is-now-wp-packages/](https://roots.io/wp-composer-is-now-wp-packages/) --- ## Post 2 by @ben — 2026-03-16T18:32:31Z --- ## Post 3 by @dsturm — 2026-03-18T07:45:57Z Congratulations on this move and your true commitment to open source and the WordPress community! :clap:t3: 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: 1. 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? 2.. WPackagist had a “Refresh” button to check for current available versions. For example, [Email Templates Customizer and Designer for WordPress and WooCommerce — WP Composer](https://wp-composer.com/packages/wp-plugin/email-templates) still lists 1.5.7 as current, whereas [https://wordpress.org/plugins/email-templates/](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 :sweat_smile:) --- ## Post 4 by @ben — 2026-03-18T13:45:28Z Thanks for calling out these issue! 1. 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 2. I’m not yet on my machine, but maybe it’s related to one of these: > > > ## 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](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) --- ## Post 5 by @ben — 2026-03-19T19:39:53Z Update: [**WP Composer is now WP Packages**](https://roots.io/wp-composer-is-now-wp-packages/) - [WP Composer is now WP Packages | Roots](https://roots.io/wp-composer-is-now-wp-packages/) - [https://wp-packages.org/](https://wp-packages.org/) --- ## Post 6 by @ben — 2026-03-19T19:40:07Z --- ## Post 7 by @dsturm — 2026-03-26T09:15:42Z Thanks, @ben. 1. Yes, the plugin [isn’t tagged correctly](https://plugins.svn.wordpress.org/email-templates/tags/), so it’s clear to me why there is no current version available. For another plugin, [Germanized for WooCommerce](https://wordpress.org/plugins/woocommerce-germanized/#developers), we have a new version that was [correctly tagged about 40 minutes ago](https://plugins.svn.wordpress.org/woocommerce-germanized/tags/), but it is still [not available](https://repo.wp-composer.com/p2/wp-plugin/woocommerce-germanized.json) on WP Packages. I don’t want to rush things :slightly_smiling_face:, but since you mentioned that updates follow a 5-minute schedule, I expected it to be listed by now. Am I mistaken? --- ## Post 8 by @ben — 2026-03-26T14:06:06Z Pipeline runs every five minutes: ![IMG_3726](https://discourse.roots.io/uploads/default/original/2X/6/6c0497091d0f8b02ab26b2212f0aa845e97f4d47.jpeg) > **[WP Packages — Recently Updated Packages](https://wp-packages.org/feed.xml)** 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`](https://roots.io/wp-composer-is-now-wp-packages/). Still investigating why this plugin wasn’t updated to 4.0.0 on the regular pipeline run --- ## Post 9 by @ben — 2026-03-26T15:23:57Z @dsturm Thank you for bringing this to our attention, the fix: > > > ## 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://wp-packages.org/packages/wp-plugin/woocommerce-germanized) [https://repo.wp-packages.org/p2/wp-plugin/woocommerce-germanized.json](https://repo.wp-packages.org/p2/wp-plugin/woocommerce-germanized.json) --- ## Post 10 by @dsturm — 2026-03-26T15:35:05Z Awesome, thank you!!!