WB Gamification 1.6.4: A Security Release You Should Install Today

WB Gamification 1.6.4 is a security and stability release, and it is genuinely urgent. It closes a bug that could delete queued WooCommerce orders and subscription renewals on sites unrelated to gamification, closes three ways an anonymous visitor could read a member’s private progress and badges, and finishes GDPR erasure and export work left quietly incomplete. There is also one behaviour change that will break a link you may have already shared. Read this before updating.

The bug that could destroy other plugins’ work

Start here, because this is the one that had nothing to do with gamification going wrong, and it is the reason to update today even if you have never looked at a badge or a leaderboard on your site.

WB Gamification uses Action Scheduler, the background job queue that ships with WooCommerce and is shared by dozens of plugins that need to run work outside the request cycle: order processing, subscription renewals, email sends, sync jobs. It is shared infrastructure, not something any one plugin owns.

The plugin’s own cleanup routine did not understand that. On a schedule, it deleted every pending Action Scheduler job older than its retention window, with no check on which plugin had created the job. It simply queried for old pending jobs and removed them.

• On a site running WooCommerce, that routine could delete queued orders waiting to be processed.
• It could delete subscription renewal jobs, silently skipping a charge that was supposed to fire.
• It could delete any other plugin’s queued background work, with no log entry pointing back at WB Gamification as the cause, because from the site owner’s side it just looked like jobs that never ran.

This is collateral damage in the truest sense. A store owner debugging a missed subscription renewal would have had no reason to suspect a gamification plugin. The fix removes the blast radius entirely.

• Cleanup is now fenced to jobs WB Gamification itself created. It cannot see, let alone delete, another plugin’s queue entries.
• Queued work is never aged out as routine housekeeping. A pending job stays pending until it runs or is cancelled by the system that owns it.

If you run WooCommerce, memberships, subscriptions, or any plugin that leans on Action Scheduler, alongside WB Gamification, this alone is the update-today case. It was not a gamification bug wearing a gamification plugin’s name; it was a shared-queue bug that any plugin sharing that queue was exposed to.

The one behaviour change you need to know about

This is the change most likely to surprise you after updating, so it goes here, early, before the rest of the fix list.

Badges are now private until a member shares them. That applies retroactively: every badge that already exists on your site, earned before this update, starts private. If a member posted a badge share link, an OpenBadges credential link, or a public badge page URL anywhere before you updated, that link will stop resolving to anything until they come back and press Share again.

• Members decide what is public. Every earned badge on a member’s own badge board now has a Share button. Until they use it, that badge is visible only to them.
• The links break because the badge behind them is no longer public, not because anything was deleted. The badge, the points behind it, and the member’s progress are untouched.
• If you deliberately ran an open community where badge visibility was never a concern and you would rather not have members re-share anything, WP-CLI gives you a one-pass override: wp wb-gamification share grandfather publishes every existing badge in one run.
• To go back the other way, wp wb-gamification share reset makes them all private again.
• Publishing is always self-service. The REST route a member calls to publish or withdraw a badge takes no member id in the request. It always acts on the badge holder’s own account, so there is no way for one member to publish, or unpublish, somebody else’s badge.

Decide before you update, not after. If your community shares badge links on social profiles, forums, or resumes, run the grandfather command right after updating so nothing goes dark. If badge visibility should be the member’s own call going forward, the default is already doing that for you.

Three ways an anonymous visitor could read a member’s private data

Each of these required no login, no API key, and no special permission. A visitor only needed to guess or increment an id in a URL. All three are closed in 1.6.4.

1. Anyone could read any member’s challenge progress

The public challenges endpoint accepted a member id and returned that member’s progress on the challenge, with no check on who was asking. A visitor with no account at all could walk through ids sequentially and collect progress data for the entire membership, including for members who had explicitly switched their public profile off.

2. Anyone could read any member’s badges, and even generate a signed credential in their name

Three separate surfaces were addressed the same unsafe way: by a badge id and a member id, both of them guessable integers.

• The badge share card, meant to be seen only after a member chose to share it.
• The OpenBadges credential endpoint, meant to issue a verifiable, signed credential representing that a specific person earned a specific badge.
• The public badge page itself.

A visitor could enumerate all three. For a credential-bearing badge, that meant the site could be made to issue a signed verifiable credential about a person who had never chosen to share anything. That credential carries the same weight as one the member requested themselves; the only difference is the member never asked for it.

