Let’s return to a topic I dropped a couple of years ago: transitioning to WordPress after more than a decade of blogging from my own homemade content management system.
(Warning: even as I begin writing this post, I’m reading ahead and I can see the potential for a sermonette-style transition to a Life Lesson via the phrase “…and you know, it occurs to me that life is like that, sometimes…”)
I’ve learned a lot about how a dilettante like myself builds a modern WordPress site. We’re a special breed, the dilettantes. We have too much ambition to just sign up for a WordPress.com blog or use an off-the-rack blog theme. We don’t have enough ambition (or not enough money) to hire someone to custom-design something to our specs.
We live somewhere in between. We must learn, explore, make lots of mistakes, and ultimately reach an articulation of the declaration “I give up!”
It’s a productive version, though. It means “I have reached my saturation point of Exploring and Learning and Growing. My knowledge and my skills have expanded to completely fill the container of time and energy I can give it. Now, it’s time for me to just build the thing and move on.”
So to aid my fellow Dilettantes, here are the various steps I went through on my way towards that magical destination of Giving Up.
Just sign up for an account on some blogging service, click on one of the six available themes, and go. It’s simple and quick, and you’re off and blogging right away. Which was no good for me because I couldn’t find a simple theme that would suit my needs.
Plus, I like the fact that I spend $20 a month for shared hosting on Media Temple. If I want to add a second blog, or a third, I don’t need to pay another $20 a month. At most, I just need to think about upgrading my service at some point.
So I moved on to
It’s close to the lack of effort of Level One: it seems as though you can just keep browsing through galleries and eventually you’ll find a design that’s precisely the one you would have built yourself, or commissioned.
No good for me. I tried, but there are just wayyyyyy too many choices out there. I think I “chose” six different themes over the past two years. I even paid for a couple of them. But eventually, I waffled, reconsidered, and kept looking at more themes.
So I moved on to
I should mention that I already know a lot of CSS, and enough PHP to confidently hail taxis and order in restaurants when visiting PHPistan. Plus, I liked the puzzle of learning something new.
Tutorials like this one and this one really inspired me. WordPress maintains a database of your blog’s data and the theme is a series of templates and scripts that manipulate that database. The tutorials urge you not to be a hero. They wave you away from the idea of filling an empty BBEdit window with PHP and HTML and show you how to just steal the functional nuggets of code from existing themes in WordPress’ built-in library.
That’s right up my alley. It’s the cultural legacy of coding. When you’re building software, your most valuable resource isn’t the reference manuals and API guides: it’s other programmers’ working, tested code. Cut and paste the function you need, examine how it works, and ultimately you can figure out where you can safely tweak and prod it.
Furthermore, building a new theme from existing code elements is particularly attractive to someone with my rudimentary PHP skills. Writing scripts from scratch is still a slow process for me, but I know enough PHP to build something from existing elements and modify what’s already been built.
I eventually abandoned this approach. Building your own theme is very doable and I learned many things about WordPress that would serve me well later on. The more I dug into the nuts and bolts of the process, though, the more I began to appreciate that a WordPress theme is a living, breathing piece of software instead of as a set of HTML files in which little snippets of script act as content placeholders. I was certain that I’d wind up with something functional. I wasn’t so sure that I’d wind up with something that would live and breathe and grow, and could take advantage of future plugins and WordPress features.
Remember, the whole reason why I abandoned my homemade CMS was because I’d been on the upgrade-it-yourself treadmill for almost 14 years. I’m not eager to return to that world.
So I moved on to
This is going to be the sweet spot for most bloggers. Choose a theme, any theme. Then just learn a little CSS (or pick up a spiffy utility like CSSEdit, or StyleMaster for Windows), create a child theme, and then go to town.
Child themes is brilliant, I tells ya. If a WordPress theme is worth using, it’s awfully complicated piece of software. Even if all you really want to do is make the titles of your posts a little bigger, there’s a lot of slogging to do before you find the thing that you need to change. And then a year later, when the theme’s developer comes up with an updated version that adds loads of fab new features, you’ll click the button to upgrade and poof! All of your custom changes go away.
A child theme is a brand-new theme of your creation. Three lines of cut-and-paste markup code tell WordPress “Start off with all of the scripts and styles you’ll find described by this theme here” and the rest of it describes your overrides. “Don’t style a post title like that. Style it like this.”
This tutorial got me off on the right foot. It explains everything. Even better, it gets you excited about what you can accomplish and makes you feel stupid (in a good way) for not finding out about child themes sooner.
…And then you install the Firebug plugin for Firefox, and you wonder why you made such a big fuss about customizing a theme in the first place.
You know that you want to change the font of your post titles. You know that it’s a simple case of modifying or overriding the theme’s CSS definition of that element.
Easy. Er, but first you need to find that definition.
Firebug will give you a simple dashboard to the CSS structure of any page in the browser. Roll your mouse over any CSS declaration, and the associated element will highlight on the webpage.
(It’s supposed to be just as easy to do this in CSSEdit. But I find it’s easier to do it in Firefox.)
Then you just slap in an overriding CSS definition in your child theme. CSSEdit is swell for this sort of thing because it’s interactive. You plug in a change via a (somewhat) word processor-style tool palette and immediately see it reflected on your site.
I treaded water here in Option 4 before I lost interest. It seemed as though the DNA of the original design was always obvious, which sort of put me back where I was when I was examining dozens and dozens of prefab WordPress themes and not finding any to my liking.
But then I learned a little more about the theme community. And I moved on to
The themes you get in Options 1 and 2 are like a hotel room or a model home. The furniture and drapes might not be to your taste, but you can move in right away. Option 3 is like starting off with a wooded lot. Option 4 is like buying an empty, existing house and then decorating it to your liking.
A “framework” theme offers some of the best features of all of these approaches. It’s as though the builder pours the foundations, frames in the whole house, gets all of the plumbing, heating, and electrical services going, plasters all of the walls, installs the roof, nails up the exterior siding, applies two coats of primer…and then hands you the blueprints.
All of the tricky technical bits that make a WordPress theme work have already been taken care of. You could move right in and live a rather stark existence among those bare walls and uncovered floors. But the understanding is that you’ll be finishing it up on your own.
And remember, you have an exceptionally well-documented design. I’ve settled on Thematic, because it’s so well supported. It’s not the only well-documented framework out there, of course. This is one of the big deals of a framework. You solve the problem “How the hell to I put a banner image in the header?” after a quick search of the support forums, not after an hour of poking and prodding and testing and failing.
There are bunches of popular frameworks. As I browsed through a dozen or so, I quickly came to see these frameworks as…well, rapid-development application frameworks. Which is precisely what they are. You’re building a new piece of software, without going to the trouble of re-inventing code that’s virtually identical among 90% of all WordPress blogs.
So that’s it, right? I’m at the end of my journey? The right answer is “Install a framework, and then build it up as needed”?
Close. I believe I’ve now hit upon a method that I’m referring to as “Really Quite Totally Finally The Right Way, Honestly, And I Mean It This Time”:
It’s a small tweak to Method 5. It seems to have given me everything I want, and removed every obstacle I’ve encountered.
I mentioned how easy it was to create a child theme: just paste in three lines of canned code at the top of a text file and presto, it’s a child theme. One of the lines tells WordPress “This child theme’s CSS styles will include all of the CSS styles of the parent theme, with the following overrides:”
Well: if you omit that line, then you get all of the machinery of the parent theme (the plumbing, the electricity, the foundation) without any of its CSS styles. Every element in the page layout is tagged with CSS selectors, but none of those tags have been styled yet.
Brilliant! Only even more so than the previous time I said that!
No, really. I was banging my head against the wall today because I’m really feeling the (self-imposed) pressure to finish up a new blog I’ve been wanting to launch since the middle of last year. Over the past few months of development, I’ve learned that modifying an existing, complicated theme via CSS is the fastest way possible to measure the exact distance between how you think CSS works, and how it actually works.
CSS is really quite simple. Anybody can understand it. You only run into trouble when you can only see (or you only understand) one small part of the elephant representing the CSS styles for this theme.
Yes, I’m a clever boy: by adjusting the offset of a graphic, I can get it to overhang past the left margin of the blog post that contains it and overlap onto the background slightly. My CSS stands proud and strong. But it didn’t work. I was unaware that the CSS element that contains the image has been told to clip anything that extends beyond its border.
I sighed. I edited the CSS for the containing element and told it “Please don’t do that.” I applied the changes, refreshed the page…and suddenly the whole page was a total, ragged mess. Because another style was counting on that clipping effect to pretty things up.
I don’t blame CSS. I don’t blame the designer. I don’t even particularly blame yourself. If I had understood the whole scheme, I’d have known exactly how to accomplish what I wanted to do. But I didn’t. And on some level, that’s kind of impossible.
Theme frameworks are wonderful and modifying them can be a streamlined process. But you’ll run into trouble if you’re trying to make the framework do things that its designer didn’t anticipate…or if they assumed that the framework’s users would be experienced consultants, instead of first-time dilettantes.
The solution was to remove that one little line from my child theme’s style definition. The Thematic framework will still act as the glue between my site design and the WordPress system. Now it’s up to me to actually create that site design, from the ground up.
It seems like the right call. Building every CSS style myself will take a lot of time, but autopsying Thematic’s CSS scheme would have taken just as much time and would have been far messier, I think. The Win is that I won’t have to give up on a good idea just because I can’t figure out how to make it live harmoniously among all of Thematic’s existing definitions. Bonus: I bet I’ll be less dumb about CSS by the time I’m finished.
I had never liked the broad width of Thematic’s content area. I opened the page in Firebug to refresh my memory on how Thematic’s different content areas are tagged. Then I created a style for “#wrapper” and set its width to 800 pixels.
Save, upload, refresh. The layout is 800 pixels wide. I want it centered in the window. Edit, save, upload, refresh: it’s centered. I want the background and the content areas to be contrasting colors. 1-2-3 and it’s done.
Best of all, it’s a linear process. I’ll never have to spend an hour “unwinding” the CSS to sleuth out why a piece of text refuses to be bold. The most frustrating tasks are the ones where you feel like you’re walking through a series of blackened hallways and you don’t know what you’re going to confront until you flip the next light switch. You thought you were going to have to just empty a wastepaper basket next to the sink. And then you got the bathroom door open and discovered that whoever designed the plumbing system in this apartment building didn’t incorporate a checkvalve system that prevents all of the sewage from all of the other units from backing up through a single fixture. You’re definitely going to be here a while.
Even without the presence of raw sewage, those projects are frustrating as all hell. I’ve been Bolding text since before many of you were born. I feel as though it’s well within my skill set to command a computer to make a certain word or line a skosh heavier.
This might be an arrogant statement, dear reader, but there you go. So I find it very, very disorienting when I add “font-weight: bold;” to a CSS definition and am only 60% certain of what effect that will have on anything.