Well, not entirely. The web application that actually makes this website work is WordPress. Up until last night, I was using a standard WP installation, which means I was running WordPress with a pre-packaged theme. Now there are literally thousands of themes: I won’t even link to any particular site here, because all you have to do is search for “wordpress theme” in any search engine to get page after page of links.
I have, since returning to WordPress for the basis of this site, used a half dozen themes in search of “the one.” All of them had something I liked, but none of them had everything. In the end, I decided that there was nothing else to be done except to code the thing myself. And so, as of the end of June in the year 2009, here is the working prototype of jello as I have come to call the collective pieces that make up johnlaudun.org.
The Building Blocks
The essential building blocks of a WP site — disregarding for the moment all the scripts that make calls to the database to pull actual content into pages — are a collection of php scripts stored in the theme folder. Well, with our disregard, we should really call them the essential presentational blocks. In a typical WordPress site, you have a collection of page templates that call upon things like header.php, sidebar.php, and footer.php. Each of those scripts in turns contains calls to others in the WP engine itself to fetch content, either singly or in an iterative fashion, that gets coughed up.
In the case of something like sidebar.php, there is ample opportunity to call a variety of widgets, which are conveniently managed from within the WP Dashboard. For the sake of keeping things simple and for making the pages of JLO load faster, I opted to hard code, as programmers sometimes say, those functions into sidebar.php itself. Here’s an example:
<div class="section">
<h4 class="ver small">
<?php wp_list_pages('depth=1&title_li='); ?>
</h4>
</div>
I borrowed the idea from the developer of the Modern-Clix theme, and I stripped out all the widgetry and now have a sidebar.php file that is 37 lines long.
I performed much the same sort of surgery on the other php scripts, paying especial attention to what the WordPress community calls the Loop, which is the iterative functionality that delivers something the list of posts, either on the front page of the site or in the archive pages. I don’t pretend to fully understand it, but I had to get inside it to some degree to begin to understand where I could intervene in terms of styling what really becomes one of the most important content blocks of the site, the post. I am not completely satisfied with the current state of things, but I have simplified the CSS and I will continue to do so, removing as much as possible to get the sheet to load as quickly as possible.
Flexible Presentation
What this means is that all those scripts I mentioned above deliver to a browser styled HTML. By convention, that means HTML broken into divs and other elements which are styled, by reference to a Cascading Style Sheet, either by class or id. In a style sheet, classes are indicated by a prefatory dot, “.”, and ids by a hash mark, “#”. By convention, classes apply to objects that appear multiple times on a page and ids to unique items. In terms of my own website, the div role call for a given page looks something like this:
#wrapper
#header
#content
.post
#sidebar
.section
#footer
In an attempt to be fashion forward and, I hope, a bit future-proof, much of the website’s measurement is made in terms of ems, a term borrowed from typography, where it refers to the square space constituted by the width of the letter m in a particular type face. There will be, under such a regime, subtle differences between faces. The hope is that those differences will be relevant to the type face itself and all the things it makes up: in books, pages; in websites, er, what we also call pages.
The other measurement commonly used in website is the pixel, which is great for absolute positioning, but it does limit what browsers can do to accommodate or adapt to their particular users. My hope is that using the em I will allow not only my youthful colleagues to read what I write but also some of the older folks with whom I work to read, and if they need to adjust type sizes, the website will flex fairly gracefully. I have not had the chance to try this out on other browsers apart from Safari and Firefox on the Mac, but I will as soon as I can and tweak appropriately.
Goals and Next Steps
My overall goal was to get the look that I wanted, but I also wanted to simplify the code base both for my own ability to use it and revise it as well as to make it faster to deliver to folks with less than optimal connections. The Flickr stuff is going to slow loading of pages down. There’s no doubt about that, but I wasn’t quite ready to give up the thumbnails in the sidebar. The site is now so clean that without a little bit of color somewhere, I worried it would fade into a white-out. I will continue to post bits of code as I go, and I will certainly make the style sheet available once I have made sure that everything in it needs to be there and that I haven’t stripped out anything important. (I would hate to give out broken code.)
Let me know what works and what doesn’t work.
My next steps are to style the printing of pages and posts so that they look like print documents and not printed screen documents and to style the website for use on mobile devices like the iPhone.
UPDATE [2009-06-29]: Comments are now on automatically for all posts.
