Personally, I have never found a theme that is 100% useable without some significant HTML+CSS customization and/or PHP/MySQL/Javascript customization. And even the best themes use approaches that result in sites that require a huge amount of time to maintain the content because the themer made easy coding choices rather than build functionality to allow managing content with less effort. Examples include using categories to group content where a custom taxonomy would be better, and a custom post would be best.
Sepearating content from presentation might have been the original purpose of themes, but that definitely hasn’t proved to be the case in practice.
Put more succinctly, the law of unintended consequences strikes again.
As a general rule, I find that themes, (and I’m not including every theme developer or designer here, just lots of them), promise way more than they can ever deliver.
I can’t count the number of sites I’ve worked on over the years in which management of expectations with regard to what a client can do with a theme and what they can’t has played a significant role.
Add to this the complexities of customizing a theme so that it becomes accessible, (something required especially when there’s a lawsuit or demand letter or even just a desire to make the site accessible involved), and you have a recipe for more headache for the developer and the client than there should be.
There’s a reason I won’t touch anything from Theme Forest, which is admittedly the most extreme case but far from the only concentration of trashfire from a code standpoint that’s out there.
And I don’t see any of this changing until one of the least-modernized parts of WordPress, (the theme infrastructure) is gone.
If Gutenberg helps us get there, I’m all for it, even though I still think Matt should spend about three days without his mouse and monitor stuck with a screen reader and Gutenberg.
Respond