I'm not using any other plugins in my localhost install, where badges still aren't awarded.
No, I don't see anything in my error logs other than someone from Poland trying to find a php executable inside the cgi-bin, even though I'm using mod_php.
There seems to be a flaw in the _AwardBadges() method: What it does is get a list of badges already obtained by the currently logged in user (BadgeAwardModel()->GetUnobtained() does the opposite of what its name indicates) and then proceeds to check if any of those haven't been awarded to the user already. That doesn't really compute
I have figured out why I couldn't replicate the issue. This project started as a private git repo and switched to a public repo on github when I released. When this happened, I switched my dev box over to github, but my 'live' test environment was running off the private repo.
If this was all that happened, I would have quickly noticed and corrected the change. I had set up a script to automatically update the private repo with the public repo commits while I was working on my private dev site. I erroneously assumed that I was working on the same commit as you had posted.
I have since done a complete sweep of my testing environment and am now working on the public version exclusively.
tl;dr I made a mistake when refactoring that was propagated unintentionally. Patch incoming.
@Kasper, once again, you prove invaluable. Thanks for the excellent deduction!
@hgtonight said:
ascom I just pushed changes to the repo that should fix this issue for you. Please let me know if the issue is resolved and I will release 0.3 here.
I noticed some issues with 0.3:
The zip file's "Yaga" folder should be "yaga" - it causes an include error in bootstrap.php
Somehow the settings menus are missing, and the settings link in the applications list returns a 404.
Comments
The GDN_BadgeAward table is empty.
Do you have any other plugins enabled?
Are you getting any php errors in your server log?
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
@hgtonight
I'm not using any other plugins in my localhost install, where badges still aren't awarded.
No, I don't see anything in my error logs other than someone from Poland trying to find a php executable inside the cgi-bin, even though I'm using mod_php.
And Vanilla runs just fine otherwise?
The only thing I can suggest is to do is to change it to a greater than or equal to comparison.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Vanilla appears to run fine. Also, changing it to greater than or equal to doesn't help.
Have you been able to reproduce this issue?
There seems to be a flaw in the
_AwardBadges()
method: What it does is get a list of badges already obtained by the currently logged in user (BadgeAwardModel()->GetUnobtained()
does the opposite of what its name indicates) and then proceeds to check if any of those haven't been awarded to the user already. That doesn't really computeI'll see if I can prep a PR fixing the issue.
Kasper Kronborg Isager (kasperisager) | Freelance Developer @Vanilla | Hit me up: Google Mail or Vanilla Mail | Find me on GitHub
Bam: https://github.com/hgtonight/Application-Yaga/pull/11
Kasper Kronborg Isager (kasperisager) | Freelance Developer @Vanilla | Hit me up: Google Mail or Vanilla Mail | Find me on GitHub
I have figured out why I couldn't replicate the issue. This project started as a private git repo and switched to a public repo on github when I released. When this happened, I switched my dev box over to github, but my 'live' test environment was running off the private repo.
If this was all that happened, I would have quickly noticed and corrected the change. I had set up a script to automatically update the private repo with the public repo commits while I was working on my private dev site. I erroneously assumed that I was working on the same commit as you had posted.
I have since done a complete sweep of my testing environment and am now working on the public version exclusively.
tl;dr I made a mistake when refactoring that was propagated unintentionally. Patch incoming.
@Kasper, once again, you prove invaluable. Thanks for the excellent deduction!
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
@ascom I just pushed changes to the repo that should fix this issue for you. Please let me know if the issue is resolved and I will release 0.3 here.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
I noticed some issues with 0.3:
@hgtonight
Oh, never mind about the settings menu - it works perfectly. I guess it was some permissions weirdness.
@ascom I updated the zip hosted here to use the lowercase name. Also added some basic stats on the dashboard.
If this works, I am going to close this thread as solved. Feel free to start a new discussion with any other issues you find.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
If this works, I am going to close this thread as solved. Feel free to start a new discussion with any other issues you find.
Installed it on to my forum, and no bootstrap.php errors seem to appear