Are WordPress Frameworks Crutches?

On a scale of difficulty — one being checking email, ten being binary machine language — to me, WordPress is maybe a four, and trending downwards. It’s taken me a while to realize that, from my viewpoint as a freshman in the app. And by WordPress, I mean knowing enough HTML, CSS, PHP and SQL to make a living at it. Which is my goal.

Before I knew I wanted to do the above, but had an idea for a blog, I only took the WordPress.org plunge once I knew I could make an early end-run around the coding by buying a framework theme: first Thesis, then about a year later (for reasons I won’t get into here), Headway.

I assumed a framework would smooth the learning curve of WordPress itself. But as I learned WordPress and the frameworks in parallel (because it turns out the frameworks have learning curves of their own), it dawned on me that the effect of the framework, even if not the intent, is to shield me from “all that nasty coding and drudgework.” Once I got so far out onto the gangplank of learning the framework, the more dependent on it I felt. And when I need more functionality than the framework provides, I have to dive into the code anyway — only now I’m more afraid of it than I need to be.

And what kind of drudgery are we avoiding here? Let’s take one feature seen in both these frameworks, and more new theme packages every day (so I hear): changing a background image. In the frameworks/themes, you go to an admin panel control. A browse button calls your OS’s directory. You pick the image, and hit an upload button. Changes are made in the code for you.

Without a framework, how do you do it? You find a new image, name it what you named the previous background, such as “background.gif”, upload it via FTP, which warns, “There’s a document with the same name; shall I overwrite it?” You say “Yes”, it uploads, and you’re done. A fresh view of the page shows the change.

What is the impact of the two methods on the underlying code? I hear that one of the themes might make some kind of database call regarding backgrounds. Maybe, maybe not. With FTP? Though a WordPress freshman, I can categorically say, none at all. Not even a little.
So at the expense of a few more mouse clicks and a little confidence, I’ve avoided adding to the things that can go wrong. If in these frameworks I fiddle my way into some kind of logic problem, and I go to the average WordPress sophomore or junior for help (such as @RentAGeekMom, whose comment on today’s WPMods post deals with this same subject), I fear they’ll take one look under the hood and go, “Uh-oh. Framework. I’m not touching this.” Yes, Headway’s support forum is fantastic. Fortunately. Thesis’ is too, no doubt. And there are plenty of framework experts, just a Twitter hashtag away, who will help. For a fee. (Hey, I shelled out bucks for an attachment to an open-source app; surely I can afford a consult.)

I just reviewed the CSS every graphic designer should know, which has atrophied in my brain since I’ve been wrestling with these frameworks. Sure enough, it’s like falling off a log, it’s so easy! So what am I afraid of? The CSS modifications I successfully made on my site’s custom.css page in Headway are piling up. Are they starting to look like a full-blown theme of my own making? What if that’s all there is to it? Could PHP be that much worse?

The final verification of my suspicion (nail in the coffin?) came in the form of BitWire Media’s WordCast. This episode was a roundtable prognosticating WordPress 3, that digressed into a critique of the whole framework mindset. They stopped short of a consensus, saving further discussion for a future episode.

Well, I have my own consensus.

In any discipline, it’s the power user who breaks or bends the rules. But first, he knows them cold. I’m not throwing away my frameworks anytime soon (the costs of both include lifetime upgrades). They serve the purpose of those who never intend to get beyond the “learning piedmont”, but just plug and play a nicely flexible theme; or to power users with clients who demand more design-noodling capability. But I think it’s the WordPress journeyman who’s already committed to the learning-curve climb, who can make best use of them as a time-saver and client-pleaser, once he totally grasps what exactly they make faster, and how. Taken too early due to his own insecurity, I think they hamper growth in learning the code, postponing the inevitable — and ultimately, not-so-painful.