I saw yet another version of a conversation I’ve had over and over again roll by on Twitter last night. A client comes to a dev with a theme they’ve already bought — maybe they thought they could DIY and got stuck; maybe they found the look they really want and they just want to hire a freelancer for some tweaks. It doesn’t really matter. Either way, the next thing that happens in this story is

… because the theme in question is a non-standard pile of deprecated functions held together with duct tape, baling wire, and spit.

So I’m proposing that every WordPress theme that’s intended to be used by anyone other than the original developer¹ should be good enough to pass a very abbreviated Minimum Viable Theme Review²:

1. Develop with WP_DEBUG on. If you see any warnings and whatnots printing out at the top of the screen, whether in admin or the front end, fix those first.
2. Run your theme through Theme Check. Yes, some of the requirements are specific to the Repo, and you don’t need to worry about your license URI unless you’re building for distribution. But the real strength of Theme Check is in finding the things you could be doing in a more WordPress-ish way. Still using a years-old hack to add a menu, or hand-coding feed links in your header? Yeah, don’t do that. Theme Check will give you all that stuff in a handy color-coded and prioritized list.
3. Load up the Theme Unit Test Data and eyeball all the pages and posts. It’s designed to make it very clear when you’ve forgotten to style something or account for some use case. Because I promise some user, somewhere, is going to load up an oversized picture, and not actually want it to overlap the sidebars; or they’ll want to use an ordered list, and they don’t expect it to come out exactly like an unordered list. And in my experience, that user is usually me.

Look, I’m not saying that every theme needs to go through a full wptrt-style review process (although a gal can dream!). But as a starting point, it doesn’t seem a lot to ask that any theme that’s released in the wild should 1) Not break WordPress 2) Do core WordPress stuff the way it’s supposed to, and 3) Display the end user’s content the way they meant it to be displayed.