Chris Klosowski

You become what you give your attention to... - Epictetus

If there are remaining ones or you run into things please reach out to me. We’ve been working on fixing technical debt issues like the ones you’ve mentioned when we find them or are informed of them. Some of them we can write backfill scripts for, even built a tool into EDD to did some Stripe subscriptions. Some of them are more complex and we can do only so much to backfill data for.

Not to cause panick, some of them don't exist anymore and got patched (the stripe one did). It looks like batches of users over different time periods have been affected by a particular issue - my guess is a patch doesn't necessarily fix existing payments with issues. Also I'm sure one of those issues has to be user error (me)

100,000+ stores run this WooCommerce plugin. I doubt any of them know their payments are broken. Any store with $1M ARR could be missing $700k+ in revenue. If you run WooCommerce Subscriptions, check your store. Yesterday, I reported a bug to WooCommerce that silently broke subscription payments after a product switch. Then I got worried: if they missed something this obvious, what else did they get wrong? So I started auditing. Within hours, I had found three more bugs. There were 121 affected subscriptions, and $43,274 in lost revenue. Here's what I found. WooCommerce Subscriptions has an internal flag that controls whether a subscription charges the customer automatically or waits for them to pay manually. When a customer checks out with (for example) Stripe or PayPal, this flag should be set to "automatic." If it isn't, subscription renewals silently stop working: no charge is attempted, no failure email is sent, and the subscription goes on hold until the customer notices and pays manually, or doesn't and churns. Bug 1 (stale cache): After saving subscription dates, the order cache was never cleared. Subsequent saves could serve a stale object with the flag still set to its default: manual. Fixed in subscriptions-core 6.9.0. Bug 2 (broken HPOS backfill): Missing getter/setter methods prevented subscription metadata from being properly synced to postmeta in HPOS when data sync is enabled. Fixed in subscriptions-core 6.5.0. Bug 3 (unnecessary re-fetch): wcs_create_subscription() returned a freshly fetched instance from cache/DB instead of the already-configured object. Any unsaved state, including the corrected flag, was silently discarded. Fixed in subscriptions-core 7.1.0. These three combined accounted for roughly 7% of all subscriptions created at checkout that were silently born broken, despite the customer paying successfully. For 7+ years (we have data from 2017–2024). Automatic payments NEVER fired for these subscriptions. Users never got renewal emails, either. The only way to know they were broken was if the customer noticed they lost access and contacted support, or if the merchant audited their database manually. Bug 4 (switch): When a customer upgrades or downgrades their subscription, the switcher flags the subscription as manual renewal; it only corrects the flag if the payment gateway changes. A customer switching plans while keeping the same gateway (e.g. Stripe to Stripe) cements the flag stuck on manual. I discovered this two days ago, when I found a happy customer in the store overview that I had just helped upgrade, with multiple valid cards on file, put "On Hold" because of a missed payment. For years, I've offered to help WooCommerce improve its code quality and performance. I dry-run code: I find bugs by reading. All four of these bugs are clearly visible in the source without needing to use the software. They could have been caught early. They weren't. The incompetence is immeasurable (well, actually, with the diagnostic queries in my next post, it might be measurable). Our store is small. WooCommerce Subscriptions powers hundreds of thousands of stores. If 7% of subscriptions were silently broken across even a fraction of them, we're looking at potentially millions of dollars in spoiled revenue industry-wide that could have been prevented. Perhaps even billions. None of this was disclosed well or at all. No admin notice. No email. No advisory. The fixes shipped under vague changelog lines like "Make sure we always clear the subscription object from cache after updating dates" and "Ensure proper backfilling of subscription metadata." One fix was labeled "Dev" instead of "Fix." Two don't appear in the GitHub release notes at all. No remediation tool or diagnostic query was provided. Store owners have NO way to know they're affected unless they manually audit their database. The woocommerce-subscriptions-core repo was archived in May 2025 after the code was absorbed into WooCommerce core — making the fix history harder to trace. If you run WooCommerce Subscriptions and used HPOS before mid-2024, check your store. Queries are linked in the tweet below.

@pvncher @RepoPrompt RepoPrompt has been a game changer so far. Great work and keep the updates coming!

@cklosowski @RepoPrompt Should pair nicely with the rp-cli :)

This will be a game changer for context limits if it works like I expect. I’ve been able to avoid a lot of it currently with @RepoPrompt.

@johnturner @rchase Yeah I have a few things I do frequently for reporting and weekly tracking that I built skills for so it didn’t have to sus it out every time. Just run the skill and execute.

@cklosowski @rchase Chris, you don't really need a skill unless it can't figure out how to use it automatically, you just have it use the Stripe command line. But if you have a workflow, then you can put that into a skill or if you need stuff over and over again.

How do you do simple Stripe queries like "What's the MRR of customers using X product?" without paying $1,000/month for chart software

@johnturner @rchase Yep made a Stripe reporting skill myself for this.

@rchase I can confirm it works like a champ :)

When we were contemplating this for email marketing integrations @eddwp, we settled on separate plugins with a shared composer library to connect the SDK of the service with EDD. We ended up finding that (with the email marketing services specifically), their SDKs were different enough that we could just build out a 'connector' that we can maintain for all of the integrations, but still keep each separate. I think it's ultimately up to what your time finds easier to maintain.

