Hi nikdow,
I have only ever updated the stable tag in trunk (and this is the plugin directory itself references), so its best to check this file:
https://plugins.trac.wordpress.org/browser/megamenu/trunk/readme.txt
… for the latest stable tag. That should also work for every other plugin also.
Regards,
Tom
Thread Starter
nikdow
(@nikdow)
Thanks for your response.
Our script already gets the correct stable tag from the WP API but we have to compare that to the installed plugin, which we install from the tag, not from trunk. The installed plugin references an incorrect version number and that is the only way the script can determine the version of the installed plugin on our server.
We can’t install from trunk because some plugins have pre-release tags which we obviously don’t want to automatically install.
99% of plugins do this correctly, I’m afraid that only a couple that we use are not updating the stable tag in the readme that is included with the installed plugin code.
Hi nikdow,
The version number – the one used by WordPress itself – is taken from the plugin header, here:
https://plugins.trac.wordpress.org/browser/megamenu/tags/3.4.1/megamenu.php?rev=3252080#L6
I’d suggest using this function to get the current version number: https://developer.wordpress.org/reference/functions/get_plugin_data/
The stable tag is only used by the plugin directory and they read from trunk.
Regards,
Tom
-
This reply was modified 4 months ago by
megatom.
Thread Starter
nikdow
(@nikdow)
Thanks for the helpful information, however we are using a PY script to update, not PHP.
You have the correct version in the /trunk/readme.txt, and the wordpress plugin developer guidelines say:
Put your code files directly in the trunk/ directory of your repository. Whenever you release a new version, tag that release by copying the current trunk revision to a new subdirectory of the tags/ directory.
If you do the above, the file in the tags/ directory will have the correct version number.
Here’s what our PY script finds:
⬆ Updating megamenu: 3.4.1 → 3.5
✅ Updated: /home/lamp/wordpress/plugins/megamenu
So it looks like you are copying the files to tags/ then after that you are updating the readme.txt in trunk, which is the wrong way around.
Anyhow it’s still a great plugin and we can put up with downloading it every 12 hours, thanks for you attention to this request.
Hi nikdow,
My process is to update the version number in trunk (in the actual main plugin file, not readme.txt). I then copy from trunk to tags with the new version number.
At this point in time, nothing has happened in terms of releases. The plugin directory builds the tag zip file (based on the version number in the main plugin file) and I can test that in my own time. The tag might sit there for a day or week without being released to the public. Once I’m happy with the tagged version (and I might not be, I might find problems and need to retag it before its released), I’ll update the stable tag in the trunk readme.txt file. That kicks off the actual release to the public.
I think the process you’re suggesting would be to update the stable tag in trunk and tag it at the same time. If I did that, the release would go out immediately, so I’d have no time to test it.
Hopefully that helps explain it and shows why – in this case at least – you can’t trust the stable tag within a tagged readme file to be the actual version you have installed. If you want the actual version number for a plugin, check the header details in the main plugin file.
Regards,
Tom
-
This reply was modified 3 months ago by
megatom.
Thread Starter
nikdow
(@nikdow)
thanks and appreciate your time on this. We will have to live with the 2ce daily download.
The only other plugin with this issue is woocommerce and they are taking a similar approach to you.
And we do appreciate your care before releasing.