3. Unpublished community challenges could be read by anyone who had the id

The public challenge list already correctly hid draft and retired challenges from the list view. But the single-challenge endpoint, reachable directly by id, did not apply that same check, so the title and details of a challenge you had not published, or had pulled after publishing, were still readable by anyone who requested that id directly.

All three paths are now checked against the same rule the list views already enforced: a request has to be entitled to see the record it is asking for, not just able to guess its id.

GDPR: erasure and export were incomplete

If your site has ever processed an erasure or export request for a member under GDPR (or any regime with equivalent rights), the tool you used did not do the full job.

• Erasure was not complete. The eraser removed data from the tables it knew about. It did not know about six others, including queued notifications, cohort membership, and reward redemptions. A member who asked to be forgotten was still present in those six tables after the request was marked done.
• Export was missing entire categories of data. The personal-data export a member is entitled to request omitted their kudos history, cohort history, redemptions, and challenge log. What they received back was a partial picture of what the site held on them.
• Six stored settings survived erasure, were absent from export, and were left behind at uninstall. One of those six is a staff-written note attached to that member’s record. A note a staff member wrote about a person was neither erased on request, nor disclosed in that person’s own export of their data, nor removed when the plugin was uninstalled.

That last point is worth sitting with. It is not a missing counter or an orphaned points total. It is a piece of text a staff member wrote about a specific person, and it outlived every mechanism meant to give that person control over it.

Both export and erasure are rebuilt in 1.6.4 to cover every table that can hold a member’s data, driven from one list rather than a hand-maintained set of table names. That also means a table added in a future release cannot quietly fall outside the eraser’s reach the way these six did.

The timezone bug class

A cluster of unrelated-looking bugs turned out to share one root cause: several features compared times using the database server’s clock instead of the site’s configured timezone. If your database and your WordPress site are both set to UTC, none of this ever showed up, which is exactly why it survived multiple releases unnoticed. Anywhere else, it broke, and it broke in opposite directions depending on which side of UTC the site sits.

Feature	What went wrong off UTC	Fixed
Challenge open/close windows	The page showed a challenge as open or closed on the site’s clock, but the engine awarding progress used the database clock. Sites ahead of UTC could show “open” while awarding nothing for hours; sites behind UTC kept awarding after the challenge visibly closed.	Both the display and the awarding engine now read the same, site-configured clock.
Community challenge countdown	Showed the wrong time remaining, and could read “ended” hours before the challenge actually ended.	Countdown now calculates against the site timezone.
Per-member kudos cooldown	Never applied on sites behind UTC, so a member could send kudos to the same person repeatedly with no cooldown in effect.	Cooldown window is evaluated against the correct clock and now actually limits repeat sends.
Weekly digest “this week” window	The window used to decide what counted as “this week” was offset, so the email could omit recent activity, or include activity from the previous week instead.	Window now aligns with the site’s actual week boundary.
Weekly digest recipient list	The query selecting who should receive the digest also used the database clock, so members who were active near the edge of the window were dropped from the send entirely.	Recipient query uses the same corrected window as the content itself.
Daily Points Trend chart	Drew an empty column for days that actually had points recorded, on any site not set to UTC.	Chart buckets points by the site’s calendar day.
Leaderboard snapshot	Emptied itself at the end of each rebuild on sites ahead of UTC, so leaderboard views silently fell back to a full-table query every time.	Snapshot rebuild boundary now matches the site’s clock and stays populated.

None of these were exotic edge cases. A site in India, Australia, most of Europe, or the US behind UTC could hit several of these at once, on the very first week the plugin was live. If your site clock has never once matched UTC, this table is effectively your changelog.

Data hygiene: what deleting a member actually deleted

Several bugs in this release are about data quietly outliving the member it belonged to, or being counted wrong because it did.

