BuddyNext 1.0.8: The Release Where I Stopped Adding Features
BuddyNext 1.0.8 is 262 commits across the free plugin and Pro, and most of them are invisible. There is no headline feature here that will make a good screenshot. It is the release I am proudest of anyway, because it is the one where our team stopped adding things and started making everything we already shipped trustworthy at the scale our customers actually run. It is also the release where I can finally say it plainly: BuddyNext is production ready.
If you have read why I built BuddyNext or the complete picture of where it is now, you know the arc: a decade inside BuddyPress, then a rebuild from scratch on custom tables. A year of that rebuild taught me something uncomfortable. The features were the easy part. The hard part, the part that decides whether someone can run a real community on your software, is everything that only shows up at ten thousand members, or in the one edge case your tests never wrote.
1.0.8 at a glance
| Area | What changed in 262 commits |
|---|---|
| Scale | Search, directories, connections, and the feed are indexed and paginated. Webhooks run one job per endpoint. Admin lists batch instead of loading everything. |
| Moderation | Rate limits no longer block a member from editing their own posts. Bulk moderation resolves a username list in two queries, not one per name. |
| Privacy | The date-of-birth REST leak is closed, the display setting truly reduces what is published, and GDPR export is derived from the erasure registry. |
| Payments (Pro) | Renewal discounts honored and refundable, stuck Stripe webhooks recovered, double-charge race closed, no silent free memberships. |
| Security | Deleting the free plugin no longer destroys paid invoices. Invitations are bound to their address, not usable as a bearer token. |
Why I made this release boring on purpose
Our customers running large communities kept hitting the same wall, and they were right to. A search that scans every row. A directory that loads everything. A webhook run that blocks for a minute. A moderation queue that pages nothing.
None of it fails on a demo with fifty members. All of it falls over the day the community succeeds.
I could have shipped another feature this cycle. Instead I told the team the job was to make BuddyNext hold its weight and to fix the bugs that quietly cost people trust. That is not a release you can market with a hero image. It is the release that decides whether the marketing was honest.
Scale that does not fall over
The largest chunk of 1.0.8 is one idea applied everywhere: nothing should load without a limit, and nothing hot should scan a whole table.
Search, directories, connections, and the activity feed are now indexed and paginated, so they cost the same on a community of two hundred thousand as on one of two hundred. Outbound webhooks deliver one job per endpoint instead of one long blocking run, so a slow third-party service can no longer stall the whole delivery.
On Pro, the membership, moderation, and scheduled-post admin lists are paginated and batched, bulk moderation resolves a pasted username list in two queries instead of one per name, and analytics cohort reporting collapsed to two queries with a cache that is finally real.
Deleting a custom reaction no longer full-scans and table-locks bn_reactions.
That is one commit out of the couple hundred. On a busy site, that table lock is a stall everyone feels. Multiply that kind of fix across the codebase and you have this release.
Moderation that does not punish good members
The bug that bothered me most here was quiet and mean. A member who hit the hourly post limit could not edit any of their existing posts. They had done nothing wrong. They had simply been active, and the software locked them out of fixing a typo.
Anti-flood is supposed to stop abuse, not punish your most engaged people. So the rate limits and safeguards no longer block a member from editing what they already published. The content rules still apply to the edit itself, which is the point, but being at a limit is no longer a wall around your own words.
For developers, the safeguard hook now receives a context of create or edit, so a rule you write can apply to new content and deliberately skip edits. Moderation should know the difference between someone posting for the tenth time this hour and someone fixing a sentence.
Privacy I take personally
One fix in this release I will remember for a while. A member could set their date of birth to display as only an age, or only a year. The interface honored that. The payload did not.
The profile payload was still leaking the date of birth. The browser caught what the tests did not.
A real request showed the real leak that a passing test had hidden. That is fixed now, and the display setting actually reduces what gets published, everywhere.
Alongside it, the GDPR export is now derived from the same erasure registry that powers deletion, so a table that can be erased is guaranteed to also be exported, and an erased member no longer survives as a row inside other members’ analytics. Privacy that only works in the interface is not privacy. It has to be true at the payload.
Payment correctness our customers can trust
On Pro, the theme was money, and money is the one place a bug is unforgivable, because it is your customer’s customer who pays for it. This cycle closed a set of them I am glad are gone:
- Renewals were invoiced at list price, ignoring the member’s discount, and could not be refunded.
- A Stripe buyer whose webhook never arrived was left stuck with no membership after paying.
- Two concurrent checkout requests could open two sessions and charge the member twice.
- A cancelled member could not re-subscribe during the period they had already paid for.
- A membership could be granted silently, for free, when a payment had not completed.
Every one of those is a support ticket that starts with an angry customer and ends with a refund and a lost renewal. Fixing them is not glamorous. It is the difference between software a business can run on and software it cannot.
The two security fixes that scared me
Two of these I want to name plainly, because they are the kind of thing that erodes trust instantly if they ever bite.
Deleting the free plugin used to destroy the customer’s invoices and other paid records, and it could take Pro’s own tables down with it. Uninstalling one plugin should never wipe the financial history of a paid product. That is fixed in both directions now.
An invitation used to be usable as a bearer token. An invite is meant to be an offer to one address, not a key anyone holding the link could spend. Invitations are now bound to the address they were sent to.
And yes, a few real features
It was not all plumbing. A handful of features shipped in 1.0.8 that our customers asked for directly, and they fit the same theme of a community you can actually run:
- Report media and block its uploader straight from the media lightbox. A BuddyNext site had no abuse path for media at all, and now reports land in the moderation queue.
- Manage the header account dropdown from Settings: hide, rename, reorder, and add your own links, without touching code.
- Reorder the mobile bottom navigation by drag and drop, with the centre Create button staying put.
- Reschedule a scheduled post by editing it, instead of deleting and reposting.
- A
wp buddynext qa-fixturescommand that generates deterministic edge-case and scale data, so we test the hard cases on purpose.
That last one is the most on-brand item in the release. The way you keep making trustworthy software is by making the edge cases cheap to reproduce, so they stop being surprises.
What production ready actually means here
I do not use that phrase lightly, so here is the bar behind it. Cache conformance used to be an advisory check we could wave through. In 1.0.8 it is blocking, which means a change that caches wrong simply cannot ship. The qa-fixtures command exists so the edge cases that used to bite in production are now data we generate on demand and test against on purpose, rather than surprises we discover from a support ticket.
The release also ran a contract audit that baselines the hooks our own code fires, each one tied back to the call that schedules it, so the seam between the free plugin and Pro cannot drift apart silently between versions. When Pro expects a hook that free quietly stopped firing, that is exactly the kind of invisible break that erodes trust, and it is now caught before it ships.
There is a quieter tell in the commit log too. One commit refreshes the customer and developer docs against 162 commits of drift, and fixes four contract defects that the doc refresh surfaced. Writing the documentation honestly turned out to be a testing method: when the docs and the code disagree, one of them is a bug. Production ready is not a feeling. It is a set of gates a change has to pass before it reaches you, and this is the release where those gates got real.
What is next
The thing our customers ask for most, the last real barrier to switching, is moving an existing community across. That is next and it is close: a dedicated BuddyNext importer, built to bring a community in cleanly and sized for both small sites and large ones, ships in the next couple of days. Getting onto BuddyNext should be as easy as running it, and that is the release right after this one.
Why boring wins
I have shipped a lot of features over the years, and the ones people build a business on are never the flashy releases. They are the quiet ones where the software stopped surprising them.
1.0.8 is that release for BuddyNext. It is 262 commits of scale, moderation, privacy, and payment correctness, and if we did it right, you will not notice most of it. You will just notice that it holds. That is what production ready feels like.
BuddyNext is built and maintained by our team at Wbcom Designs, and it is the community layer of the larger WordPress platform we have been assembling. If you run a community on it, install 1.0.8 alongside Pro 1.0.8, they ship in lockstep, and tell me what still gets in your way. The next release starts from your list, not mine.