I see most plugin companies having dozens of individual add-ons. Are there examples of companies which combine multiple add-ons and integrations into one plugin? For example, instead of having a Mailchimp add-on, a Kit add-on, a MailerLite add-on, and an ActiveCampaign add-on. Are there companies that have an Email add-on that bundles all those options together? Or instead of having 20 different feature add-ons, you bundle all of them up into one premium add-on? I'm asking because that's what we're planning to do with EventKoi. To us it seems easier to manage a small handful of plugins with bundled integrations and features, rather than 30 different add-ons. And I can't tell why more people don't do it. Is it a bad idea and I just don't know it? In which case, please tell me why. Or is it a good idea that more people don't do because they already committed to single feature add-ons and they can't go backwards?

There’s a whole generation of adults who don’t know any of the jokes from Austin Powers 2 and that just makes me sad.

The “their own context” is such an under-appreciated mechanism. Without subagents, Claude Code was compacting so frequently it was slowing me down. With subagents for token-heavy tasks, that dropped significantly. Biggest savings was a subagent for handling my Playwright MCP tasks. It takes a ton of tokens for each page load.

The main benefit of subagents is that you can spin up multiple instances in parallel and they have their own context.

@hirepetedotdev @eddwp Our latest plugin updater is as simple as a composer package. Happy to answer any questions you might have. easydigitaldownloads.com/docs/software-…

@rmelogli Nice post and a good idea for sure. This was one of the main reasons we added a rate column to @eddwp core, so that when we introduced our multi-currency addon we could do reporting in “converted” values. Orders in multiple currencies, reporting in your stores currency.

New Post - WooCommerce: Save Order Currency Exchange Rate businessbloomer.com/?p=253968 #Currency #Order

@TheFrosty @codyL Now can you guys help us out and maybe give us a chance to win a couple in our series 🤣

@codyL Yeah, thanks for that one 😀

Always a great day when the Snakes beat the Phillies!

@KatieKeithBarn2 @pmjcreations @uglyrobot @ask_hellosatya @stripe @OpenAI @eddwp We are keeping a close eye on the availability of this feature. The good news is the docs say the Payment Element supports it. So once they make it available for us to enable, it should just work.

@pmjcreations @uglyrobot @ask_hellosatya @stripe @OpenAI Yeah, it’s often a case of waiting for Stripe to add something. And then waiting for @eddwp to add it to their Stripe plugin so we can actually use it 😩

As always, I got a ton of business benefits from attending #WCUS: - Productive conversations with other plugin companies about cross-promotion. - Invited to speak at 2 conferences. - Early insights into Elementor’s new "Angie" AI plugin & opportunities it creates for Woo + integrations with our plugins. - Content idea for WooCommerce Product Options (new use case). - Received inside info about how some of the bigger companies in WordPress are managed, which will help me to be more strategic in how to work with them. - Learned that UPI payments dominate in India, where we have lots of traffic but low conversions → adding this to our research. - Recruited a beta tester for Barn2 Bundles & Bulk Discounts. - Connected with plugin founders also expanding into Shopify → added them to my Slack group. - Tips on support metrics + process improvements. - Useful feedback on Barn2’s content & my personal role in the community. Now to put it all into practice 🚀

@BlakeWhittle7 @ciorici @Cloudways Keeping an eye on this thread. Not sure if there is anything we can do on our end but @Cloudways if I can help in anyway or share any information that would help ensure license activations don’t trigger false positives in the firewall, I’m available.

@ciorici @Cloudways Weird, looks like it’s a reCAPTCHA DoS issue from Immunfiy360.

All of a sudden, @Cloudways's firewall started blocking the IPs of our customers, and I'm having trouble figuring out how to resolve the issue. Anyone else using Cloudways and EDD having similar issues?

I think this is a symptom of a difference in process, as you mentioned you are applying a 100% credit, instead of modifying the line item to $0, as when I do the line item modification, I get the expected results of the revenue not increasing. There are a few ways we could handle this...but I'll have to look at the queries to see what we can do here. We are in the middle of scoping a new reports UI with the ability to customize/filter more reports, so I'll add these notes to the PRD so we can keep this use case in mind.

I’m looking at my Top Selling Downloads report. It also includes renewals. Maybe I have the wrong assumption but I’m expecting to see only new sales and want to see counts only for real purchases here. Is there a better way to give license to people besides an order with 100% credit so they are not included in real sales reports?

One thing that about @eddwp Reports: if I give a license to someone for $0 (for a review or dev license) it counts it towards my total sale at the normal price. My data is not as good as I had been thinking 😔

@jeffr0 Logging an issue so make this possible, but in the mean time, you can manually verify the user as an admin from the customer details in the backend.

I'm wracking my brain, and for some reason, Google and AI are not helping. Does anyone know how to resend a User Verification email from EDD?

@adampreiser @tomzur Nope same here. I check it less and less 3 years in, but I still find myself smiling when I open it up.

@jamesckemp Ugh yep. Ted Lasso, geez. 🙄

@cklosowski Autocorrect working overtime!

The hardest part about airpods is trying to find the right angle to press and hold to turn on noise cancellation 😅

It’s less about the number of records and more about the data you are storing. If your data maps easily to the existing post table columns then it’s fine. But if your data is mostly in the meta table, a well crafted custom table performs better, uses less space, and is easier to query.

WordPress devs — at what point do you move a custom post type (with lots of postmeta) to a custom DB table instead? 🤔 Do you have a hard rule (e.g. 10k+ posts)? Do you go custom from day 1 for certain use cases? Curious how others decide!