search

outlandishideas / wpackagist

WordPress Packagist — manage your plugins with Composer
https://wpackagist.org
MIT License
704 stars 71 forks source link

Trunk is installed rather than tag for advanced-post-manager #292

Open coreyworrell opened 5 years ago

coreyworrell commented 5 years ago

You'll see they don't keep any code in trunk: https://plugins.trac.wordpress.org/browser/advanced-post-manager/#trunk

But there are tags with full code: https://plugins.trac.wordpress.org/browser/advanced-post-manager/#tags/4.5.0

If I specify in my composer.json "*" or "4.5.0" it installs from trunk.

coreyworrell commented 5 years ago

Looking in ~/.composer/cache/repo/https---wpackagist.org/provider-wpackagist-plugin$advanced-post-manager.json I see there is an entry for 4.5 (normalized to 4.5.0.0.) pointing to trunk, and then also a 4.5.0 (also normalized to 4.5.0.0 pointing to the correct dist/zip).

Does wpackagist look at the readme.txt for versions at all? Because trunk specifies Stable tag: 4.5.0 while tag 4.5.0 specifies Stable tag: 4.5. Maybe this has something to do with it.

roy-bongers commented 4 years ago

The same goes for enlighter it seems. Here everything seems to be at 4.2.0 except for the plugin itself (enlighter.php file).

https://wpackagist.org/p/wpackagist-plugin/enlighter%24ebf508e505ec8f47198e73a96b602b85731dd1c4dd2ae648ddc0b7f8b57c4452.json

https://plugins.trac.wordpress.org/browser/enlighter

Edit: I just found out where it goes wrong for the enlighter plugin: https://github.com/outlandishideas/wpackagist/blob/master/src/Command/UpdateCommand.php#L117

The $info['version'] is the version from the plugin's php file. Where the other versions are the svn tags. The version in the php file doesn't match any of the tags and therefore it set's the current "wordpress" version to trunk.

NoelLH commented 3 years ago

Let's re-test this once recent refactor changes are out. See #350, #368

NoelLH commented 3 years ago

I think this is a live issue, but as you suggest is down to the published package data not being self-consistent in this particular case. I'm not sure the complexity of parsing versions differently to work around this is necessarily worth it but I'm definitely open to PRs if they can address this without significantly slowing down the update process.

ethanclevenger91 commented 3 years ago

Bugged the Tribe team here