Just tested and confirmed this. We are looking into this right now.
Hoping you don’t have a lot of blog posts to deal with, but I can easily imagine you could. Thankfully the data isn’t deleted, but it will take a moment of work to get fixed. I’m going to recommend this very handy plugin to help out with this, so that you don’t need to access your data right in the database, you can do it from the WP Admin instead.
http://wordpress.org/plugins/post-type-switcher/
It will add a line above your publish/update button that allows you to specify a new post type. You’ll want to set all of your original blog posts back to “post”. I have tested this myself, and it’s working like a charm.
I’m very sorry this had to happen to you, and we appreciate you letting us know so we can get a fix out asap.
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.
Hi Michael,
Yes, I’ll admit this did through quite a wrench into my day. But thank you for that plug-in, it made the change back much easier.
I really like BadgeOS, though I’m now nervous to continue with it. How did this latest release fix the problem?
Thanks,
Chris
Hi Brian,
Thanks for the prompt attention, and for the offer to fix the site for me. I’m back up and running now, so that won’t be necessary. However, I would love to get the BadgeOS add-ons, if that is a possibility. Perhaps as a consolation for being the bug-finder 🙂
Please let me know what you think.
Thanks,
Chris
Chris,
I’ll defer to Brian to share with you the details of the fix. But rest assured, this was an anomaly of an issue.
Please kindly complete the contact form at:
http://badgeos.org/contact/
A member of the team will reach out to you about a consolation prize! 😉
Thanks again for reporting the issue and for your kindness here in the forum.
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.