• Deleting a member left all of their gamification data behind. Points, streaks, badges, cohort rows, and queued notifications all stayed in the database indefinitely, attached to a user id that no longer resolved to anyone.
• Those orphan rows broke the Analytics dashboard. Because it counted rows belonging to members who no longer existed, it could report figures as nonsensical as 6822% streak health.
• Failed webhook deliveries were never retried. The retry logic looked up a database column that did not exist. The query failed at the database level every time, and the job quietly did nothing, with no error visible anywhere in the admin.
• A reward with limited stock became unlimited the instant it sold out. Stock now has three distinct states: empty means unlimited (as it always did), zero means sold out, and any positive number is the exact quantity remaining. Any reward currently sitting at stock zero and behaving as unlimited is migrated automatically on upgrade.
• Two kudos sent to the same member in the same instant could both slip past the cooldown check and get recorded twice. Only one is recorded now, regardless of timing.
• The leaderboard could show two different point totals for the same member on the same page, because the leaderboard row and the “your standing” strip above it were reading from two different sources of truth.

Fixes for this group: deleting a member now removes their gamification data with it. The Analytics dashboard is corrected even on sites that already have orphaned rows sitting in the database from before this update. Webhook retries fire correctly. And if your site has existing orphan rows from a member deleted on an earlier version, wp wb-gamification member purge-orphans cleans them up in one pass.

Settings that existed in code but had no screen

A separate group of fixes is not about broken behaviour at all. It is about rules that were already being enforced with no way for a site owner to see them, let alone change them.

• Weekly cap per action. The limit was already being enforced in the points engine. There was simply no field anywhere in the admin to set it. It is now settable per action under Settings > Points.
• A new Background features section under Settings > Modules. Weekly recap email, leaderboard nudges, status retention, community challenges, tenure badges, site-first badges, badge sharing, and cohort leagues can each now be switched off individually. Seven of those eight were already being enforced in code with no screen anywhere to configure them.
• Webhooks can now subscribe to the redemption event. The engine already fired that event and the API already accepted a subscription to it. The settings page simply never rendered the checkbox to turn it on.

If you assumed a feature was missing because you could not find a setting for it, it is worth checking Settings > Modules again after updating. Several things you may have thought were unavailable were running the whole time.

Genuinely new capability

Not everything in 1.6.4 is a fix. A few things are new.

• Multi-condition badge rules. A badge can now require more than one condition to unlock, built from any of eight condition types: points total, points within a period, action count, level reached, another badge already earned, streak length, tenure, or an admin-awarded flag. Rules can require ALL conditions or ANY of them.
• Tenure and site-first badges are now ordinary, editable rules. The four tenure badges and three site-first badges used to be awarded by hardcoded engines while the badge library’s own screen claimed they were manual-award only. Changing what “2-Year Member” actually meant required editing PHP. They are now regular rule-based badges you can open and change from the admin, the same as any custom badge.
• Retroactive award on save. When you save a badge rule, you can now choose to award it immediately to any member who already qualifies under the new rule. This is off by default, so saving a rule change never silently mass-awards a badge unless you ask it to.
• Kudos Moderation gets real filtering. You can filter by giver, receiver, and date range. Kudo-trading pair detection (two members repeatedly kudos-ing each other back and forth) now scans the whole table, not just whatever page happened to be visible on screen.

Performance

A cluster of changes targets sites with real member counts, not demo data. None of these change what the plugin does; they change how much work it does to do it.

• A badge is now only evaluated when something that could actually change its answer has happened. A “publish 10 posts” badge no longer runs a full count every time an unrelated member reacts to a comment.
• Tiered badges (Bronze at 5, Silver at 25, Gold at 100 of the same action) used to ask the database the same underlying question about the same member three separate times on every award check. They now ask once.
• Leaderboards serve from a maintained snapshot table instead of aggregating the entire points ledger on every page view.
• Point decay no longer aggregates every member on the site to work out which few hundred actually need decaying.
• Kudos Moderation’s abuse detection is now indexed. It previously scanned every kudos ever given, every time a moderator opened the page.
• Database indexes were added for badge, kudos, submission, redemption, and member-intelligence queries.
• The weekly digest, cohort assignment, and status-retention jobs now process members in batches instead of the entire site in one run.
• Personal-data export is now paginated, so a long-tenure member with years of history no longer risks exhausting memory on a single export request.
• Award Points now uses a searchable member picker instead of rendering every member on the site into a single dropdown.

None of this changes numbers on a screen. It changes whether that screen loads at all once your member count moves from a few hundred to several thousand.

Accessibility

