Plugins don't always tag their latest releases

[retlehs]

Problem

~33% of WordPress plugins (~20k) don't have an SVN tag matching their latest release. This means their newest version can't be served as a proper Composer package.

WordPress officially recommends tagging every release and is working toward disabling trunk as a release mechanism

Warning

WPackagist serves the latest untagged version as a "stable" tagged release, which can result in unexpected plugin updates. For example, a plugin author could push breaking changes to trunk without bumping the version number, and composer update would pull those changes in as if they were the same stable version.

What we've done

• Untagged Plugins page page — lists all affected plugins with links to request tagging on the plugin's support page
• Detail page warnings — when a plugin's wp.org version doesn't match any tagged SVN release, the detail page shows a warning with the dev-trunk install command
• dev-trunk installs (Split dev-trunk into ~dev.json for proper SVN revision locking #65) — every package now has a dev-trunk version available:

  composer require wp-plugin/example:dev-trunk
  

• Revision pinning (Pin dev-trunk to SVN revision and remove unpinnable dist #69) — dev-trunk is pinned to a specific SVN revision (e.g. trunk@3478537), so composer install from a lock file is actually immutable. This is an improvement over wpackagist's approach which uses ?timestamp= cache-busting but still serves whatever trunk currently contains.

What plugin authors should do

Tag your releases in SVN.

[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.

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

Update: You can now install any package from trunk via dev-trunk:

composer require wp-plugin/optima-express:dev-trunk

Note: trunk is mutable — the contents may change without the version number changing. See #65 for details.

[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...

[vinkla]

If it helps with debugging: the plugin Post Type Switcher is listed as version 4.0.1 on WordPress.org but appears as 4.0.0 on WP Packages.

• WP Packages: https://wp-packages.org/packages/wp-plugin/post-type-switcher
• WordPress: https://wordpress.org/plugins/post-type-switcher/

[retlehs]

Thanks for the report

I’d strongly suggest reaching out to these plugin authors since the dot org plugin team lead has said “you're non-compliant with this service” (context in OP)

@JJJ Just curious why is there not a SVN tag for your new release?

[JJJ]

@retlehs laziness and not automating tags & releases thoroughly 😀

Tagged it just now: https://plugins.trac.wordpress.org/changeset/3490211

I for-sure have other plugins like this, stemming from way-way back-in-the-day when we used to recommend everyone occasionally purge old tags & branches because their dormant existence was slowing down (or clogging up) the Subversion mono-repo - it seemed most polite to not bother with tags or branches at all.

[retlehs]

We've added visibility into this but are still on the fence about adding direct support for untagged versions. Here's what's live:

• https://wp-packages.org/untagged — all ~5,700 affected plugins with request-tagging links to the plugin's support page, and composer.json workarounds
• Detail page warnings when a plugin's wp.org version doesn't match any tagged SVN release, with a copyable composer.json workaround for plugins that haven't tagged their latest version

Our current thinking is we'd rather put pressure on authors than add trunk-based installs that mask the problem, but we're open to hearing from anyone who feels differently.

[E-VANCE]

I think this is the right approach and providing the composer workaround allows for a soft landing.

Minor UX request: "Copy workaround" doesn't give any feedback once clicked, would love to see some confirmation there.

[retlehs]

Turns out this number is much higher than my original queries after making this fix: #61

20,694 plugins affected (33.3% of all plugins)