Fair warning: tweaking someone else’s theme is never as straightforward as you think. There’s a reason theme frameworks have gotten popular for custom designer/developers.
The client inquiry seems simple enough: “Hey, I downloaded this theme from the repository,” or “I bought this theme at a marketplace,” and “I’d like you to make a few changes. It’s close to what I want, but it needs a few changes.”
You quote the prospect your hourly rate and the estimated time you would spend doing the tweaks. The client sends you the zip file of the theme, you run it in your development environment then…
Boom. You’re staring at code you can’t make out. Forget the readability bit; forget shorthand. You’re faced with poorly written custom functions, undocumented hooks, abused filters, you name it. You get this feeling you might as well reverse-engineer the front end of the theme or plugin and call it a day. You find that researching the edits to the theme would push your estimated time to over twice what you quoted. You need to quote your client more, but expectations have been floated, if not set.
There’s more than one way to skin a cat. Some days, it seems there’s one way for every cat.
If it’s a matter of customizing a theme in terms of reader-facing design: colours, typography, minor changes to the markup, the task is simple enough. But when a client asks to expand a theme’s functionality using a theme whose code I have never seen before, there are so many potential pitfalls that it serves neither my client nor myself for me to enter into a contract for work without having the chance to review what I have to do.
Let’s start at HTML and CSS. Before CSS3 and widespread browser support, rounded corners for boxes required extraneous divs just to get them to work. You ran into alignment issues when cross-browser testing, and heaven forbid that you had to make it “IE6 compliant.” A single sidebar box with rounded corners and a background image can be coded in at least four ways, with varying degrees of efficiency. To an extent, CSS3 solves this particular problem, but how many more of these little things will you face as you go through your work? When you throw in PHP, the number of possible ways to produce a required output greatly increases.
We may all be writing in the same language—PHP—but we’re writing widely different manuscripts. The human cost of learning one person’s theme—purchased for a small amount of money—for one client, for use on one project is high enough. Having to do this with every client you come across would make the cost insurmountable. This messy, diverse, beautiful nature is also what’s led to the rise of “theme frameworks,” and they’ve proven to be helpful and efficient ways to churn out custom themes for clients. They let developers streamline their learning paths by having a relatively standard base on which to build their themes, especially when the custom themes they make would require periodic, minor maintenance over time.
Theme frameworks help. I’ve been using one I’ve developed since version 0.71.
There are some themes I won’t touch. I have no experience with the Thesis framework and I won’t get into jobs for that. I would send them to experienced Thesis developers like Greg Rickaby or Andrew Norcross. Or I’d offer my own solutions. Freelancing is the same as any other profession, and it requires savvy salesmanship to stay in business.
A number of commercial themes have enough features to enable professionals to do their jobs a little bit better, a little faster. This is the reputation built by Headway, StudioPress Genesis, iThemes Builder, and Thesis. What they do not have are features that cast a wide net to capture numerous, small slices of the market from their competitors. For example, Builder doesn’t ship with a slider plugin, but they do have Displaybuddy available for separate sale.
Recently I’ve switched to Builder for rapid deployment projects. The many child themes available address a majority of the aesthetic requirements of clients, and creating a child theme is relatively easy. There’s a lot to learn with it alone, and I admit, that trying to learn another framework—be it Genesis or Headway—might not be the best choice for me at the moment. Maybe when I am ready to expand in that direction, but not yet.
“Standardization” in open source is impossible, but we can try to come close.
If you’ve ever worked in engineering or architecture, you’d know that drawings for a project are made according to a standard. It makes plans understandable for anyone with the professional knowledge, and allows for the continuity of a project across multiple participants. We don’t have that in WordPress. We have quality standards, and we hope that people who follow them get the most exposure. The WordPress Theme Review Team presides over theme submissions before they make it to the repository, and the official checklist is there for everyone to see an aspire to. None of these are guarantees to the actual readability and malleability of the code by a third party, though.
A few recommendations.
Commercial theme devs, especially those offering lower price points: a good way to help those who buy your commoditized themes is to offer links to people who are familiar with your work and have customized them before. I don’t know how the sub-$50 theme market works in terms of competition and whatnot, but even in such a crowded space there should be plenty of room for cooperation and referrals.
Freelancers: don’t quote anything until you’ve looked at the code. That hour or two looking at someone else’s theme may fall under time spent and even close to speculative work because you risk not getting client, but don’t forget to factor in that discovery time when you quote them. Don’t forget to educate your clients. there is a real difference between a drop-in theme you get from Themeforest, which you can slap a logo on, and an application/theme development framework you can start off of.
(Thanks to Andy Stratton, Ryan Duff and Phillip Copley with help on this article.)