• The redemption confirmation dialog was announced to screen readers as a modal while trapping nothing inside it, and pressing Redeem never moved keyboard focus into it. It is a real dialog now: focus moves in on open, Escape closes it, and focus returns to the button that opened it.
• Level-up and streak celebrations were announced as modal dialogs a member had no way to dismiss with the keyboard. They are announced as status updates now, not as dialogs a member is trapped inside.
• The user status bar and top-positioned toasts could render on top of, or hidden behind, the active theme’s header. They now measure what is actually occupying the top of the page before positioning themselves.

What WB Gamification is, and what it costs

For anyone meeting the plugin for the first time through this release: WB Gamification is a universal gamification engine for any WordPress site. Install it, activate it, pick one of five starter templates, and gamification is running immediately with no further configuration required.

• Points for 30+ actions across WordPress core, BuddyPress, WooCommerce, LearnDash, bbPress, and more, auto-detecting whichever of those you have installed.
• 30 pre-built badges plus unlimited custom badges, now with the multi-condition rule builder described above.
• 5 default levels.
• All-time, monthly, weekly, and daily leaderboards, scopeable to a single BuddyPress group.
• Challenges, streaks with grace periods, and peer-to-peer kudos.
• 19 Gutenberg blocks and 17 shortcodes for placing any of this in your theme without touching code.
• 64 REST endpoints across 28 controllers, outbound webhooks, and WP Abilities API support.
• Event-sourced points, meaning every point on the site is traceable back to the action that generated it.
• Built for memberships past 100,000, with WP-CLI commands for the operational tasks covered above.

Every mechanic and every integration listed above ships in the free plugin. There is no paid tier being held back and no add-on required to unlock any of it. If you want the reasoning behind that choice rather than the feature list, we have laid it out separately: gamification shouldn’t cost extra.

If you are still deciding whether WB Gamification is the right engine for your site, two comparisons are worth reading before you commit: how it stacks up against GamiPress and myCRED, and a broader look at WordPress points, badges, and leaderboard plugins as a category. The plugin itself is available on its product page, and the full version history is on the release notes page.

Update urgency, at a glance

Issue	Who is affected	What to do
Action Scheduler cleanup deleting other plugins’ jobs	Any site running WooCommerce, subscriptions, or any other plugin that queues background jobs, alongside WB Gamification, regardless of whether gamification itself was ever configured	Update now. This is the highest-priority item in the release; the exposure was never about gamification data.
Three anonymous-read paths (challenge progress, badges and credentials, unpublished challenges)	Any site with public challenges, badges, or OpenBadges credentials enabled, visible to logged-out visitors	Update now. Assume the paths were reachable; there is no way to retroactively know whether they were used.
Incomplete GDPR erasure and export	Any site that has processed, or may need to process, an erasure or export request under GDPR or an equivalent regime	Update, then re-run erasure for any member who submitted a request on an earlier version, since the earlier run would not have reached all tables.
Badges now private by default	Any site where members have shared badge, credential, or public badge-page links anywhere outside the site	Decide before or immediately after updating: leave private (safer default) or run wp wb-gamification share grandfather to keep existing links working.

Frequently asked questions

Do I need to do anything after updating?

Two things are worth doing right away. First, if your community has shared badge or credential links anywhere, decide whether to leave badges private (the new default) or run wp wb-gamification share grandfather to republish everything that already existed. Second, if you have processed any GDPR erasure requests on an earlier version, re-run them, since the earlier eraser did not reach six tables that are now covered.

Why did my badge share link stop working?

Badges are now private until a member shares them, and every existing badge started private when you updated. The badge itself and the member’s progress are unchanged, only its public visibility reset. Ask the member to press Share again, or run wp wb-gamification share grandfather to republish all existing badges site-wide in one pass.

Was my site affected by the Action Scheduler bug?

If you were running an earlier version alongside WooCommerce, a subscriptions plugin, or any other plugin that queues Action Scheduler jobs, the cleanup routine could have deleted those jobs regardless of whether you ever configured gamification features. There is no reliable way to check after the fact; updating removes the exposure going forward.

Is any of this behind a paid tier?

No. WB Gamification has no paid tier and no add-on model. Every mechanic and every integration covered in this release, points, badges, levels, leaderboards, challenges, kudos, webhooks, and the REST API, ships in the free plugin.

Will updating change my existing badges or rewards?

Your badges, points, and progress are untouched. The one visible change is that badges start private until shared again. Separately, any reward that was sitting at zero stock and behaving as unlimited is migrated automatically to the corrected “sold out” state, so double-check reward stock levels after updating if you run limited-stock rewards.