A subscription business with more than 9,000 registered members and close to two million dollars in yearly revenue runs its paid community, courses and coaching programmes on one WordPress site. We look after it month to month: WordPress and plugin updates, maintenance, and whatever goes wrong in between. The client is under NDA, so there is no name and no screenshot here, only the work.
The kind of site it is
Memberships, recurring payments, a course platform, a community, a page builder, consent, advertising pixels, and a marketing team that ships new landing pages every week. It grew over years, with many hands and more than 70 active plugins. Sites like that work well almost all of the time. When something does break, it breaks where two plugins meet, and neither vendor sees it as theirs.
That is the work: find the exact cause, fix it without touching anyone else’s code, and say plainly when the right fix is to change nothing.
A sign-up page that crashed for one customer in three
New members were paying and then landing on a broken thank-you page. Not all of them, which is why it had gone unnoticed: the staging copy worked, the team’s own test purchases worked, and WordPress only sends its crash email for the admin side.
We matched one reported sign-up to one line in the server log, to the second. The advertising add-on was calling a function the membership plugin does not have, and only on one path: a trial subscription. Every trial sign-up crashed the page in the footer, and the purchase never reached the ad platform either. Everyone else passed through untouched.
Proving it took one switch. The fix is a small plugin of our own that takes over that single case and sends the purchase event itself. It retires itself the day the vendor ships a correction, and no vendor file was edited, so the next update cannot undo it.
Checkout tracking that reported zero
The marketing team rebuilt a campaign page and moved the sign-up form onto a page of its own. Sign-ups kept working. The ad platform, however, started receiving “checkout started, value 0, no product” for every visitor, which quietly ruins a campaign’s numbers.
The tracking add-on assumed the form always lives on the membership’s own page. We corrected the data where the membership plugin hands it over, so any future page with an embedded form reports the right product and price. Before it went near the live site we ran it against real cases without writing anything, then checked the result in the page a visitor gets.
Consent that held one script and missed the rest
The consent tool blocked the main advertising script until a visitor agreed, as it should. The add-on’s separate event scripts were not on its list, so they ran anyway, found nothing to talk to and threw errors on every page. We put them behind the same consent decision. Nothing fires before a visitor agrees, and exactly one of each event fires after.
One customer who could not register
A member wrote in: the form refused their phone number, whatever format they tried. Support could not reproduce it.
The server logs could. Six attempts in two minutes, and each time the site had received an empty phone field. The form rewrites the number just before sending, using a helper script that loads late, and in that browser it had not loaded at all. Then we counted: one customer in a week of sign-ups. We explained the cause, described the fix we would make if it happened again, and recommended leaving the site alone. Not every fault earns a change.
Questions as well as faults
“Can we tell which sign-ups came from the campaign page?” Nothing on the site recorded that. The server logs still held a week of visits, so we rebuilt the path of every new member in that window before the logs rotated out, and the team had real numbers for a campaign they had already paid for.
How we work on a site like this
- Read first. Logs, database and the page as a visitor receives it, before anything changes.
- Our fixes live in our own small plugins, each with an off switch and a note saying what it fixes. Vendor code stays byte for byte as shipped.
- A backup before every change, and the rollback written down next to it.
- Verified at the public address, through the cache, not on a test copy.
- The bug goes back to the vendor, so the workaround can be removed one day.
None of this is a case against WordPress. A busy site with a lot of plugins and a lot of people will grow an edge case now and then. They are rare, and with someone watching they are found in hours, not discovered months later in a revenue report.