Inaccurate plugin rating counts

[svenl77]

I found a wired behave in the new plugin directory. Deleted spam reviews still get counted

Example: ​https://wordpress.org/plugins/bp-wc-vendors/ the two 1 star have been deleted but still get count

[netweb]

Welcome to Trac and thanks for the ticket @svenl77

To clarify things a little further, currently there are two 5 star reviews, and three 1 star reviews that have been "archived". The plugin page shows two 5 star reviews and two 1 star reviews, it should show only the two published 5 star ratings, the same as the reviews page.

This is also only an issue on the plugin page: ​https://wordpress.org/plugins/bp-wc-vendors/

• 

The plugin correctly only shows only the two 5 star reviews on the review page: ​https://wordpress.org/support/plugin/bp-wc-vendors/reviews/

• 

[Otto42]

This is because the get_star_rating function is using the post_meta, when it should be calling the existing and centralized ratings code to get the information correctly. Said ratings code also contains the necessaries to create the HTML for the bars, so some simple de-duplication of code should fix this.

[keraweb]

What is the status for this issue? I have the same thing with one of my plugins. The WP.org API returns the archived/spammed reviews as well.

[SergeyBiryukov]

Replying to Otto42:

This is because the get_star_rating function is using the post_meta, when it should be calling the existing and centralized ratings code to get the information correctly.

It used to call WPORG_Ratings methods via Plugin_Directory::filter_shim_postmeta() before [4420], but apparently post meta fields are necessary for search indexing.

Looking at Meta_Sync::sync_ratings()​, the post meta is supposed to be synchronized with WPORG_Ratings data hourly, so the information should eventually be correct, even though there is some delay.

To reduce confusion and avoid discrepancy between the ratings on support forums and on plugin page, we could probably trigger a sync right after a review is archived or marked as spam.

[SergeyBiryukov]

On second thought, switching Template::get_star_rating() back to using WPORG_Ratings methods might indeed be easier. WPORG_Ratings is not open-sourced yet, so I'm not sure which way is better in terms of performance, but the same methods are used on support forums, so it would at least bring parity.

[dd32]

Just noting that it looks like some plugins post_meta got out of sync, due to the cron only picking up recently added reviews. Removing a review doesn't trigger any syncing and that causes it to ultimately be out of date.

When a spam review is removed, the next review added after that will trigger the resync. Because the action of adding a new review clears out the bad data, this makes this even more low-priority in my eyes.

Fixing this by using the underlying WPORG_Ratings class rather than post meta would probably make sense.
As a temporary work around I just ran a script to resync all the rating counts (commit following)

[dd32]

In 7029:

Plugin Directory: Ratings/Reviews: Add a bin script to resync the underlying ratings data to plugin post_meta
Sometimes the post_meta gets out of sync with the ratings system data due to spam reviews being removed (which don't trigger a sync) and no new reviews being added to the plugin for a while. During that time the plugin will have the previous review count, and only adding a new review will clear that cache.

See #2606.

[dd32]

In 7030:

Plugin Directory: Ratings/Reviews: Enhance the bin script from r7029 to also operate on a singular plugin.

See #2606.

[dd32]

As I hit enter on the commit, I realised that this is a little more of an issue for plugins who have a bunch of spam 5-star reviews removed. As such I added a parameter to allow devs to sync a singular plugins ratings too

Because of 5-star spam reviews, fixing this is a little more important.

[dd32]

In 7282:

Plugin Directory: Use WPORG_Ratings for the plugin rating/ratings when available.

Fixes #2606.