Here’s another fine mess I’ve gotten me into.
Editing someone else’s theme didn’t work. Or, rather, it was harder than throwing everything out and starting from scratch — there was just too much in there I didn’t understand and too much that broke when I pulled elements out.
However, starting from scratch was easier than expected. At a minimum, a WordPress theme consists of index.php and style.css. — and style.css can be blank to start with (but it has to be named ‘style.css’, go figure). WordPress will use defaults for everything else if custom files aren’t supplied. All a basic index.php has to do is grab some posts from the database and display them, and that little chunk of code was easily stolen (thanks again, Andreas!).
So, starting from some text in the middle, it was actually pretty easy to add blog elements, one by one. I’ve now built header.php, sidebar.php, footer.php, index.php and the basics of style.css. The WordPress program files define many functions — for example, sidebar.css is a pre-defined object that controls both left and right sidebars. I was half-tempted to fiddle with these files, but that’s a bad idea; I’d have to redo my customizations every time I upgraded WordPress. Also, I haven’t the faintest idea what I’m doing.
Luckily, the built in WordPress functions are a dawdle. For example, this is all you have to do to display the post calendar:
<?php get_calendar(1); ?>
Not a dawdle: getting the main elements to line up. Even giving hardcoded values for the total width, the width of the left and right sidebars and the center column, I get totally different page widths with Opera, IE and Firefox. The math just isn’t working. The math never works for me. Math hates me.
Also not a dawdle: building all the fiddly graphics. Sure an’ it’s the most fun part, but the most time-consuming.
I do think my mad scheme of making the graphic elements in low-contrast shades of gray is working. The sidebars are extremely busy without visually drowning the main article. I think. Modestly. They’re also low-burden: the masthead, for example, is the biggest graphic on the page: at 540 by 116 pixels, it’s only 12K. Most of the graphic elements are around 6K. So the total graphic overhead is lower than my mental rule of thumb for the size of a single image in an article (~40K).
You know what else didn’t work? Building it locally on my machine. Well, it kind of worked, but it got messed up looking for graphics. You define graphic locations with code that says “look in a directory called \graphics on my blog path.” Looking back, if I had defined my blogpath as localhost (and then changed it when I moved it online) it would’ve worked. But I got all wadded up when the graphics wouldn’t appear and I’ve been building it live online. I’ll leave the XAMPP on my machine, though — I’ve got some php ideas I want to play with.
You know what ELSE didn’t work? Migrating content from the old site. Well, it actually worked very well, except that it didn’t capture and upload the images. See, the images were there — which is why I was mystified when my new graphic elements wouldn’t show up — but when I looked at the source code, it turns out they were being grabbed from their original location on WordPress.com.
I had pretty much decided not to move my old content to the new location, anyhow. Start fresh. I’ll lose whatever Google cred I’ve built up so far, but c’est la blog.
Next: going visible. So far, I’ve been editing index.php online, but leaving the Under Construction graphic at the default location in index.html. To build the last functions — like comments.php — I need everything in place.
Time to expose myself!