#4661 closed defect (bug) (wontfix)
W.org plugins directory displays wrong version in advanced view
Reported by: | KestutisIT | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | needs-patch |
Cc: |
Description
So, here is a bug. Plugin was released with 6.1.7 initial Semver. It is shown in plugin details page on the right side.
But somewhy in advanced view it pulls out '1.0' version that is nowhere displayed.
https://wordpress.org/plugins/deals/advanced/
Additionally, I also noticed for other plugin - 6.1 version was released, but in advanced view only 6.0 version was displayed for nearly two weeks, despite that the graph bellow already was showing a boost of downloads (due to new version release) at:
https://wordpress.org/plugins/expandable-faq/advanced/
So one graph display realtime information (at least date matches), while the version information is somewhy delayed by 2 weeks.
Change History (9)
#2
@
5 years ago
Also, while the data is not delayed 2 weeks, it is delayed by a couple days. Update checks happen over the course of a day, and then the next day we add up the totals for the previous day, thus leading to a roughly 48 hour delay in active version data being updated. But it is accurate as far as the data we have received.
#3
@
5 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
I'm saying that is not couple days. It is more. And I'm totally confused about 1.0. I never posted anywhere this version. So please exactly explain or give link how the 1.0 got there (even in 'Deals' beta versions it was still 6.1.* as it is on SolidMVC, Version 6 - so it was never 1.0 for 'Deals').
I'm reopening this ticket as long as the clear answer about 1.0 with exact information is not given, as I believe it is bug.
I also disagree about 1 day of 6.0 or 6.1. It was almost 2 weeks. Not 1 day. So I once again, ask at least to run a test. I'm not going to release 6.2 soon to do the test again, but you guys have tools for testing there. It was definitely longer than 1-2 days.
#4
@
5 years ago
- Resolution set to wontfix
- Status changed from reopened to closed
KestutisIT - the issue is SOMEONE ELSE used 'deals' as the plugin folder name too.
That's why we generally reject simple-named plugins like that out of hand. It causes weird metrics. Nothing's wrong here, you just picked a name other people were using too.
We have an in progress ticket to check if slugs are used to a high degree or not when a plugin is submitted, and will prevent submissions in that case, but that's a bit out.
2 weeks for everything to catch up and cache is extreme, but not unheard of.
#5
@
5 years ago
@Ipstenu - thanks for clearing this up. As I have a partnership with PayPal and did many PayPal integrations, I can confirm that the most secure way for this, is to generate SHA2-512 or RSA *.cert file for each plugin after it is released and keep that file in plugins folder. The cert will ensure that request is coming from that exact plugin. It should be an URL of W.org and plugin's admin dashboard image icon checksum or Plugin/Plugin.php (main file with meta description) or just a meta description checksum. It won't be a checksum of whole zip, but at least of that one thing it could be. Otherwise I can now hack any plugin of W.org putting there random information and submitting to report, even maybe '1.0-EVIL' version to i.e. bbPress. And this will be see on reports screen for everyone, as I can print there any message I want with version as long as it match the Semver rule, and Semver allows to name the release. So that's a security risk.
#6
@
5 years ago
I can print there any message I want with version as long as it match the Semver rule, and Semver allows to name the release.
Oh it's worse than that. It doesn't require it to match the semver pattern. I could put in a version of "Otto-Sucks" if I wanted, and it'd show up. The system doesn't force SemVer.
If you wanted to open up a ticket to propose something like this, go for it.
You may want to read https://meta.trac.wordpress.org/ticket/3192 first for what was done with checksums and zips.
admin dashboard image icon checksum
Those aren't included in the plugin as installed. Remember the assets folder is separate :) And not all plugins have them.
The only ONE file in all plugins is the readme. But that could still be 100% the same, so probably the only reliable source would be the main plugin file.
ETA: I will note that one massive flaw here is that we may not have the checksum for older versions. Some people annoyingly use trunk for everything. They don't use tag folders. So either we'd have to omit those plugin versions (which would build an incomplete list) or find an alternative solution.
#7
@
5 years ago
@Ipstenu should I create a ticket on meta track then about the checksum? https://meta.trac.wordpress.org/
#8
@
5 years ago
You don't have to @ me :) I'm following the ticket. @ people who aren't on the ticket.
If you want to follow up on this, yes, make a new ticket just for that, but that's entirely your choice.
#9
@
5 years ago
I also disagree about 1 day of 6.0 or 6.1. It was almost 2 weeks. Not 1 day. So I once again, ask at least to run a test. I'm not going to release 6.2 soon to do the test again, but you guys have tools for testing there. It was definitely longer than 1-2 days.
It is one to two days exactly. I'm not just making things up, I can see the data.
Do not confuse "downloads" with "active installs". These are two entirely different numbers, from two entirely different sources, that have nothing whatsoever to do with each other.
You're pointing to a plugin that has like 20 active installs, has only been listed for 9 days, and then are trying to make inferences from that. You simply don't have the data.
WordPress installs check for updates. They do this asking api.wordpress.org "hey, I have plugin-x version 1.1, are there any newer versions available?" We look it up, and respond yes or no. Simple. We also record the version number and then at the end of every day make a count of all the installs that called home. The active installs is where the active install data comes from.
Downloads are a simple hit counter. How many times the ZIP file was downloaded. Doesn't say who downloaded it, why, or for what purpose. Simple dumb hit counter. Download numbers count inactive installs too. Or people downloading the zip file. Or bots. These are all things that affect the numbers.
Active install data also isn't guaranteed to be accurate. If nobody visits a website, then it doesn't do anything. It doesn't ask for updates. It doesn't load WordPress at all to do so. So the data varies from day to day. People also install plugins to test them, and then remove them. Or they deactivate them. Point being that there is a lot of variance in the data over time, so until your numbers are large enough, and you have a long enough baseline for comparison, you can't really draw any meaningful conclusions at all.
Point being that this is a directory for hosting free plugins for free. It's not a storefront. We do try to make the numbers accurate and meaningful and useful, but we're not going to excessive lengths to verify or validate them. You shouldn't be relying on them for meaningful sales info because it's not allowed to sell things here in the first place.
The data from Active Versions comes from reports back from actual live systems.
You have a plugin named "deals". There exist plugins with the same name and their version is "1.0". Maybe these are not your plugin, but same name and slug = same plugin as far as our systems are concerned.
As for the 6.0 and 6.1, the data we display on these charts comes from actual systems. If it says 60% of people are running your old version, then that's because 60% of people are running the old version according to the data reported back to us by the update checks.
This is not a bug, or an error. It is the data that is reported back to us, we are simply reflecting it in those graphs.