I started building Sales by State as a WordPress.org project. Free plugins, a paid add-on sold through my own licence manager, everything running on infrastructure I control. That worked fine.
Then I decided it was time to also list Sales by State PRO on the WooCommerce Marketplace, a different channel with its own review process and its own rules about what a plugin name can even look like.
My first submission had a couple of problems, and that had nothing to do with the plugin code. Then there was the demo site. It had to be built from scratch.
So, here’s what actually happened, in the order it happened, starting with the two rejections.
Why bother with the Marketplace at all?
Sales by State Pro already sells on this site. Someone finds the free plugin on WordPress.org, likes it, buys Pro, and my own licence system handles the key and the updates. Nothing about that is broken.
The Marketplace is a different kind of customer. Some store owners look for extensions right there, or through the extensions page in wp-admin.
They’re never going to stumble onto my free plugin on WordPress.org first. Listing there isn’t replacing what I already have, it’s a second door into the same plugin!
The problem with my own licence system
My site’s version of Pro checks in with my own server to confirm a licence key is active, then pulls updates from there. WooCommerce.com doesn’t allow that. If they’re selling it, they handle the licence check and the updates themselves.
So I needed two versions of the same plugin: one with my licence code, one without it. Keeping those in sync by hand, remembering to strip the right files out of a second copy every time I fix a bug, is exactly the kind of thing that goes wrong eventually… so Claude built it properly instead.
My real code now lives in a single GitHub repository. When I publish a release, a script builds a clean copy with those sections removed and pushes it to a separate repository, the one I actually hand to WooCommerce.
I never touch that second copy by hand. It’s generated, every time, from the same release that goes out to my own customers.
Rejection one: the name
I submitted “Sales by State Report Pro for WooCommerce” as the product name. Rejected. The reason: WooCommerce’s trademark rules don’t allow their own name to be part of a product name.
You can say a plugin is “for WooCommerce” in a sentence describing it, but the literal name field can’t contain the word.
That felt backwards at first, since every plugin using this same pattern seems to have “for WooCommerce” right there in the name. Turns out that’s a WordPress.org convention, not a Marketplace one.
So I renamed the Marketplace listing to just “Sales by State Report Pro“. The plugin’s actual file names, the code, my own site’s listing, none of that changed. Just the one text field WooCommerce shows to shoppers.
Rejection two: the slug
Fixed the name, resubmitted, got a second rejection on the slug field for the exact same reason. The web address for the listing had “woocommerce” baked into it too (“sales-by-state-pro-for-woocommerce”).
Then a third requirement showed up on the upload step. The zip file I upload has to be named after that same slug, and the folder inside it has to match too. My actual plugin files are still named the old way internally, none of that had to change, but the folder wrapping them for this one zip does.
I added that repackaging step to the same automated pipeline from earlier, so every future release builds a correctly named zip and attaches it to the GitHub release on its own. That was a one-time fix, not something I have to remember to do by hand every time I release a new version.
Rewriting the pitch
My first draft of the product description said things like “adds tax periods and exports to the free Sales by State report for WooCommerce plugin”.
Reading it back, that’s the wrong way round. Nobody buying a plugin cares that it “adds” something to a free one they may not even know exists yet. They care what it does for them.
I also caught myself writing US and Canada into the description more than once, without ever actually checking whether that was true. It isn’t; the plugin works for any country WooCommerce has states or provinces for!
I rewrote the whole thing to say plainly what it does and who needs it, and stopped assuming the tax angle was the only reason anyone would want it. Some stores care about sales tax thresholds. Others just want to know which regions are actually selling:
Revenue by state or province, for any country, in tax quarters, IRS periods or months, with CSV/XLSX/PDF exports and threshold alerts.
There was no demo site
The submission form asks for a working demo a reviewer can log into. I didn’t have one! Sales by State Pro reads live store data, so there wasn’t an existing page I could just point at.
I had to build a second, separate WordPress install just for this, running on SQLite so it never touches my real database. Filled it with close to 800 fake orders spread across US states and Canadian provinces, real sales tax on them, a few refunds and cancelled orders mixed in so it looks like an actual store instead of a spreadsheet. Set up a reviewer login that can’t install or edit anything, blocked it from search engines, and wired up a script that resets it back to the original data whenever it needs to.
It took Claude a few minutes 🙂
And it’s worth it: a reviewer clicking around a report with real-looking numbers in it is a completely different experience than reading a description and taking my word for it!
Testing it properly
WooCommerce has an official testing tool for this (QIT), and I wanted to run it. Turns out it needs a partner account with an extension already listed on the Marketplace, which is exactly the thing I was trying to get to for the first time. Chicken and egg 😀
So I ran the same categories of checks myself instead: the WordPress.org plugin scanner, coding standards, static analysis, and manually testing activation with the free plugin and WooCommerce both switched off, both on, and everything in between.
That caught a real bug before anyone else ever would have seen it, a WordPress notice that only shows up under a specific combination of plugins being active or not. Small fix, but the kind of thing that looks bad showing up in front of a reviewer instead of getting caught first.
Where it stands now
Submitted, waiting on review. I don’t know yet what comes back. Given how much came up before a human even looked at the code, I’d be surprised if nothing does!
Leave a Reply