Top Contributors of the Month [Paid] v2.2.9

[Stuart Wright]

So I checked. Banned users are not included in the lists when they're created.

The issue is if they're banned after a cache is already created they are not removed in real-time from that cache.

I'll see about purging a banned user from the most recent cache on ban action.

It’s great that you’re using a cache. But shouldn’t the cache be cleared when recreating the list?
When we ban users, they are put in to a banned usergroup. It is that usergroup which I am excluding from the Top Contributors list.
What if a user is suspended? That’s just adding the Suspended usergroup.
Or put in to any of the usergroups we don’t want rewarded with the Top Contributors prize? Like the Adblocking usergroup from your other addon?
What if the user self disables using the self disable function of User Essentials?

I won’t pretend to know how caches should be managed, but the moment a user has one of the excluded user groups added to their account, they should not appear on the list.

 

[Wutime]

Or put in to any of the usergroups we don’t want rewarded with the Top Contributors prize? Like the Adblocking usergroup from your other addon?
What if the user self disables using the self disable function of User Essentials?

The entire list is cached; it's not real time. If you want it real-time you can disable the cache. I don't recommend it, but you could do it. Or set a short cache lifetime.

If a user moves into an excluded usergroup and the list is cached, they'll appear in the list until the cache expires. If you have a 1 hour cache, they'll appear in that list for up to 1 hour.

I've added an immediate cache removal for banned users in the next release, but I'm not going to add every possible cache busting scenario for every possible add-on.

The issue with NOT caching is the fact that users can choose complex 6-metric queries, and then every page load if it's not cached those queries run every single forum/thread view; caching is the way to go, despite the fact it can lead to a rare stale piece of data.

The issue without caching is primarily exacerbated on large forums. On smaller forums like the one you shared earlier, caching isn't that important. Though I'd strongly recommend at least a 1 minute or 5 minute cache; and yes, data may appear stale for that 1 minute or 5 minutes, but is it really the end of the world given all the performance benefits outside of these edge cases?

 

[Wutime]

The reason for the cache is:

• Ensuring speed and efficiency
• To overcome DB design choices by XenForo that make some of the queries incompatible with XenForo

XenForo made some great design choices to ensure thread/forum rendering was fast. However, these choices make reverse lookups on who received who's reaction, or who responded to who's thread often taxing on the database when doing large row scans.

The queries were never intended, and therefore not very performant. When doing massive row-based lookups in combination with a large busy forum; running these queries can hit really hard. Hence the cache system.

I've already planned a v3.0 of this add-on that will work similar to stat_daily and create statistics per scoring metric each evening; allowing the leader board to be rendered by day, week or month; but it will come at the drawback of having zero same day leaderboards (it'll always be a day behind).

The biggest benefit of doing the stats in the evening will be allowing unlimited scoring metrics, and allowing them to be easily added by definitions for custom add-ons, xfmg, xfmr, etc.

 

[Wutime]

I won’t pretend to know how caches should be managed, but the moment a user has one of the excluded user groups added to their account, they should not appear on the list.

Yes, in a perfect world.

Just like I'm sure you'd love to update your website page and have Google reflect the change in real-time. But sometimes caching is necessary.

If you want real-time turn the caches off; you'll get real-time widgets at the expensive of cpu/ram on every page load that the widgets load.