While having nothing to do seems nice, and it was the first month or two, watching TV all day gets boring very quickly. Especially with HBO showing The Green Lantern multiple times a day and week. So things had to be done, not only to entertain me but also to hone my skills further and keep them from rusting shut.
I’ve started reading more(Currently reading Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin, very insightful book!) and I’ve built my own WordPress theme(Which can be found on Github, feel free to “steal” or comment on it :)). I’ve opted for a minimalistic approach for this new theme, because it appeals to me most and is the easiest to read and get around.
As a starting point the theme uses the Handcrafted theme, which is a bare naked HTML5 theme. This theme uses HTML5 and the HTML5shiv to support older, less-capable browsers and seemed like a great place to start. In the process of building my theme I’ve learnt a lot more about how WordPress works(and doesn’t work, for that matter) and how to properly use some of the new tags in HTML5(Specifically article and section tags).
Features of the new look include:
A new homepage that will show my most recent post and the content of a page
The process of building the new homepage shows my limited experience with WordPress. It relies on having the static page setting enabled and having two pages(One for Home, one for the Blog). I wanted to do more with the homepage than simply showing page content, I made a page-template for it. I named this home.php. As it turns out, that was a bad idea. Little did I know, WordPress has a Template Hierarchy that basically works as follows:
If a visitor goes to your home page at http://example.com/blog/, the following happens:
WordPress first determines whether it has a static front page. If a static front page has been set, then WordPress loads that page according to the page template hierarchy.
If a static front page has not been set, then WordPress looks for a template file called home.php and uses it to generate the requested page.
If home.php is missing, WordPress looks for a file called index.php in the active theme’s directory, and uses that template to generate the page.
This basically meant that my front and blog pages were loading off the same template. Bit of a RTFM issue right there and I don’t mind admitting it.
The page template itself is pretty straightforward. It uses WP_Query('showposts=1') to retrieve the most recent post and a simple bit of code to retrieve the page content set as “front page”(Thanks to David of Limoen for showing me setup_postdata!).
$frontpage_id = get_option('page_on_front');
setup_postdata(get_page($frontpage_id));
the_content();A separate blog page
The blog page is now listing all my blog posts until the beginning of time. I use a WordPress plugin called “Infinite Scroll” to automatically load the next page of posts until you reach the end. I’ve also gone ahead and used Chris Spooner’s tutorial to create CSS calendar icons for each blog post in the list. It uses CSS3 techniques like gradients, box shadows, and border radius. I’ve still got to do stuff about the comment form though, see if I can manage to make something spiffy out of those.
An archive page
As I had removed the sidebar altogether from this theme(I’ve never really had a use for it, even with the old theme), I had to make at least the option to search available. A very simple get_search_form(); and it’s done. I’ve also personalised the page somewhat and added some translations by checking the qTranslate language.
One thing I have noticed when working on this page is the inconsistency in the ways to show the post counts for each month and category. To show the post count when using wp_get_archives(); (for months), you need to set show_post_count to true. Like so: wp_get_archives( 'show_post_count=true' );
However, the same is not true when using wp_list_categories();, which uses show_count=1 to enable the post count. A minor inconvenience, but it makes me wonder why they’re different. There certainly is no reason for them to be, as far as I know anyway.
Better usable on mobile devices
This turned out to be a bit tricky. This is the first time I’ve used media queries and while the concept is simple, it ended up taking more time than anticipated. Mainly due to the fact that the browsers on my Android phone(Chrome, Firefox and Web) showed things differently from the User Agent/Device metrics overrides in the Chrome developer toolbar.
The toolbar suggests a screen resolution of 720 by 1280, and while there’s nothing wrong with that this is not the width an element(say, the body or html elements) will get when it’s set to 100%. Instead, the width will be set to 320. When overflow is not set to hidden, this will ensure that, when zoomed out, the elements that you’d like to span the full width only reach to about halfway. Not a pretty sight indeed.
I would never have figured this out were it not for the remote debugging that’s part of the Android SDK. That being said, I’ve no idea how this website runs on iPhones or tablets. I’d assume that it will work fine on iPhones at the very least, considering those set the viewport to 320 as well when using:
<meta name="viewport" content="width=device-width, initial-scale=1.0">Tablets I’m not too sure about however…
So with that said and done, those are the highlights of my theme and some of the problems I’ve come across in developing it. Certainly a nice learning experience to keep me from getting bored. Should you spot any inconsistencies, bugs, weirdness anywhere on the site(or in the code on github) or feel I could’ve done things simpler(mostly the coding part) do let me know. :)
Next stop will likely either be learning Python using a combination of Learn Python the Hard Way, Python from Scratch, and The Django Book or dive deeper into PHP and spend some time with Zend. Because, stuff.