Some plugin versions unavailable when not tagged in SVN

[retlehs]

Problem

Some WordPress plugin/theme authors release new versions to SVN trunk 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, Plugin.php

Relevant discussion from wpackagist: wpengine/wpackagist#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

[retlehs]

Queried production data — 5,743 packages (9.4% of 61k active) have a wp.org reported version that doesn't match any tagged version:

• Plugins: 5,737
• Themes: 6

Installs	Count
1M+	2
100K+	9
10K+	113
1K+	434
100+	917
10+	2,901
<10	1,367

[retlehs]

WP officially recommends tagging every release and is working on disabling trunk as a release mechanism. Going to deprioritize this for now.

If you're affected by this for a specific plugin, the best path is to ask the plugin author to tag their releases in SVN — this is the WP-recommended practice and makes the version available everywhere (wp.org, wpackagist, and us).

Ref https://meta.trac.wordpress.org/ticket/6380

But please feel free to comment if you're affected by this and let us know which plugin(s) so we can track demand.

A workaround you could use is define a custom package repository in your composer.json. Example for the Optima Express plugin:

{
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "wp-plugin/optima-express",
        "version": "8.4.0",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "https://downloads.wordpress.org/plugin/optima-express.zip"
        }
      }
    }
  ]
}

The custom package repository must be listed above the wp-composer repository in the repositories array — Composer resolves in order.

Note: this downloads from trunk, which is mutable — the contents may change without the version number changing.

[tangrufus]

Since zips generated from trunk (e.g: https://downloads.wordpress.org/plugin/optima-express.zip) is not versioned.

I suggest we exclude non-compliant stable tag from stable versions.

By non-compliant, I mean:

• missing SVN tag
• version number is not supported by composer/semver. Examples https://github.com/typisttech/composer-semver#why

A better workaround for users is to install from SVN source with the branch name trunk. Composer can infer the svn revision number and properly lock the version.

[hadronix]

great work!

The activecampaign-subscription-forms plugin is also causing problems; the versioning is somewhat "broken" anyway. You had to explicitly set it to version 8: https://wpackagist.org/search?q=activecampaign-subscription

       {
            "name": "wpackagist-plugin/activecampaign-subscription-forms",
            "version": "8.1.21",
            "source": {
                "type": "svn",
                "url": "https://plugins.svn.wordpress.org/activecampaign-subscription-forms/",
                "reference": "trunk"
            },
            "dist": {
                "type": "zip",
                "url": "https://downloads.wordpress.org/plugin/activecampaign-subscription-forms.zip?timestamp=1763105557"
            },
            "require": {
                "composer/installers": "^1.0 || ^2.0"
            },
            "type": "wordpress-plugin",
            "homepage": "https://wordpress.org/plugins/activecampaign-subscription-forms/"
        }

[E-VANCE]

First of all: Great work, much appreciated!! 🙏

Keeping things open-sourced is much needed nowadays in the WP-sphere and introducing performance gains helps pushing the bar.

I am unable to switch to WP Composer for one project which uses the following plugins:

• Categories For Gravity Forms
• Log HTTP Requests

Both are missing SVN tags so this aligns with the findings.

Would love to see a workaround for this...