I do not believe we have any ability to force a “recheck” of all available achievements(though that may be a nifty idea). I believe they’d have to trigger one of the steps that checks to see if they deserve the achievement yet, and if they match up enough, they’d earn it.
I’m not completely sure how they’d get ahead of such a thing, to be honest. Just trying to work out the flow in my head. Each of the steps you create would be tied to a specific achievement, they’re not just floating out there for any achievement to use. With your example of adding levels, I believe what I replied with above would be true. Hope that makes sense. If not, let’s keep hashing this out.
Just so I understand this correctly….
If we created a badge in the future that awards people that have made 50 comments all those people that already have 50 or more comments would not receive the badge automatically?
What if a user has 55 comments would they receive the badge when they make their 56th comment or would they have to make 50 more?
Does the database store all user actions possible with the plugin or does it only record actions required for badges you have created? So for example, if you don’t have any badges that require members to make comments is it still recording user comment counts?
Thanks
Well, let’s test it quick.
From a different support thread from last night, one i think you commented in, I had like 5 comments already made. I added a new badge that had steps of only 3 comments. Refreshed the page. The new badge didn’t get awarded. So I went ahead and made another comment quick, bumping me up to 6. That triggered the awarding of the achievement. So it doesn’t look like we have auto-watching or auto-checking of required steps on the publish of a new post. They will need to trigger the code that checks the requirements, which is as simple as just making the first comment.
Regarding your 55 comment part, they would just need to make one more to get the achievement recognized as award-able, not 50 more :).
For the last part, I am not sure where exactly the code is for comment based steps, but I wager it just queries for the amount of comments a user has, regardless of if it was before or after the achievement was made.
Maybe comments was a bad example because they are already stored in the database. What about BadgeOS actions that are not automatically stored in the database by WordPress? Are those actions stored even if there is no badge yet created that awards those actions?
Tried with “Log in” steps, I knew my login count in the logs was at about 3 times, created a new badge that required 2 logins, and then visited the frontend and refreshed the page. No new achievement showed up in the widget. Logged out, logged back in, new achievement was awarded.
Something like “publish a page” would watch for the hooks that fire on publish and would check that our user matches the post author, so that one isn’t going to be a recursive check.
Minimal number of points is going to need the user to earn a some new ones before it checks again.
Those are the only ones I can think of that aren’t immediately stored in the db before BadgeOS checks are run.
I think we’re stuck with it an answer of it’s not constantly monitoring to auto-award. It needs to be kicked in the britches to check again, and if more than one achievement are suddenly met, all get awarded.
It sounds to me like it would be best practice to add one login requirement to any future badges/levels requirements to “kick it in the britches” and check for other requirements.
Perhaps BadgeOS could create a “faux” login requirement built in so every time someone logs-in it runs a check for unclaimed badges.
Not sure that’ll get added just because it could get a bit intensive, especially for larger sites.
I did start this GitHub issue enhancement for a manual trigger though, https://github.com/opencredit/badgeos/issues/230
Would that mean that any badge using login requirements is sever intensive?
That comment was more for the last part of your previous comment, with the “faux login” requirement, that’s what would have potential for processing intensive work.
Your solution for your future achievement requirements most likely won’t be bad, as it’d just be checking the one badge, if I’m following correctly.
If anything, try it out and see how it does. I am not sure how big your site is or how big it may be in the future 🙂
Currently we have 50,000+ registered active members. So yes, our servers are a major concern.
The “faux login” would work just like a real login requirement except it would be invisible. Requiring a login for ever badge would insure that it would check any new badges created since their last login. Unless my logic is off it shouldn’t be any more intensive that a regular login requirement.
Another solution would be to do a one time check of the user database when the badge is created. Although that would only work with requirements that are logged in the database. It also has its own server issues.
