Brian Richards

Hey Chris,

I’m not sure that the code changes will make much sense to you, but here’s the changeset that I put in place to ensure this never happens again: https://github.com/opencredit/badgeos/commit/30c9967ffcaa99abf9ff03d8f23aef6ac350678e

In 1.4 we added a new feature that supports automatically migrating all achievements from one type to another when an achievement-type is renamed (e.g. Changing “Badge” to “Level”). This is a fairly complex process, which is why we never supported it prior to 1.4. While there were already extensive checks in place to make sure something like this wouldn’t happen during the achievement-type renaming process, that condition actually failed in certain cases when a brand new achievement-type was created.

In these instances, when the migration functions were called, the “original achievement type” value would be empty, causing a query for “all posts of this type: ____” to pull back all posts of any type.

The code alterations I linked above are a two-fold measure to make sure this cannot happen again. The first edit is to ensure that there absolutely, positively is an original achievement type post (a hard requirement to verify an existing achievement type is being renamed). The second edit is a backup failsafe to make sure that we absolutely cannot alter the post type of any posts of a core post type (e.g. post, page, menu item, etc).

Michael and I were able to repeatedly reproduce the issue before the patch, and unsuccessful in reproducing it again after the patch.

Hopefully that brings about some clarity as to how and when this bug came to be, and some level of assurance that it’s definitely gone.

We’ve released 1.4.1 to address the issue you discovered. I’m really sorry, again, that it was you who found this bug and not us.

Upgrading to 1.4.1 will prevent this from happening again (to you and anyone else), but it will not undo what has already been done.

If you find using the post-type-switcher plugin to be too laborious, and if you aren’t opposed to privately sending us credentials for accessing your database directly, we can alter the post_types of each posts for you. Just let us know how you choose to proceed.

It is indeed, but thank you for adding your voice. It’s one we hope to resolve soon.

Dylan, my apologies. In the previous release we did away with empty maximums because we found that most admins wanted a maximum of one by default and ran into lots of problems without a limit.

You can still achieve “no maximum” by setting the maximum to zero (0). The label will be updated in the next release to explain this, instead of saying “leave blank”.

Hope this helps!

Ah, I forgot to add this:

If you think a particular feature you need is something that would benefit a number of other users, you’re encouraged to open an issue on our GitHub project page: https://github.com/opencredit/badgeos/issues/ (each feature as a separate issue is ideal)

From what you’ve described already, most of what you’d post would be tagged with Feature Request.

Hey ldsphilosopher, it’s possible to add custom triggers to do exactly what you’re describing, and there are docs to help wire these things together, but they are developer focused and PHP-heavy: https://badgeos.org/developers/functional-docs/awarding-achievements/

Specifically, you want to add additional triggers for “Viewed a Page” and “Passed a Quiz”, and the hooks you’re using for those triggers will be different based on how you’re implementing everything and which plugin you choose to use for quizzes.

I strongly suggest hiring a developer to write these for you (assuming you’re not a developer yourself, that is). It’s also not something we can provide free support for, I’m afraid, because your needs are so specific and custom.

As Michael said earlier, the possibility exists for us to create additional add-ons to help suit some of the needs you’ve described, but they’re not on the immediate roadmap.

As an admin, you should be able to repeatedly award an achievement to a user as many times as you like: even if the achievement has a “maximum earnings” rule set (because, as an admin, you’re bypassing the rules engine and saying, “I want this person to have this achievement”).

You are correct though, in that the UI is preventing you from rewarding an already-earned achievement. That is something we’ll need to update in a later release.

I’ve just created an issue for this bug, and you can track that on GitHub so you’ll know when it gets added: https://github.com/opencredit/badgeos/issues/100

Sorry about that!

Hey allmyleagues,

To clarify, are you using submission-based badges? If so, we had someone else just bring this same issue to our attention: an achievement is set to be earned an unlimited number of times, but the submission form only allows for a single submission.

Let me know if this is the problem you’re describing. It’s not fixed in the 1.1 release (scheduled to ship soon), but it is hot on the heels for our very next release.

Hm, looks like WordPress hung up on you during the file installation. Can you manually upload the files via FTP? If not, try downloading the plugin ZIP file and then use the Upload option (https://d.pr/i/IKWr) to add it to your WordPress site.

If you already have an older version of BadgeOS it could be that WP lost the ability to overwrite the files. If that’s the case, I recommend deleting the original version (this will have no effect on your data) and uploading a fresh copy of the new version.

Hope this helps!

You’ll need BadgeOS 1.0.2, which was just released earlier this evening (so automatic updates in your admin probably hasn’t caught it yet).

Hey Taylor, I’m sorry to report that, at the moment, the plugin only supports a 1:1 relationship with images and galleries (one upload goes to one gallery).

YES, this is making it’s way into a pro version very soon. Stay tuned ??

Currently, no. The only way to upload to a particular gallery is to have an uploader for that gallery. I would recommend adding the uploader to each individual gallery page, rather than present it as a widget.

We’ve talked about a feature like this, so it might find it’s way into a future pro release.

What is your setting for “Minimum User Role” in the Public Uploader settings? If you’ve set it to Administrator then anyone who is not an admin will not see the uploader. If you want it visible to any logged in user then you’ll want to select “Subscriber”, if you want it visible to any visitor then you’ll want to select “Visitor”.

Well shoot, I confirmed this to be the case, too. 1.7.1 fixes this issue. Please update and report back if that’s not true. Sorry for the mixup.